Carbon footprint data authority verification method, device, equipment, medium and product

Abstract

The application discloses a carbon footprint data authority verification method, device, equipment, medium and product, comprising: obtaining a transaction request of a user on carbon footprint data, determining a target transaction request to be executed for authority verification, routing the target transaction request to a target shard, sorting the target transaction request on the target shard to obtain an ordered transaction set, sequentially executing authority verification on the target transaction request in the ordered transaction set by using each node of the target shard, generating a state tree of the verification state of each node, and determining the root hash value of the state tree of each node, determining the authority verification result of the target transaction request on the target shard according to the root hash value of each node of the target shard, and generating a verification record of the target transaction request when the authority verification result is passed, and returning the authority verification result to the user. The application improves the execution efficiency of authority verification, ensures the tamper resistance and compliance of the verification result, and meets the demand of large-scale, real-time carbon footprint credible management of the industrial chain.

Description

Technical Field

[0001] This application belongs to the field of carbon footprint data management technology, specifically relating to a carbon footprint data access verification method, apparatus, equipment, medium, and product. Background Technology

[0002] The full lifecycle management of carbon footprint data has become a core link driving the green and low-carbon transformation of the industrial chain. It covers transactions such as the collection, storage, revision, and certification of carbon footprint data. Blockchain technology, with its characteristics of distributed ledger and immutability, is widely used in carbon footprint data management. Among them, smart contracts, as digital protocols that are automatically executed and have transparent rules, have become the core carrier for carbon footprint data permission verification.

[0003] Currently, carbon footprint data management involves dozens of entities, including raw material suppliers, manufacturers, logistics providers, and regulatory agencies. Product lifecycle traceability certification, emission data revision, and approval must be verified through blockchain smart contract permissions. However, since carbon footprint permission verification contracts are essentially computationally intensive tasks with often multiple nested logic layers, existing blockchains typically process smart contract transactions with ordinary data query transactions in a mixed manner. This makes computationally intensive permission verification contract transactions easily blocked by a large number of low-frequency, simple transactions, resulting in the execution time of a single permission verification being 10-20 times that of an ordinary query transaction. This makes it difficult to support large-scale industrial chain collaboration scenarios and fails to meet the stringent real-time requirements of the supply chain. Blockchain sharding technology, introduced to improve throughput, requires each node to independently and completely re-execute the same smart contract logic to verify the results. For carbon footprint permission verification contracts, which have high execution costs, this repetitive execution paradigm results in a huge waste of computing resources. Simultaneously, on-chain storage and network bandwidth costs increase. Furthermore, multiple authentication requests for the same product's carbon footprint data may be allocated to different shards, leading to fragmented storage of the data's permission verification state. Cross-shard state synchronization in a concurrent environment easily results in inconsistencies, potentially causing authentication errors and fundamentally undermining data credibility. Therefore, current blockchain-based carbon footprint permission verification suffers from high latency, high resource consumption, low consistency, and difficulty in adapting to complex logic, making it unsuitable for large-scale, real-time, and reliable industrial chain carbon footprint management. Summary of the Invention

[0004] The purpose of this application is to provide a carbon footprint data permission verification method, apparatus, device, medium, and product that can solve the problems of high latency, high consumption, and low consistency in current blockchain-based carbon footprint permission verification in terms of processing efficiency, resource consumption, state consistency, and adaptability to complex logic, making it difficult to meet the needs of large-scale, real-time trusted management of carbon footprints in the industrial chain.

[0005] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a carbon footprint data access verification method, the method comprising: Obtain user transaction requests for carbon footprint data and determine the target transaction requests for which permission verification needs to be performed; Based on a pre-determined sharding mapping relationship, the target shard corresponding to the target transaction request is determined, and the target transaction request is routed to the target shard. The target transaction requests on the target shard are sorted to obtain an ordered transaction set. The nodes of the target shard sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. Based on the verification status of each node in the target shard, generate a state tree of the verification status of each node, and determine the root hash value of the state tree of each node. Based on the root hash value of each node in the target shard, the permission verification result of the target transaction request on the target shard is determined; wherein, the permission verification result includes permission verification passed and permission verification failed; If the permission verification result is successful, a verification record for the target transaction request is generated, and the permission verification result is returned to the user.

[0006] Optionally, the step of obtaining user transaction requests for carbon footprint data and determining the target transaction request to be subject to permission verification includes: Obtain user transaction requests for carbon footprint data, parse the transaction requests, and obtain the operation type and data identifier of the transaction requests; The request type of the transaction request is determined based on the operation type of the transaction request; wherein, the request type of the transaction request includes data transaction requests and contract transaction requests; The contract transaction request in the transaction request is identified as the target transaction request to be executed for permission verification.

[0007] Optionally, determining the target shard corresponding to the target transaction request based on a pre-determined sharding mapping relationship, and routing the target transaction request to the target shard, includes: The data identifier of the target transaction request is hashed to obtain the transaction hash of the target transaction request; The shard number for processing the target transaction request is determined based on the transaction hash and the predetermined total number of shards to be executed for permission verification. Based on the pre-determined sharding mapping relationship and the sharding number, the target shard corresponding to the target transaction request is determined from the shards to be executed for permission verification; The target transaction request is routed to the target shard.

[0008] Optionally, the step of sorting the target transaction requests on the target shard to obtain an ordered transaction set, and then sequentially performing permission verification on the target transaction requests in the ordered transaction set using each node of the target shard to obtain the verification status of each node of the target shard, includes: Obtain the timestamp and transaction hash of the target transaction request on the target shard; Based on the timestamp and transaction hash of the target transaction request, the target transaction requests on the target shard are sorted to obtain an ordered transaction set; Obtain the pre-configured permission verification contract for the shard to be executed for permission verification; Based on the permission verification contract, each node of the target shard sequentially performs permission verification on the target transaction request of the ordered transaction set to obtain the verification status of each node of the target shard.

[0009] Optionally, the step of sequentially performing permission verification on target transaction requests in the ordered transaction set based on the permission verification contract, and obtaining the verification status of each node in the target shard, includes: Obtain the user attributes and aggregate signature of the target transaction request; Based on the permission verification contract, each node of the target shard sequentially performs user attribute verification and aggregate signature verification on the target transaction request of the ordered transaction set. The verification status of each node in the target shard is obtained based on whether the user attributes of the target transaction request match the preset AND gate policy and the validity of the aggregated signature.

[0010] Optionally, the step of generating a state tree of the verification status of each node based on the verification status of each node in the target shard, and determining the root hash value of the state tree of each node, includes: The verification status of each node in the target shard is hashed to generate a state tree of the verification status of each node; the verification status includes at least one of user attribute verification progress, aggregate signature verification progress, and permission verification progress. The hash values ​​of the state tree are hashed layer by layer to obtain the root hash value of the state tree for each node.

[0011] Optionally, determining the permission verification result of the target transaction request on the target shard based on the root hash value of each node in the target shard includes: The root hash value of each node in the target shard is broadcast, and a pre-determined consensus node is used to identify the node with the same root hash value. The permission verification result of the target transaction request on the target shard is determined based on the number of nodes with the same root hash value in the target shard.

[0012] Optionally, determining the permission verification result of the target transaction request on the target shard based on the number of nodes with the same root hash value in the target shard includes: If the number of nodes with the same root hash value in the target shard exceeds a preset proportion of the total number of nodes in the target shard, then the consistent root hash value is taken as the root hash value of the target shard, and the permission verification result of the target transaction request on the target shard is determined to be permission verification passed. Otherwise, the permission verification result of the target transaction request on the target shard is determined to be permission verification failure.

[0013] Optionally, after determining that the permission verification result of the target transaction request on the target shard is that the permission verification fails, the method further includes: Nodes in the target shard whose root hash values ​​are inconsistent are identified as abnormal nodes in the target shard. Obtain the state tree of the abnormal node, and verify the actual situation of the abnormal node performing permission verification based on the state tree of the abnormal node to obtain the abnormal verification result of the target shard.

[0014] Optionally, if the permission verification result is successful, generating a verification record for the target transaction request and returning the permission verification result to the user includes: If the permission verification result is that the permission verification is successful, the root hash value of the target shard, the ordered transaction set, and the data identifier of the target transaction request are used to generate the verification record of the target transaction request; The verification record is written to the blockchain containing the carbon footprint data, and the permission verification result is returned to the user.

[0015] Optionally, the method further includes: If the target transaction request awaiting authorization verification is associated with at least two types of carbon footprint data, a joint transaction request is generated. Determine the shards for executing the joint transaction request for each type of carbon footprint data; The joint transaction request is routed to the corresponding shards of the various types of carbon footprint data, and the permission verification result of the shard executing the joint transaction request is obtained; If the permission verification result of the joint transaction request is that the permission verification is passed, the joint transaction request is determined to be valid, and the permission verification result of the joint transaction request is returned to the user.

[0016] Optionally, the step of routing the joint transaction request to the corresponding shards of various types of carbon footprint data and obtaining the permission verification result of the shard executing the joint transaction request includes: The primary shard is determined from the shards, and the joint transaction request is routed to the shards corresponding to the various types of carbon footprint data; The sharding is used to perform permission verification on the joint transaction request, and the root hash value of the state tree for the permission verification of the shard is determined. The root hash value of the shard is aggregated into the main shard to obtain the permission verification result of the shard that executes the federated transaction request.

[0017] Optionally, the step of aggregating the root hash value of the shard to the primary shard to obtain the permission verification result of the shard executing the federated transaction request includes: The root hash values ​​of the shards are aggregated into the main shard, and the number of shards with the same root hash value is identified in the main shard. Based on the number of shards with the same root hash value in the shards, the permission verification result of the shard executing the federated transaction request is obtained.

[0018] Optionally, the step of determining the validity of the joint transaction request and returning the permission verification result of the joint transaction request to the user when the permission verification result of the joint transaction request is successful includes: If the permission verification result of the joint transaction request is that the permission verification is passed, the joint transaction request is determined to be valid, and a verification record of the joint transaction request is generated; The verification record of the joint transaction request is written into the blockchain where the various types of carbon footprint data are located, and the permission verification result of the joint transaction request is returned to the user.

[0019] Secondly, embodiments of this application provide a carbon footprint data access verification device, the device comprising: The request acquisition module is used to acquire users' transaction requests for carbon footprint data and determine the target transaction requests to be executed for permission verification. The sharding mapping module is used to determine the target shard corresponding to the target transaction request according to a pre-determined sharding mapping relationship, and to route the target transaction request to the target shard. The permission verification module is used to sort the target transaction requests on the target shard to obtain an ordered transaction set, and use each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. The state tree generation module is used to generate a state tree of the verification status of each node based on the verification status of each node of the target shard, and to determine the root hash value of the state tree of each node. The result determination module is used to determine the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard; wherein, the permission verification result includes permission verification passed and permission verification failed; The return result module is used to generate a verification record for the target transaction request and return the permission verification result to the user if the permission verification result is that the permission verification is successful.

[0020] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the steps of the carbon footprint data access verification method as described in the first aspect.

[0021] Fourthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the carbon footprint data access verification method as described in the first aspect.

[0022] Fifthly, embodiments of this application provide a computer program product, including a program or instructions that, when executed by a processor, implement the steps of the carbon footprint data access verification method as described in the first aspect of this application.

[0023] The carbon footprint data permission verification method provided in this application obtains a user's transaction request for carbon footprint data, determines the target transaction request to be verified, determines the target shard corresponding to the target transaction request according to a pre-determined sharding mapping relationship, routes the target transaction request to the target shard, sorts the target transaction requests on the target shard to obtain an ordered transaction set, uses each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set, obtains the verification status of each node of the target shard, generates a state tree of the verification status of each node based on the verification status of each node of the target shard, determines the root hash value of the state tree of each node, determines the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard, generates a verification record of the target transaction request if the permission verification result is successful, and returns the permission verification result to the user. This application embodiment avoids blocking high-frequency permission verification transaction requests by sharding and classifying them, meeting the real-time carbon footprint management needs of various industries. All permission verification requests for the same carbon footprint data are executed in a dedicated shard, avoiding the problem of verification errors that can easily occur when synchronizing verification states across shards. The hash value verification of the state tree is used to replace the repeated execution of the entire node, and the permission verification process within the shard is optimized by using hash calculation. The execution result of the permission verification contract for the transaction request is confirmed in a lightweight way, simplifying the execution and verification process of the permission verification contract. It adapts to the complex logic of permission verification for carbon footprint data, improves the execution efficiency of permission verification, and ensures the immutability and compliance of the verification results, thus guaranteeing the credibility of carbon footprint data and meeting the needs of large-scale, real-time trusted management of carbon footprints in the industrial chain.

[0024] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0025] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating the steps of a carbon footprint data access verification method provided in an embodiment of this application. Figure 2 This is a flowchart of another carbon footprint data access verification method provided in an embodiment of this application; Figure 3This is a schematic diagram of the structure of a carbon footprint data access verification device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0027] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0028] The carbon footprint data permission verification method, apparatus, device, medium, and product provided in this application will be described in detail below with reference to the accompanying drawings and through specific embodiments and application scenarios.

[0029] To address the challenges of high latency, high resource consumption, and low consistency in current blockchain-based carbon footprint permission verification, which struggles to meet the demands of large-scale, real-time trusted management of industry chain carbon footprints, this application proposes a solution. This solution differentiates transaction requests within carbon footprint data management, assigning each type of carbon footprint data a dedicated contract shard. All permission verification requests for that specific carbon footprint data are routed to the corresponding shard. Each shard independently runs the carbon footprint permission verification contract, creating a Merkle tree for the contract execution results within the shard. The root hash value of the Merkle tree is used to quickly verify result consistency, replacing repetitive execution across all nodes. Through transaction classification routing, dedicated carbon footprint contract shards, and Merkle hash trees, lightweight permission verification achieves highly efficient execution of carbon footprint data permission verification, significantly improving efficiency. This solution can be applied to blockchain-based carbon footprint data management platforms, such as enterprise carbon emission management systems and product carbon footprint traceability platforms, thereby promoting the large-scale implementation of blockchain in the "dual carbon" field.

[0030] Reference Figure 1The flowchart illustrates the steps of a carbon footprint data access verification method provided in an embodiment of this application. The method may include: Step 101: Obtain the user's transaction request for carbon footprint data and determine the target transaction request to be executed for permission verification.

[0031] In this embodiment, the implementation entity is a blockchain-based carbon footprint data management platform, such as an enterprise carbon emission management system or a product carbon footprint traceability platform. No specific limitations are made here. When dozens of entities, including raw material suppliers, manufacturers, logistics providers, and regulatory agencies, request the carbon footprint data management platform to query, store, or modify carbon footprint data, in this embodiment, to ensure the immutability and compliance of the carbon footprint data in the blockchain, when a user needs to modify or update the carbon footprint data, the carbon footprint data management platform uses a smart contract with permission verification to verify the user's right to revise or certify specific carbon footprint data.

[0032] In this embodiment, the carbon footprint data management platform acquires user transaction requests for carbon footprint data and determines the target transaction requests for which permission verification is required. These requests are categorized into ordinary data transactions and contract transactions requiring permission verification. Therefore, this embodiment classifies user transaction requests for carbon footprint data into data transaction requests and contract transaction requests. Data transaction requests are those involving only queries or simple recording of carbon footprint data, and their format can be (User ID, Data Identifier, Operation Type = Query / Record). Contract transaction requests are those requiring permission verification, i.e., those requiring the execution of smart contract logic, and their format can be (User ID, Data Identifier, Contract Address, Operation Type = Revision / Authentication, Aggregate Signature, Attribute Set to be Verified). In this embodiment, upon acquiring a user's transaction request for carbon footprint data, the type of the transaction request is first distinguished, and the contract transaction request within the transaction request is identified as the target transaction request for which permission verification is required.

[0033] Step 102: Based on the pre-determined sharding mapping relationship, determine the target shard corresponding to the target transaction request, and route the target transaction request to the target shard.

[0034] In this embodiment, each type of carbon footprint data is bound to a dedicated shard for processing contract transaction requests. Permission verification requests for carbon footprint data, i.e., target transaction requests, are routed to the corresponding dedicated shard. This shard routing by transaction request category avoids blocking high-frequency verification transactions and meets the real-time requirements of carbon footprint management. Specifically, based on a pre-determined shard mapping relationship, a target shard corresponding to the target transaction request is determined, and the target transaction request is routed to the target shard. The shard mapping relationship is a predefined correspondence between carbon footprint data, transaction requests, and shards. In the blockchain architecture for carbon footprint data management, a shard is a relatively independent parallel processing unit, which can be a partition or microservice cluster in the blockchain. Each shard is used to process transaction requests of a certain type or data range. Each shard maintains its own independent ledger state, such as a permission list and signature verification records for a specific carbon asset. Different shards can process transactions simultaneously, forming parallel, consensus-based processing, which is not specifically limited here.

[0035] In this embodiment, a unique shard identifier is calculated based on the data identifier of the target transaction request. Then, according to the shard mapping relationship, the target shard corresponding to the target transaction request is determined, and the target transaction request is intelligently routed to the target shard for processing. In specific implementation, the data identifier in the transaction request can be a product ID, enterprise ID, etc. For example, if product ID=P001, the transaction hash of the target transaction request can be obtained by hashing the data identifier of the target transaction request. Based on the transaction hash and the predetermined total number of shards to be executed for permission verification, the shard number for processing the target transaction request is determined. Then, according to the predetermined shard mapping relationship and shard number, the target shard corresponding to the target transaction request is determined from the shards to be executed for permission verification, and the target transaction request is routed to the target shard.

[0036] Step 103: Sort the target transaction requests on the target shard to obtain an ordered transaction set. Then, use each node of the target shard to perform permission verification on the target transaction requests in the ordered transaction set in sequence to obtain the verification status of each node of the target shard.

[0037] In this embodiment, the carbon footprint data management platform sorts target transaction requests on the target shard to obtain an ordered transaction set. The ordered transaction set is obtained by arranging contract transaction requests routed to the same shard in sequence. The ordered transaction set includes at least one target transaction request. The ordered transaction set is used by nodes within the shard to reach consensus on the permission verification of the target transaction request through a consensus mechanism, ensuring that nodes within the shard perform permission verification on the target transaction request in the same order. Therefore, after obtaining the ordered transaction set, each node in the target shard sequentially performs permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node in the target shard.

[0038] Step 104: Based on the verification status of each node in the target shard, generate a state tree of the verification status of each node, and determine the root hash value of the state tree of each node.

[0039] In this embodiment of the application, a state tree of the verification status of each node of the target shard is generated based on the verification status of each node, and the root hash value of the state tree of each node is determined. Specifically, the verification status of each node of the target shard is hashed to generate a state tree of the verification status of each node. The verification status includes at least one of user attribute verification progress, aggregate signature verification progress, and permission verification progress. The hash value of the verification status of each node is used as a leaf node to generate a state tree of the verification status of each node. The hash value of the state tree is hashed layer by layer to obtain the root hash value of the state tree of each node.

[0040] In this embodiment, hash calculation can use secure hash algorithms such as SHA-256. The state tree of the verification status of each node can be a Merkle tree. The leaf nodes of the Merkle tree are the hash values ​​of the user attribute verification progress, aggregate signature verification progress, and permission verification progress, such as hash (signature verification result), hash (attribute matching result), and hash (permission determination). Merkle hash verification is used to replace the repeated execution of full nodes, reducing the computational amount of complex aggregate signature verification and reducing on-chain storage and bandwidth overhead.

[0041] Step 105: Determine the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard; wherein the permission verification result includes permission verification passed and permission verification failed.

[0042] In this embodiment, the permission verification result of the target transaction request on the target shard is determined based on the root hash value of each node in the target shard. The verification results are compared to determine if they are consistent, and the final permission verification result of the target transaction request is determined. Specifically, the root hash values ​​of each node in the target shard are broadcast, and nodes with consistent root hash values ​​are identified using pre-determined consensus nodes. The permission verification result of the target transaction request on the target shard is determined based on the number of nodes with consistent root hash values ​​in the target shard. It should be noted that the blockchain consists of a main shard and other shards. Nodes in a shard are divided into main nodes and ordinary nodes. In some embodiments, the shard containing the consensus node is the main shard, or each shard has a main node, with the main node of the main shard serving as the consensus node. The consensus node is the main node of the shard in the blockchain, used to coordinate the consistency of verification results. This embodiment does not specifically limit this.

[0043] Step 106: If the permission verification result is that the permission verification is successful, generate the verification record of the target transaction request and return the permission verification result to the user.

[0044] In this embodiment, if the permission verification result is "permission verification passed," an immutable verification record is generated and the verification result is returned to the user. Specifically, the root hash value of the target shard, the ordered transaction set, and the data identifier of the target transaction request are used to generate a verification record for the target transaction request. The verification record is written to the blockchain where the carbon footprint data is located. The permission verification result is returned to the user, and the verification record is written to the blockchain where the carbon footprint data is located, forming an immutable verification record. The decentralization and immutability of the blockchain ensure the security and trustworthiness of the verification record. The carbon footprint data management platform returns the permission verification result to the user. The permission verification result may include the verification result "permission verification passed" and the root hash value indicating that the verification passed.

[0045] The carbon footprint data permission verification method provided in this application obtains a user's transaction request for carbon footprint data, determines the target transaction request to be verified, determines the target shard corresponding to the target transaction request according to a pre-determined sharding mapping relationship, routes the target transaction request to the target shard, sorts the target transaction requests on the target shard to obtain an ordered transaction set, uses each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set, obtains the verification status of each node of the target shard, generates a state tree of the verification status of each node based on the verification status of each node of the target shard, determines the root hash value of the state tree of each node, determines the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard, generates a verification record of the target transaction request if the permission verification result is successful, and returns the permission verification result to the user. This application embodiment categorizes and segments transaction requests for permission verification, avoiding blocking of high-frequency permission verification requests and meeting the real-time carbon footprint management needs of various industries. All permission verification requests for the same carbon footprint data are executed in a dedicated shard, avoiding the problem of verification errors that can easily occur when synchronizing verification states across shards. The hash value verification of the state tree is used to replace the repeated execution of the entire node, and the permission verification process within the shard is optimized by using hash calculation. The execution result of the permission verification contract for the transaction request is confirmed in a lightweight way, simplifying the execution and verification process of the permission verification contract. This adapts to the complex logic of permission verification for carbon footprint data, improves the execution efficiency of permission verification, and ensures the immutability and compliance of the verification results, thus guaranteeing the credibility of carbon footprint data and meeting the needs of large-scale, real-time trusted management of carbon footprints across the industrial chain.

[0046] In some embodiments of this application, step 101, obtaining a user's transaction request for carbon footprint data and determining the target transaction request to be subject to permission verification, may specifically include the following steps: S11, Obtain the user's transaction request for carbon footprint data, parse the transaction request, and obtain the operation type and data identifier of the transaction request; S12, determine the request type of the transaction request based on the operation type of the transaction request; wherein, the request type of the transaction request includes data transaction request and contract transaction request; S13, the contract transaction request in the transaction request is identified as the target transaction request to be executed for permission verification.

[0047] In this embodiment, a user initiates a carbon footprint management operation. The carbon footprint data management platform obtains the user's transaction request for carbon footprint data, parses the transaction request, and obtains the operation type and data identifier of the transaction request. The transaction request includes data transaction requests and contract transaction requests. Data transaction requests are those involving only querying or simply recording carbon footprint data, while contract transaction requests are those requiring permission verification, i.e., those requiring the execution of smart contract logic. In this embodiment, to distinguish between transaction requests requiring smart contract logic and ordinary data transaction requests, the request type of the transaction request is determined based on the operation type of the transaction request. Contract transaction requests within the transaction requests are identified as the target transaction requests requiring permission verification.

[0048] In its implementation, the carbon footprint data management platform categorizes transaction requests. By parsing the transaction requests, it obtains the operation type and data identifier of the transaction request. For example, the format of a data transaction request can be (User ID, Data Identifier, Operation Type = Query / Record), and the format of a contract transaction request can be (User ID, Data Identifier, Contract Address, Operation Type = Revision / Authentication, Aggregate Signature, Attribute Set to be Verified). After obtaining the operation type of the transaction request, the request type of the transaction request is determined based on the operation type. If the operation type is a query or record without a contract call, the transaction request is a normal data transaction request. If the operation type is a revision or authentication that includes contract address and signature data, the transaction request is a contract transaction request. The contract transaction request in the transaction request is identified as the target transaction request to be executed for permission verification.

[0049] It should be noted that in this embodiment, the shards in the blockchain are pre-divided into general shards and dedicated shards for executing permission verification. The configuration number of the shards for executing permission verification and the general shards is set according to actual needs. For example, 10 general shards (S0) are deployed to handle ordinary data transaction requests, and 100 shards (S1) for executing contract verification are deployed to handle contract transaction requests for carbon footprint data. If the operation type is a query or record without contract call, the transaction request is an ordinary data transaction request, and the transaction request is routed to the general shard for processing. The processing of data transaction requests is not described in detail in this embodiment.

[0050] This application embodiment avoids blocking high-frequency permission verification transaction requests by sharding and classifying permission verification transaction requests, so that all permission verification requests for the same carbon footprint data are executed in a dedicated shard, avoiding the problem of verification errors that are easy to occur when synchronizing verification status across shards.

[0051] In some embodiments of this application, step 102, determining the target shard corresponding to the target transaction request based on a pre-determined shard mapping relationship, and routing the target transaction request to the target shard, may specifically include the following steps: S21, perform hash calculation on the data identifier of the target transaction request to obtain the transaction hash of the target transaction request; S22, determine the shard number for processing the target transaction request based on the transaction hash and the total number of shards to be executed for permission verification in advance; S23, Based on the pre-determined sharding mapping relationship and sharding number, determine the target shard corresponding to the target transaction request from the shards to be executed for permission verification; S24, route the target transaction request to the target shard.

[0052] In this embodiment, to route transaction requests requiring permission verification to the corresponding matching shard so that the permission verification contract can be executed on that shard, and to avoid blocking high-frequency verification transactions by classifying shards and meeting the real-time requirements of carbon footprint management, this embodiment determines the target shard corresponding to the target transaction request according to a pre-determined shard mapping relationship, and routes the target transaction request to the target shard. Specifically, the data identifier of the target transaction request is hashed to obtain the transaction hash of the target transaction request. Each transaction request contains a data identifier, such as a product ID (e.g., P001) or an enterprise ID, which is used to uniquely identify the carbon footprint data involved in the target transaction request. The transaction hash is used to uniquely identify the target transaction request.

[0053] In this embodiment, a hash calculation is performed on the data identifier in the target transaction request. Specifically, the SHA-256 hash function can be used. The purpose of the hash calculation is to convert the data identifier into a fixed-length hash value in order to determine the shard number. Based on the transaction hash and the predetermined total number of shards to be executed for permission verification, the shard number for processing the target transaction request is determined. The shard number is H(data identifier) ​​mod M, where M is the total number of shards to be executed for permission verification, and H is the SHA-256 hash function.

[0054] In this embodiment, the pre-determined shard mapping relationship can be maintained as a mapping table between data identifiers and shards. This can be solidified through on-chain contracts to ensure that the routing rules for verification requests of the same carbon footprint data are consistent across all nodes in the shard. Specifically, based on the pre-determined shard mapping relationship and shard number, the target shard corresponding to the target transaction request can be determined from the shards to be executed for permission verification. The target transaction request is then routed to the target shard. For example, according to the pre-determined shard mapping relationship, shard number 3 corresponds to shard S3. The corresponding shard S3 is found from the shards to be executed for permission verification, and the target transaction request is routed to the determined target shard S3 so that the permission verification contract for the target transaction request can be executed on that target shard.

[0055] This application embodiment routes transaction requests that require permission verification to the corresponding matching shard, so that the permission verification contract can be executed on that shard. This ensures that all permission verification requests for the same carbon footprint data are executed on a dedicated shard, avoiding the problem of verification errors that can easily occur when synchronizing verification status across shards, and improving the efficiency of permission verification execution.

[0056] In some embodiments of this application, step 103, which involves sorting the target transaction requests on the target shard to obtain an ordered transaction set, and then sequentially performing permission verification on the target transaction requests in the ordered transaction set using each node of the target shard to obtain the verification status of each node in the target shard, may specifically include the following steps: S31, obtain the timestamp and transaction hash of the target transaction request on the target shard; S32, Sort the target transaction requests on the target shard according to the timestamp and transaction hash of the target transaction request to obtain an ordered transaction set; S33, Obtain the permission verification contract pre-configured to the shard to be executed for permission verification; S34, based on the permission verification contract, uses each node of the target shard to sequentially perform permission verification on the target transaction request of the ordered transaction set, and obtains the verification status of each node of the target shard.

[0057] In this embodiment, target transaction requests are sorted on the target shard, and the verification status of each node is obtained by sequentially executing the permission verification contract within each shard. Specifically, the carbon footprint data management platform obtains the timestamps and transaction hashes of the target transaction requests on the target shard. Each target transaction request contains a timestamp to identify its reception time, and the transaction hash is calculated by hashing the data identifier of the target transaction request to uniquely identify it. Based on the timestamps and transaction hashes, the target transaction requests on the target shard are sorted to obtain an ordered transaction set. First, they are sorted by timestamp to ensure they are arranged in order of reception time. If timestamps are the same, they are sorted by transaction hash to ensure that the order of transaction requests is determined when timestamps are the same. The ordered transaction set is the sorted set of transaction requests, which can be denoted as... ,in It is the first target transaction request on the target shard. It is the last target transaction request on the target shard.

[0058] In this embodiment, a pre-configured permission verification contract is obtained for the shard to be verified. This permission verification contract is a smart contract pre-configured on the target shard and is used to execute permission verification logic, such as aggregate signature verification and attribute permission matching. Each shard has a pre-configured permission verification contract; the contract code and permission verification logic are loaded when the shard starts. Based on the permission verification contract, each node of the target shard sequentially performs permission verification on the target transaction requests of the ordered transaction set, thus obtaining the verification status of each node in the target shard.

[0059] It should be noted that the sequential permission verification performed by each node on the target transaction request of the ordered transaction set may include aggregate signature verification, attribute permission matching, and permission grant determination. Aggregate signature verification verifies the validity of the aggregate signature in the target transaction request. Attribute permission matching checks whether the user attributes in the target transaction request satisfy the permission policy, such as an AND gate policy. Permission grant determination, based on aggregate signature verification and attribute permission matching, determines whether to grant permission to the target transaction request. The verification status is the state of each node in executing the permission verification contract, and includes at least one of the following: user attribute verification progress, aggregate signature verification progress, and permission verification progress.

[0060] This application embodiment sorts transaction requests on the same shard to ensure that all nodes in the target shard perform permission verification in the same order and generate a consistent verification status, thereby achieving efficient and consistent permission verification.

[0061] As a specific implementation of this application embodiment, step S34, based on the permission verification contract, uses each node of the target shard to sequentially perform permission verification on the target transaction request in the ordered transaction set, and obtains the verification status of each node of the target shard, which may specifically include the following steps: Sub-step 01: Obtain the user attributes and aggregate signature of the target transaction request; Sub-step 02: Based on the permission verification contract, each node of the target shard sequentially performs user attribute verification and aggregate signature verification on the target transaction request of the ordered transaction set. Sub-step 03: Based on whether the user attributes of the target transaction request match the preset AND gate policy and the validity of the aggregated signature, obtain the verification status of each node of the target shard.

[0062] In this embodiment, to perform permission verification on a target transaction request, the user attributes and aggregate signature of the target transaction request are obtained. Specifically, the target transaction request includes user attributes and an aggregate signature. Based on the permission verification contract, each node of the target shard sequentially performs user attribute verification and aggregate signature verification on the target transaction request of the ordered transaction set. The user attributes are used for matching the permission verification contract. For example, user attributes include user roles, permission levels, etc. The aggregate signature is used to verify the legality of the target transaction request. The aggregate signature is a combination of multiple signatures. Each node of the target shard sequentially performs permission verification on the target transaction request of the ordered transaction set according to the order of the ordered transaction set.

[0063] In this embodiment, user attribute verification checks whether user attributes meet a preset permission policy, such as an AND gate policy. An AND gate policy requires user attributes to meet multiple conditions simultaneously, such as having an administrator role and a high-level permission level. This embodiment does not specifically limit this. Aggregate signature verification verifies the validity of the aggregate signature, ensuring the legitimacy of the transaction request. An aggregate signature is typically composed of multiple signatures. Verification requires checking the validity of all signatures. Based on whether the user attributes of the target transaction request match the preset AND gate policy and the validity of the aggregate signature, the verification status of each node in the target shard is obtained. In one specific implementation of this embodiment, user attribute verification involves matching user attributes with a preset AND gate policy. If the user attributes in the target transaction request satisfy the preset AND gate policy, the user attribute verification passes; otherwise, it fails. Aggregate signature verification passes if the target transaction request is valid, and fails if it fails. Each node generates a verification status based on the results of user attribute verification and aggregate signature verification. The verification status can include the user attribute verification result, the aggregate signature verification result, and the permission granting result, which can be either granted or denied.

[0064] According to the permission verification contract, all nodes within the target shard consistently perform permission verification and generate a consistent verification status, avoiding the problem of verification errors that are easy to occur when synchronizing verification status across shards, and improving the execution efficiency of permission verification.

[0065] In some embodiments of this application, step 104, generating a state tree of the verification status of each node based on the verification status of each node in the target shard, and determining the root hash value of the state tree of each node, may specifically include the following steps: S41, perform hash calculation on the verification status of each node of the target shard to generate a state tree of the verification status of each node; the verification status includes at least one of user attribute verification progress, aggregate signature verification progress and permission verification progress. S42, perform hash calculations on the hash values ​​of the state tree layer by layer to obtain the root hash value of the state tree for each node.

[0066] In this embodiment, the verification status of each node in the target shard is hashed to generate a state tree of the verification status of each node. The verification status includes at least one of user attribute verification progress, aggregate signature verification progress, and permission verification progress. For example, whether the user attributes satisfy the AND gate policy, the number of verified signatures (e.g., 5 / 5 signatures have been verified), and the permission grant result (grant or deny). In this embodiment, the verification status of each node is hashed to generate a hash value. The hash value of the verification status of each node is used as a leaf node to generate a state tree of the verification status of each node. The hash value of the state tree is hashed layer by layer to obtain the root hash value of the state tree of each node.

[0067] It's important to note that the hash function can use secure hash algorithms such as SHA-256, and the state tree for each node's verification status can be a Merkle tree. The leaf nodes of the Merkle tree are the hash values ​​of the verification status, and the intermediate nodes are the combined hash values ​​of adjacent leaf nodes. Using Merkle hash verification replaces the repeated execution of full node verification, reducing the computational load of complex aggregate signature verification and lowering on-chain storage and bandwidth overhead. Specifically, the hash values ​​of the state tree are hashed layer by layer to obtain the root hash value of each node's state tree. Starting from the leaf nodes, the hash values ​​of intermediate nodes are calculated layer by layer. For each pair of adjacent leaf nodes, their combined hash value is calculated and used as the parent node. This process is repeated until the root hash value is generated. The root hash value, denoted as Rooti, ​​is used to quickly verify the consistency of the entire state tree. The root hash value is the unique identifier of the entire state tree; any change in the verification status of any node will cause a change in the root hash value.

[0068] This application embodiment uses the hash value verification of the state tree to replace the repeated execution of the entire node. It uses hash calculation to optimize the permission verification process within the shard, ensuring that each node in the target shard can quickly determine the consistency of the verification state through the hash structure and generate a unique root hash value, thereby achieving efficient state verification and consistency check.

[0069] In some embodiments of this application, step 105, determining the permission verification result of the target transaction request on the target shard based on the root hash value of each node in the target shard, may specifically include the following steps: S51, broadcast the root hash value of each node in the target shard, and use a pre-determined consensus node to identify the node with the same root hash value; S52, determine the permission verification result of the target transaction request on the target shard based on the number of nodes with the same root hash value in the target shard.

[0070] In this embodiment, the permission verification result of the target transaction request on the target shard is determined based on the root hash value of each node in the target shard. Specifically, the root hash value Rooti of each node in the target shard is compared to determine whether the verification results are consistent, and the permission verification result of the target transaction request is finally determined. Specifically, the root hash value of each node in the target shard is broadcast, and nodes with consistent root hash values ​​are identified by a pre-determined consensus node. The permission verification result of the target transaction request on the target shard is determined based on the number of nodes with consistent root hash values ​​in the target shard.

[0071] In the specific implementation, each node within the target shard broadcasts its generated root hash value (Rooti) to other nodes, allowing all nodes to compare their root hash values ​​and determine if the verification results are consistent. The consensus node, acting as the master node of the shard in the blockchain, coordinates the consistency of the verification results. Pre-determined consensus nodes collect the root hash values ​​of all nodes, compare them, and identify nodes with identical root hash values. Nodes with the same root hash value indicate that their verification status is consistent. Based on the number of nodes with consistent root hash values ​​in the target shard, the permission verification result for the target transaction request on the target shard is determined. Specifically, the number of nodes with consistent root hash values ​​in the target shard is counted, and the majority rule is used to determine whether the verification results are consistent.

[0072] This application's embodiments employ hash calculation to optimize the intra-shard permission verification process, confirming the execution result of the permission verification contract for transaction requests in a lightweight manner, simplifying the execution and verification process of the permission verification contract, and adapting to the complex logic of permission verification for carbon footprint data.

[0073] Specifically, S52 determines the permission verification result of the target transaction request on the target shard based on the number of nodes with the same root hash value in the target shard. This may include: Sub-step 01: If the number of nodes with the same root hash value in the target shard exceeds the preset proportion of the total number of nodes in the target shard, then the consistent root hash value is taken as the root hash value of the target shard, and the permission verification result of the target transaction request on the target shard is determined to be permission verification passed. Sub-step 02: Otherwise, determine that the permission verification result of the target transaction request on the target shard is "permission verification failed".

[0074] In this embodiment, the permission verification result of the target transaction request on the target shard is determined based on the number of nodes with the same root hash value in the target shard. A majority rule can be used to determine whether the verification results are consistent. Specifically, if the number of nodes with the same root hash value in the target shard exceeds a preset proportion of the total number of nodes in the target shard, the consistent root hash value is taken as the root hash value of the target shard, and the permission verification result of the target transaction request on the target shard is determined to be successful. The preset proportion can be set and adjusted according to actual needs. For example, the preset proportion is usually a majority rule such as 2 / 3, used to determine whether the verification results are consistent, that is, at least 2 out of a total of 3 nodes have the same root hash value. If the number of nodes with the same root hash value exceeds the preset proportion, the root hash value is taken as the root hash value of the target shard, denoted as Rootm, and the permission verification result of the target transaction request on the target shard is determined to be successful. Otherwise, if the number of nodes with the same root hash value does not reach the preset proportion, the permission verification result of the target transaction request on the target shard is determined to be unsuccessful. Unsuccessful verification indicates that the permission verification logic of the target transaction request is inconsistently executed on a majority of nodes, and the verification result is unreliable.

[0075] This application embodiment quickly determines the correctness of the verification result by comparing the root hash value, confirms the execution result of the permission verification contract for the transaction request in a lightweight manner, simplifies the execution and verification process of the permission verification contract, improves the efficiency of permission verification execution, and ensures the immutability and compliance of the verification result.

[0076] In some embodiments of this application, after determining that the permission verification result of the target transaction request on the target shard is that the permission verification fails, sub-step 02 may further include: Sub-step 03: Identify nodes in the target shard whose root hash values ​​are inconsistent as abnormal nodes in the target shard. Sub-step 04: Obtain the state tree of the abnormal node. Based on the state tree of the abnormal node, verify the actual situation of the abnormal node's execution permission verification and obtain the abnormal verification result of the target shard.

[0077] In this embodiment, nodes with inconsistent root hash values ​​in the target shard are identified as abnormal nodes in the target shard. Abnormal nodes that fail verification may have malicious behavior or execution errors, and it is necessary to investigate the reasons for the verification failure. Therefore, after determining that the permission verification result of the target transaction request on the target shard is that the permission verification fails, nodes with inconsistent root hash values ​​in the target shard are identified as abnormal nodes in the target shard. The state tree of the abnormal node is obtained, and the actual situation of the abnormal node's permission verification is verified based on the state tree of the abnormal node. For example, based on the Merkle tree path provided by the abnormal node, its execution process is re-verified, such as whether the signature verification steps are correct, etc., to exclude malicious nodes and obtain the abnormal verification result of the target shard.

[0078] Based on the permission verification results, this application embodiment verifies and investigates abnormal nodes that may have malicious behavior or execution errors, so as to provide users with clear verification result feedback, thereby realizing an efficient and secure permission verification process.

[0079] In some embodiments of this application, step 106, if the permission verification result is successful, generates a verification record for the target transaction request and returns the permission verification result to the user, may specifically include the following steps: S61, if the permission verification result is that the permission verification is successful, generate the verification record of the target transaction request by taking the root hash value of the target shard, the ordered transaction set and the data identifier of the target transaction request; S62 writes the verification record to the blockchain where the carbon footprint data is located, and returns the permission verification result to the user.

[0080] In this embodiment, if the permission verification result is successful, an immutable verification record is generated and the verification result is returned to the user. Specifically, the root hash value of the target shard, the ordered transaction set, and the data identifier of the target transaction request are used to generate a verification record for the target transaction request. The root hash value Rootm of the target shard is used to uniquely identify the verification status of the target shard. The ordered transaction set T is used to associate the verification record with the specific transaction request. The data identifier of the target transaction request is a unique identifier of the target transaction request (such as a transaction ID) used to associate the verification record with the specific transaction request. The generation of the verification record ensures the traceability and immutability of the verification result.

[0081] In this embodiment, the verification record is written to the blockchain where the carbon footprint data is located, and the permission verification result is returned to the user. The verification record is written to the blockchain where the carbon footprint data is located to form an immutable verification record. The decentralization and immutability of the blockchain ensure the security and trustworthiness of the verification record. The carbon footprint data management platform returns the permission verification result to the user. The permission verification result may include the verification result of permission verification passed and the root hash value Rootm, which is used by the user to verify the correctness of the verification result.

[0082] The embodiments of this application ensure the reliability and immutability of the permission verification results, while providing users with clear feedback on the verification results, thereby realizing an efficient and secure permission verification process.

[0083] Reference Figure 2 The diagram illustrates a flowchart of another carbon footprint data access control method provided in this application embodiment. The method may further include: Step 201: If the target transaction request to be executed for permission verification is associated with at least two types of carbon footprint data, generate a joint transaction request; Step 202: Determine the shards for executing joint trading requests on various types of carbon footprint data; Step 203: Route the joint transaction request to the corresponding shards of various carbon footprint data and obtain the permission verification results of the shards that execute the joint transaction request; Step 204: If the permission verification result of the joint transaction request is that the permission verification is passed, the joint transaction request is determined to be valid, and the permission verification result of the joint transaction request is returned to the user.

[0084] In this embodiment of the application, when the target transaction request involves multiple types of carbon footprint data, such as joint emission data from upstream and downstream of the industrial chain, cross-segment joint verification is required. Specifically, when the target transaction request to be verified is associated with at least two types of carbon footprint data, a joint transaction request is generated. The purpose of joint verification is to ensure that the verification results of multiple types of carbon footprint data are consistent, thereby confirming the validity of the joint permissions.

[0085] In this embodiment, a master shard can be determined among the shards that perform permission verification in the blockchain, and a joint transaction request can be generated. The joint verification request is used to coordinate the verification process of each associated shard. The joint verification request may include a list of data identifiers to be verified and a Merkle root for local verification. The list of data identifiers to be verified is a unique identifier of the multiple types of carbon footprint data associated with the target transaction request, such as ID_P002, ID_P003, etc. The Merkle root for local verification is the root hash value of the Merkle state tree generated by the master shard after performing permission verification on the local carbon footprint data.

[0086] In this embodiment, the shards for executing joint trading requests on various types of carbon footprint data are determined. Based on the list of data identifiers to be verified, the shards to which each type of carbon footprint data belongs are determined. For example, carbon footprint data P002 belongs to shard S2, and carbon footprint data P003 belongs to shard S3. Each shard is used to execute joint trading requests on its own carbon footprint data and generate verification results such as Merkle roots. Therefore, the joint trading requests are routed to the corresponding shards for each type of carbon footprint data to obtain the permission verification results of the shard executing the joint trading request. For example, the joint trading requests are routed to each associated shard through the main shard, allowing each shard to perform permission verification on its own carbon footprint data. After receiving the joint trading request, each shard performs permission verification on its own carbon footprint data. The permission verification process for each shard is similar to the preceding steps, including user attribute verification, aggregate signature verification, and permission grant determination. After verification, each shard generates its verification results, such as Merkle roots Root2, Root3, etc., and returns the generated Merkle roots to the main shard.

[0087] In the specific implementation, if the permission verification result of the joint transaction request is successful, the joint transaction request is deemed valid, and the permission verification result is returned to the user. Specifically, the primary shard receives the verification results from each shard, such as Root2, Root3, etc. The primary shard aggregates the Merkle roots of all shards to generate a global Merkle root. Aggregation involves using the Merkle roots of each shard as leaf nodes to construct a new Merkle tree, generating the global Merkle root. If the consistency verification of the global Merkle root is successful (e.g., the Merkle roots of all shards are consistent), the permission verification result of the joint transaction request is deemed successful. Successful verification indicates that the permission verification results for multiple types of carbon footprint data have all passed, thus the joint transaction request is valid, and the permission verification result of the joint transaction request is returned to the user. The permission verification result of the joint transaction request may include the verification result of successful permission verification and the global Merkle root.

[0088] This application's embodiments handle joint permission verification involving multiple types of carbon footprint data, ensuring consistent permission verification results across different types of carbon footprint data. It also generates immutable verification records through a global state tree, thereby achieving efficient and secure cross-shard joint verification. This meets the permission verification needs of multiple entities and complex logic, optimizes contract execution and verification processes, and supports large-scale collaboration at the industry chain level.

[0089] In some embodiments of this application, step 203, which routes the joint transaction request to the corresponding shards of various carbon footprint data and obtains the permission verification result of the shard executing the joint transaction request, may specifically include the following steps: S71, determine the main shard from the shards, and route the joint transaction request to the shards corresponding to various carbon footprint data; S72, use sharding to perform permission verification on the joint transaction request and determine the root hash value of the state tree for sharding permission verification; S73, aggregate the root hash value of the shard to the main shard to obtain the permission verification result of the shard that executes the federated transaction request.

[0090] In this embodiment, a master shard is determined from the shards, and the joint transaction request is routed to the shards corresponding to various carbon footprint data. The master shard can be used as the shard that initiates the joint verification request, such as S1. The master shard coordinates the entire joint verification process, including routing the joint transaction request to each shard and aggregating verification results. Specifically, after receiving the joint transaction request, each shard performs permission verification on its exclusive carbon footprint data. The shard performs permission verification on the joint transaction request and determines the root hash value of the state tree of the shard performing permission verification. The verification process includes user attribute verification, aggregated signature verification, and permission grant determination. After verification, each shard generates a state tree of its verification status. The root hash value of the state tree, such as Root2 and Root3, is used to represent the verification result of the shard.

[0091] In this embodiment, the root hash values ​​of the shards are aggregated to the primary shard to obtain the permission verification result of the shard executing the federated transaction request. Each shard returns its generated state tree root hash value to the primary shard. The primary shard aggregates the root hash values ​​of all shards to generate the root hash value of the global Merkle state tree. Based on the aggregated root hash value of the global Merkle state tree, the permission verification result of the federated transaction request is determined. If the consistency verification of the root hash value of the global Merkle state tree passes, that is, the root hash values ​​of all shards are consistent, then the permission verification result of the shard executing the federated transaction request is that the permission verification has passed.

[0092] This application embodiment aggregates the root hash values ​​of the shards that execute the federated transaction request to generate the root hash value of the global Merkle state tree, so as to efficiently verify the validity of the federated authorization verification and realize efficient and secure cross-shard federated verification.

[0093] In some embodiments of this application, step S73, which aggregates the root hash value of the shard to the primary shard to obtain the permission verification result of the shard executing the federated transaction request, may specifically include: Sub-step 01: Aggregate the root hash values ​​of the shards to the main shard, and identify the number of shards with the same root hash value in the main shard; Sub-step 02: Based on the number of shards with the same root hash value, obtain the permission verification result of the shard that executes the federated transaction request.

[0094] In this embodiment, each shard returns its generated state tree root hash value to the master shard. The master shard aggregates the root hash values ​​of all shards, identifies the number of shards with the same root hash value, and obtains the permission verification result of the shard executing the federated transaction request based on the number of shards with the same root hash value. Specifically, a new global Merkle state tree is constructed using the root hash value of each shard as a leaf node. During the aggregation process, it identifies whether the root hash values ​​of each shard are consistent, counts the number of shards with the same root hash value, and obtains the permission verification result of the shard executing the federated transaction request based on the number of shards with the same root hash value. If the root hash values ​​of all shards are consistent, the permission verification result of the shard executing the federated transaction request is considered successful.

[0095] In some embodiments of this application, step 204, where the authorization verification result of the joint transaction request is successful, determines that the joint transaction request is valid and returns the authorization verification result of the joint transaction request to the user, may specifically include the following steps: S81, if the authorization verification result of the joint transaction request is that the authorization verification is passed, the joint transaction request is determined to be valid and a verification record of the joint transaction request is generated; S82 writes the verification record of the joint transaction request to the blockchain where various carbon footprint data are located, and returns the permission verification result of the joint transaction request to the user.

[0096] In this embodiment, if the permission verification result of the joint transaction request is successful, the joint transaction request has passed the consensus verification between shards, and the verification status of each shard is consistent. Therefore, it can be determined that the joint transaction request is valid, and a verification record for the joint transaction request is generated. The verification record may include a list of data identifiers for the joint transaction request, the permission verification result, information about each shard, and the root hash value of the global state tree. The verification record is written to the blockchain related to the carbon footprint data, and the permission verification result of the joint transaction request is returned to the user who initiated the transaction.

[0097] The embodiments of this application ensure the credibility and immutability of the permission verification results of the joint transaction request, while providing users with clear feedback on the verification results, thereby achieving efficient and secure cross-shard permission verification.

[0098] Reference Figure 3 The diagram shows a structural schematic of a carbon footprint data access verification device provided in an embodiment of this application. The device includes: The request acquisition module 301 is used to acquire user transaction requests for carbon footprint data and determine the target transaction request to be executed for permission verification. Shard mapping module 302 is used to determine the target shard corresponding to the target transaction request according to a pre-determined shard mapping relationship, and route the target transaction request to the target shard; The permission verification module 303 is used to sort the target transaction requests on the target shard to obtain an ordered transaction set, and use each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. The state tree generation module 304 is used to generate a state tree of the verification status of each node based on the verification status of each node of the target shard, and to determine the root hash value of the state tree of each node. The result determination module 305 is used to determine the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard; wherein, the permission verification result includes permission verification passed and permission verification failed; The return result module 306 is used to generate a verification record for the target transaction request and return the permission verification result to the user if the permission verification result is that the permission verification is passed.

[0099] Optionally, the request acquisition module 301 includes: The first acquisition submodule is used to acquire user transaction requests for carbon footprint data, parse the transaction requests, and obtain the operation type and data identifier of the transaction requests; The first determining submodule is used to determine the request type of the transaction request based on the operation type of the transaction request; wherein, the request type of the transaction request includes data transaction request and contract transaction request; The second determination submodule is used to determine the contract transaction request in the transaction request as the target transaction request to be executed for permission verification.

[0100] Optionally, the sharding mapping module 302 includes: The first hash submodule is used to perform hash calculation on the data identifier of the target transaction request to obtain the transaction hash of the target transaction request; The third determining submodule is used to determine the shard number for processing the target transaction request based on the transaction hash and the pre-determined total number of shards to be executed for permission verification. The fourth determination submodule is used to determine the target shard corresponding to the target transaction request from the shards to be executed for permission verification, based on the pre-determined shard mapping relationship and the shard number. The first routing submodule is used to route the target transaction request to the target shard.

[0101] Optionally, the permission verification module 303 includes: The second acquisition submodule is used to acquire the timestamp and transaction hash of the target transaction request on the target shard. The sorting submodule is used to sort the target transaction requests on the target shard according to the timestamp and transaction hash of the target transaction request to obtain an ordered transaction set; The third acquisition submodule is used to acquire the permission verification contract pre-configured to the shard to be executed for permission verification; The first verification submodule is used to verify the permissions of the target transaction requests of the ordered transaction set sequentially by each node of the target shard based on the permission verification contract, thereby obtaining the verification status of each node of the target shard.

[0102] Optionally, the first verification submodule includes: The acquisition unit is used to acquire the user attributes and aggregate signature of the target transaction request; The first verification unit is used to verify the contract based on the permissions, and to perform user attribute verification and aggregate signature verification sequentially on the target transaction requests of the ordered transaction set using each node of the target shard. The second verification unit is used to obtain the verification status of each node of the target shard based on whether the user attributes of the target transaction request match the preset AND gate policy and the validity of the aggregate signature.

[0103] Optionally, the state tree generation module 304 includes: The second hash submodule is used to perform hash calculation on the verification status of each node of the target shard to generate a state tree of the verification status of each node; the verification status includes at least one of user attribute verification progress, aggregate signature verification progress and permission verification progress. The third hash submodule is used to perform hash calculations on the hash values ​​of the state tree layer by layer to obtain the root hash value of the state tree of each node.

[0104] Optionally, the result determination module 305 includes: The broadcast submodule is used to broadcast the root hash value of each node of the target shard, and to identify the node with the same root hash value using a pre-determined consensus node. The fifth determination submodule is used to determine the permission verification result of the target transaction request on the target shard based on the number of nodes with the same root hash value in the target shard.

[0105] Optionally, the fifth determining submodule includes: The first determining unit is configured to, if the number of nodes with the same root hash value in the target shard exceeds a preset proportion of the total number of nodes in the target shard, take the consistent root hash value as the root hash value of the target shard and determine that the permission verification result of the target transaction request on the target shard is permission verification passed. The second determining unit is used to determine, otherwise, that the permission verification result of the target transaction request on the target shard is that the permission verification fails.

[0106] Optionally, the fifth determining submodule further includes: The third determining unit is used to determine the nodes in the target shard whose root hash values ​​are inconsistent as abnormal nodes of the target shard. An anomaly verification unit is used to obtain the state tree of the anomaly node, verify the actual situation of the anomaly node performing permission verification based on the state tree of the anomaly node, and obtain the anomaly verification result of the target shard.

[0107] Optionally, the result return module 306 includes: The first generation submodule is used to generate a verification record for the target transaction request by taking the root hash value of the target shard, the ordered transaction set, and the data identifier of the target transaction request when the permission verification result is that the permission verification is passed. The first result submodule is used to write the verification record into the blockchain where the carbon footprint data is located, and to return the permission verification result to the user.

[0108] Optionally, the device further includes: The joint request module is used to generate a joint transaction request when the target transaction request to be executed for permission verification is associated with at least two types of carbon footprint data; The sharding module is used to determine the shards for executing the joint transaction request on each type of carbon footprint data; The joint verification module is used to route the joint transaction request to the corresponding shards of various types of carbon footprint data and obtain the permission verification result of the shard that executes the joint transaction request; The module for returning joint verification results is used to determine that the joint transaction request is valid if the permission verification result of the joint transaction request is that the permission verification is passed, and to return the permission verification result of the joint transaction request to the user.

[0109] Optionally, the joint verification module includes: The second routing submodule is used to determine the main shard from the shards and route the joint transaction request to the shards corresponding to the various types of carbon footprint data; The second verification submodule uses the shard to perform permission verification on the joint transaction request and determines the root hash value of the state tree for the shard to perform permission verification. The aggregation submodule is used to aggregate the root hash value of the shard to the main shard to obtain the permission verification result of the shard that executes the federated transaction request.

[0110] Optionally, the aggregation submodule includes: An aggregation unit is used to aggregate the root hash values ​​of the shards to the main shard, and to identify the number of shards with the same root hash values ​​in the main shard. The fourth determining unit is used to obtain the permission verification result of the shard that executes the joint transaction request based on the number of shards with consistent root hash values ​​in the shards.

[0111] Optionally, the module for returning joint verification results includes: The second generation submodule is used to determine that the joint transaction request is valid and generate a verification record for the joint transaction request if the permission verification result of the joint transaction request is that the permission verification is passed. The second return submodule is used to write the verification record of the joint transaction request into the blockchain where the various types of carbon footprint data are located, and to return the permission verification result of the joint transaction request to the user.

[0112] The carbon footprint data permission verification device provided in this application obtains a user's transaction request for carbon footprint data, determines the target transaction request to be verified, determines the target shard corresponding to the target transaction request according to a pre-determined sharding mapping relationship, routes the target transaction request to the target shard, sorts the target transaction requests on the target shard to obtain an ordered transaction set, uses each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set, obtains the verification status of each node of the target shard, generates a state tree of the verification status of each node based on the verification status of each node of the target shard, determines the root hash value of the state tree of each node, determines the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard, generates a verification record of the target transaction request if the permission verification result is successful, and returns the permission verification result to the user. This application embodiment categorizes and segments transaction requests for permission verification, avoiding blocking of high-frequency permission verification requests and meeting the real-time carbon footprint management needs of various industries. All permission verification requests for the same carbon footprint data are executed in a dedicated shard, avoiding the problem of verification errors that can easily occur when synchronizing verification states across shards. The hash value verification of the state tree is used to replace the repeated execution of the entire node, and the permission verification process within the shard is optimized by using hash calculation. The execution result of the permission verification contract for the transaction request is confirmed in a lightweight way, simplifying the execution and verification process of the permission verification contract. This adapts to the complex logic of permission verification for carbon footprint data, improves the execution efficiency of permission verification, and ensures the immutability and compliance of the verification results, thus guaranteeing the credibility of carbon footprint data and meeting the needs of large-scale, real-time trusted management of carbon footprints across the industrial chain.

[0113] Reference Figure 4 This application also provides an electronic device, such as... Figure 4 As shown, it includes a processor 401, a communication interface 402, a memory 403, and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404. Processor 401, memory 403 for storing processor-executable instructions; The processor 401 is configured to execute the instructions to implement the carbon footprint data access verification method as described below: Obtain user transaction requests for carbon footprint data and determine the target transaction requests for which permission verification needs to be performed; Based on a pre-determined sharding mapping relationship, the target shard corresponding to the target transaction request is determined, and the target transaction request is routed to the target shard. The target transaction requests on the target shard are sorted to obtain an ordered transaction set. The nodes of the target shard sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. Based on the verification status of each node in the target shard, generate a state tree of the verification status of each node, and determine the root hash value of the state tree of each node. Based on the root hash value of each node in the target shard, the permission verification result of the target transaction request on the target shard is determined; wherein, the permission verification result includes permission verification passed and permission verification failed; If the permission verification result is successful, a verification record for the target transaction request is generated, and the permission verification result is returned to the user.

[0114] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0115] The communication interface is used for communication between the aforementioned terminal and other devices.

[0116] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0117] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0118] In another embodiment provided in this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the carbon footprint data permission verification method described in any of the above embodiments.

[0119] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0120] In another embodiment of this application, a computer program product is also provided, including a program or instructions that, when executed by a processor, implement the steps in the carbon footprint data access verification method described in any of the above embodiments of this application.

[0121] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0122] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0123] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for verifying carbon footprint data access rights, characterized in that, The method includes: Obtain user transaction requests for carbon footprint data and determine the target transaction requests for which permission verification needs to be performed; Based on a pre-determined sharding mapping relationship, the target shard corresponding to the target transaction request is determined, and the target transaction request is routed to the target shard. The target transaction requests on the target shard are sorted to obtain an ordered transaction set. The nodes of the target shard sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. Based on the verification status of each node in the target shard, generate a state tree of the verification status of each node, and determine the root hash value of the state tree of each node. Based on the root hash value of each node in the target shard, the permission verification result of the target transaction request on the target shard is determined; wherein, the permission verification result includes permission verification passed and permission verification failed; If the permission verification result is successful, a verification record for the target transaction request is generated, and the permission verification result is returned to the user.

2. The method according to claim 1, characterized in that, The step of obtaining user transaction requests for carbon footprint data and determining the target transaction request to be executed for permission verification includes: Obtain user transaction requests for carbon footprint data, parse the transaction requests, and obtain the operation type and data identifier of the transaction requests; The request type of the transaction request is determined based on the operation type of the transaction request; wherein, the request type of the transaction request includes data transaction requests and contract transaction requests; The contract transaction request in the transaction request is identified as the target transaction request to be executed for permission verification.

3. The method according to claim 2, characterized in that, The step of determining the target shard corresponding to the target transaction request based on a pre-determined sharding mapping relationship, and routing the target transaction request to the target shard, includes: The data identifier of the target transaction request is hashed to obtain the transaction hash of the target transaction request; The shard number for processing the target transaction request is determined based on the transaction hash and the predetermined total number of shards to be executed for permission verification. Based on the pre-determined sharding mapping relationship and the sharding number, the target shard corresponding to the target transaction request is determined from the shards to be executed for permission verification; The target transaction request is routed to the target shard.

4. The method according to claim 1, characterized in that, The process of sorting the target transaction requests on the target shard to obtain an ordered transaction set, and then sequentially performing permission verification on the target transaction requests in the ordered transaction set using each node of the target shard to obtain the verification status of each node of the target shard, includes: Obtain the timestamp and transaction hash of the target transaction request on the target shard; Based on the timestamp and transaction hash of the target transaction request, the target transaction requests on the target shard are sorted to obtain an ordered transaction set; Obtain the pre-configured permission verification contract for the shard to be executed for permission verification; Based on the permission verification contract, each node of the target shard sequentially performs permission verification on the target transaction request of the ordered transaction set to obtain the verification status of each node of the target shard.

5. The method according to claim 4, characterized in that, Based on the permission verification contract, the nodes of the target shard sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node in the target shard, including: Obtain the user attributes and aggregate signature of the target transaction request; Based on the permission verification contract, each node of the target shard sequentially performs user attribute verification and aggregate signature verification on the target transaction request of the ordered transaction set. The verification status of each node in the target shard is obtained based on whether the user attributes of the target transaction request match the preset AND gate policy and the validity of the aggregated signature.

6. The method according to claim 1, characterized in that, The step of generating a state tree of the verification status of each node based on the verification status of each node in the target shard, and determining the root hash value of the state tree of each node, includes: The verification status of each node in the target shard is hashed to generate a state tree of the verification status of each node; the verification status includes at least one of user attribute verification progress, aggregate signature verification progress, and permission verification progress. The hash values ​​of the state tree are hashed layer by layer to obtain the root hash value of the state tree for each node.

7. The method according to claim 1, characterized in that, The step of determining the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard includes: The root hash value of each node in the target shard is broadcast, and a pre-determined consensus node is used to identify the node with the same root hash value. The permission verification result of the target transaction request on the target shard is determined based on the number of nodes with the same root hash value in the target shard.

8. The method according to claim 7, characterized in that, The step of determining the permission verification result of the target transaction request on the target shard based on the number of nodes with the same root hash value in the target shard includes: If the number of nodes with the same root hash value in the target shard exceeds a preset proportion of the total number of nodes in the target shard, then the consistent root hash value is taken as the root hash value of the target shard, and the permission verification result of the target transaction request on the target shard is determined to be permission verification passed. Otherwise, the permission verification result of the target transaction request on the target shard is determined to be permission verification failure.

9. The method according to claim 8, characterized in that, Otherwise, after determining that the permission verification result of the target transaction request on the target shard is that the permission verification fails, the method further includes: Nodes in the target shard whose root hash values ​​are inconsistent are identified as abnormal nodes in the target shard. Obtain the state tree of the abnormal node, and verify the actual situation of the abnormal node performing permission verification based on the state tree of the abnormal node to obtain the abnormal verification result of the target shard.

10. The method according to claim 1, characterized in that, If the permission verification result is successful, generating a verification record for the target transaction request and returning the permission verification result to the user includes: If the permission verification result is that the permission verification is successful, the root hash value of the target shard, the ordered transaction set, and the data identifier of the target transaction request are used to generate the verification record of the target transaction request; The verification record is written to the blockchain containing the carbon footprint data, and the permission verification result is returned to the user.

11. The method according to claim 1, characterized in that, The method further includes: If the target transaction request awaiting authorization verification is associated with at least two types of carbon footprint data, a joint transaction request is generated. Determine the shards for executing the joint transaction request for each type of carbon footprint data; The joint transaction request is routed to the corresponding shards of the various types of carbon footprint data, and the permission verification result of the shard executing the joint transaction request is obtained; If the permission verification result of the joint transaction request is that the permission verification is passed, the joint transaction request is determined to be valid, and the permission verification result of the joint transaction request is returned to the user.

12. The method according to claim 11, characterized in that, The step of routing the joint transaction request to the corresponding shards of various types of carbon footprint data and obtaining the permission verification result of the shard executing the joint transaction request includes: The primary shard is determined from the shards, and the joint transaction request is routed to the shards corresponding to the various types of carbon footprint data; The sharding is used to perform permission verification on the joint transaction request, and the root hash value of the state tree for the permission verification of the shard is determined. The root hash value of the shard is aggregated into the main shard to obtain the permission verification result of the shard that executes the federated transaction request.

13. The method according to claim 12, characterized in that, The step of aggregating the root hash value of the shard to the primary shard to obtain the permission verification result of the shard executing the federated transaction request includes: The root hash values ​​of the shards are aggregated into the main shard, and the number of shards with the same root hash value is identified in the main shard. Based on the number of shards with the same root hash value in the shards, the permission verification result of the shard executing the federated transaction request is obtained.

14. The method according to claim 11, characterized in that, If the permission verification result of the joint transaction request is successful, determining that the joint transaction request is valid and returning the permission verification result of the joint transaction request to the user includes: If the permission verification result of the joint transaction request is that the permission verification is passed, the joint transaction request is determined to be valid, and a verification record of the joint transaction request is generated; The verification record of the joint transaction request is written into the blockchain where the various types of carbon footprint data are located, and the permission verification result of the joint transaction request is returned to the user.

15. A carbon footprint data access verification device, characterized in that, The device includes: The request acquisition module is used to acquire users' transaction requests for carbon footprint data and determine the target transaction requests to be executed for permission verification. The sharding mapping module is used to determine the target shard corresponding to the target transaction request according to a pre-determined sharding mapping relationship, and to route the target transaction request to the target shard. The permission verification module is used to sort the target transaction requests on the target shard to obtain an ordered transaction set, and use each node of the target shard to sequentially perform permission verification on the target transaction requests in the ordered transaction set to obtain the verification status of each node of the target shard. The state tree generation module is used to generate a state tree of the verification status of each node based on the verification status of each node of the target shard, and to determine the root hash value of the state tree of each node. The result determination module is used to determine the permission verification result of the target transaction request on the target shard based on the root hash value of each node of the target shard; wherein, the permission verification result includes permission verification passed and permission verification failed; The return result module is used to generate a verification record for the target transaction request and return the permission verification result to the user if the permission verification result is that the permission verification is successful.

16. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the carbon footprint data access verification method as described in any one of claims 1-14.

17. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the carbon footprint data access verification method as described in any one of claims 1-14.

18. A computer program product, characterized in that, Includes a program or instructions that, when executed by a processor, implement the steps of the carbon footprint data access verification method as described in any one of claims 1 to 14.

Images