A carbon chain circulation supply data sharing method based on a blockchain multi-chain

Abstract

The application discloses a carbon chain circulation supply data sharing method based on a blockchain multi-chain, establishes a parent chain / child chain structure composed of a consortium chain and multiple private chains, and stores complete carbon transaction data in the consortium chain. Each organization generates a representative person through DPOS consensus, and the parent chain authorizes the child chain representative person to cross-chain authority and share open data of the child chain through a smart contract. The child chain divides data through ZK-STARKS consensus, generates a hash value of private data through a secure hash algorithm, and generates new open data with the open data. Decision makers are elected through two rounds of DPOS consensus, the decision makers use VDF to make decisions on the open data, and after verification, the data is given to the next organization for verification. After the carbon transaction is completed, the authoritative node serves as the decision maker, makes decisions on the transaction through VDF consensus, and after the consensus is completed, the data is recorded in the form of plaintext to the consortium chain. Compared with the prior art, the application realizes cross-chain data sharing and consensus, and guarantees data privacy security and traceability.

Description

Technical Field

[0001] This invention belongs to the field of blockchain and data sharing, and specifically relates to a method for sharing carbon chain circular supply data based on a multi-chain blockchain. Background Technology

[0002] The carbon chain circular supply data sharing method based on blockchain multi-chain in this invention has important role and significance. Against the backdrop of the country's active and steady promotion of "carbon peaking" and "carbon neutrality," traditional carbon value recording methods have the following problems: (1) High scalability: Traditional databases are centrally managed, making data susceptible to tampering and deletion. (2) Lack of transparency: Data is controlled by a few individuals, lacking openness and transparency. (3) Risk of data attack: If a centralized database is damaged or attacked, the data of the entire system will be affected. (4) Difficult to share: Traditional databases are difficult for other organizations to share and use. (5) Difficult traceability: Without standardized records, it is difficult to record a complete carbon transaction, often resulting in the loss of a lot of data. In recent years, with the development of blockchain technology, its inherent characteristics can be well applied to the carbon chain circular supply data sharing method, promoting carbon trading, realizing the marketization of carbon trading, strengthening carbon emission accounting and tracking, recording carbon emission data of various enterprises, effectively avoiding data errors and loss, reducing human interference, and improving the accuracy and credibility of carbon emission accounting.

[0003] Blockchain technology:

[0004] Blockchain is a decentralized distributed ledger technology. It records a series of encrypted transaction data in the form of blocks, each block linked to previous blocks to form a chain. Blockchain data is encrypted using algorithms to form ciphertext, and is recorded irreversibly on the blockchain. Because all nodes maintain a complete ledger, there is no single entity that can be tampered with; once a transaction is added to the blockchain through consensus, it cannot be altered. However, blockchain has limitations in performance, scalability, energy consumption, and consensus mechanisms, making it difficult to directly meet the data sharing requirements of complex carbon trading scenarios.

[0005] Consortium blockchains and private blockchains:

[0006] A consortium blockchain is a blockchain network jointly built by multiple organizations to share data. It has access control and only allows verification by consortium members. A private blockchain, on the other hand, is independently built and controlled by a single organization, not open to the public, and used only within the organization. The use of a single consortium or private blockchain lacks flexibility, making interoperability difficult. Direct data access between organizations presents challenges, increases regulatory and security risks, and affects data authenticity and transaction verification.

[0007] Consensus mechanism:

[0008] A consensus mechanism requires all nodes participating in the ledger to exchange and verify information to reach a consensus on the ledger's state, enabling secure updates and maintenance. In carbon trading among multiple companies, each company may generate varying degrees of private and public data. Furthermore, frequent personnel changes and the need for constantly updated representatives mean that a one-size-fits-all consensus mechanism is insufficient to meet the dynamic commercial applications of carbon trading. Summary of the Invention

[0009] Purpose of the Invention: Addressing the problems in carbon chain recycling supply data sharing mentioned in the background art, this invention proposes a multi-chain blockchain-based method for sharing carbon chain recycling supply data. This method strengthens cross-verification, enhances the credibility of verification results, and adopts a "mother chain and child chain" architecture of "consortium chain and private chain," enabling large-scale interconnection of public data between organizations, which is beneficial for data cross-verification and supervision. It employs a multi-consensus mechanism: by dividing the data chain into privacy and public chains, data privacy is protected, while the VDF consensus algorithm is optimized to improve the overall system throughput and meet the needs of different scenarios.

[0010] Technical Solution: This invention proposes a data sharing method for carbon chain circular supply based on blockchain multi-chain, comprising the following steps:

[0011] Step 1: Construct a multi-chain blockchain structure, including a consortium blockchain and private chains of N organizations;

[0012] Step 2: Nodes within the private chain elect representatives using the DPOS consensus algorithm and grant access permissions between different chains;

[0013] Step 3: The representative divides the data into public data and private data using the ZK-STARKS consensus mechanism;

[0014] Step 4: Perform a second DPOS consensus algorithm to elect a private chain decision-maker from among the representatives, verify the public data through the VDF algorithm, and after reaching a consensus, pass the public data to the next data receiving organization for verification;

[0015] Step 5: Once N organizations have completed the carbon trading process, they will upload the complete transaction data to the consortium blockchain.

[0016] Furthermore, the specific method of step 1 is as follows:

[0017] Step 1.1: Construct a consortium blockchain as a "mother blockchain". Each block in the "mother blockchain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain.

[0018] Step 1.2: Construct multiple organizations' private chains as "child chains" of the "mother chain". Each block in the "child chain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain.

[0019] Step 1.3: The "child chain" creates an independent sidechain address on the "parent chain". The "parent chain" defines and constrains the rules of the "child chain" through smart contracts.

[0020] Step 1.4: Define the smart contract:

[0021] (1) When the carbon trading of the “subchain” is completed, the following event is triggered: the data is uploaded to the consortium blockchain;

[0022] (2) Grant access permissions to "subchains": access public data of other "subchains";

[0023] Step 1.5: When the data upload event is triggered, the "mother chain" uses the VDF algorithm as the consensus algorithm. After successful verification, the complete data of this transaction is recorded in the next block of the "mother chain".

[0024] Furthermore, the specific method for step 2 is as follows:

[0025] Step 2.1: In the process of sharing carbon chain circular supply data, there are N private chains of organizations, and representatives are elected through DPOS consensus;

[0026] Step 2.2: After the "subchain" elects a representative, the "parent chain" manages and controls quotas, granting the representative the right to access public data across "subchains".

[0027] Furthermore, the specific method of step 3 is as follows:

[0028] Step 3.1: Representatives within the "subchain" divide the company's carbon data into public and private data using the ZK-STARKS consensus mechanism;

[0029] Step 3.2: Set data permissions. Public data: visible to employees of the enterprise under the "sub-chain" and representatives of other "sub-chains"; Private data: visible only to the enterprise's internal representatives.

[0030] Step 3.3: Generate a 32-byte hash value from the private data using the SHA256 secure hash algorithm, and then place it into the public data.

[0031] Furthermore, the specific method of step 4 is as follows:

[0032] Step 4.1: Conduct a second DOPS consensus, dividing the representatives into decision-makers and validators;

[0033] Step 4.2: The decision-maker holds the VDF private key and makes decisions based on the public data;

[0034] Step 4.3: The verifier verifies the decision-maker's results;

[0035] Step 4.4: Once verification is successful and a consensus is reached, the publicly available data will be passed on to the next organization receiving the data for verification.

[0036] Step 4.5: If verification fails, return to the secondary DOPS consensus and re-elect the decision-maker;

[0037] Step 4.6: After the consensus is reached, the publicly available carbon data is packaged and sent to the next organization receiving the data. Before proceeding with its own process, the next organization needs to perform VDF verification on the data from the previous organization.

[0038] Step 4.7: After verification, proceed with the internal data sharing and consensus process.

[0039] Step 4.8: Verification failed, end this carbon transaction.

[0040] Furthermore, the specific method of step 5 is as follows:

[0041] Step 5.1: Repeat step 4 until N organizations have completed their respective carbon value consensus verification and recognized the previous carbon value data;

[0042] Step 5.2: Trigger the smart contract event and upload the carbon transaction data to the consortium blockchain;

[0043] Step 5.3: The authoritative institution in the consortium blockchain provides an authoritative node as the decision-maker for this VDF consensus, evaluates and judges this carbon trading event, and the delegated representative of one round of DPOS from N organizations acts as a verification member and performs verification.

[0044] Step 5.4: Verification successful; this carbon trading event will be recorded on the consortium blockchain.

[0045] Step 5.5: Verification failed. The authoritative node will investigate this transaction event to determine if there is any data tampering or irregular process.

[0046] Step 5.6: After verification, the authoritative node, with the highest authority, uploads a plaintext note to the consortium blockchain to ensure the integrity of the chain and its subsequent operation.

[0047] Beneficial effects

[0048] (1) The method of the present invention forms a “mother chain and child chain” chain architecture, grants cross-chain permissions to representatives through smart contracts, realizes data sharing, and different enterprises jointly identify the same carbon project through inter-chain communication.

[0049] (2) The company adopts DPOS to select representatives to ensure high efficiency, high transparency and high flexibility. Employees supervise each other, reduce corporate costs and meet actual governance requirements.

[0050] (3) In the ZK-STARKS consensus phase, zero-knowledge proofs divide data into private and public categories, reducing the computational load of VDF and addressing the issues of high computational cost and poor scalability of VDF. On the other hand, during long-term operation, the random number sequence of VDF becomes more predictable, posing a certain risk of data leakage. By providing only public data in the ZK-STARKS consensus phase, data leakage can be avoided, requiring only the uniqueness of the decision-maker. If multiple verification requests occur or more than half of the verifiers abandon verification, a second round of DPOS is conducted to re-elect the decision-maker and generate a new private key, ensuring the security of this phase.

[0051] (4) In the second round of DOPS, the representatives are divided into decision-makers and verifiers, reducing personnel and difficulty. In the "subchain" VDF stage, the decision-maker holds the private key and judges whether the public data is reasonable. It is then passed to the next "subchain" for secondary verification to ensure data security. The "subchain" obtains the public data from the previous enterprise, and continues the process after approval. This step can ensure the basic consensus of multiple enterprises and reduce subsequent meaningless processes.

[0052] (5) In the complete carbon trading process, each organization forms an AND gate signature through a smart contract to jointly acknowledge the transaction. Once the data is uploaded, a consortium blockchain event is triggered, and the authoritative node, as the VDF decision-maker, ultimately achieves secure sharing of carbon data. Attached Figure Description

[0053] Figure 1 A flowchart illustrating the overall process of a blockchain-based multi-chain carbon chain circular supply data sharing method.

[0054] Figure 2 A schematic diagram of carbon chain cycle supply data;

[0055] Figure 3 This is a schematic diagram of the overall structure of a multi-chain blockchain.

[0056] Figure 4 Flowchart for uploading data to the blockchain. Detailed Implementation

[0057] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.

[0058] This invention discloses a method for sharing carbon chain circular supply data based on blockchain multi-chain, which includes the following steps:

[0059] Step 1: Construct a multi-chain blockchain structure, including a consortium blockchain and private chains of N organizations. In this embodiment, five private chains of organizations are set up. The specific method is as follows:

[0060] Step 1.1: Construct a consortium blockchain as the "mother blockchain" S. Each block in the "mother blockchain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain.

[0061] Step 1.2: Construct multiple private chains L = {L1, L2, L3, L4, L5} for each organization as "child chains" of the "mother chain". Each block in the "child chain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain.

[0062] Step 1.3: The "child chain" creates an independent sidechain address on the "parent chain". The "parent chain" defines and constrains the rules of the "child chain" through smart contracts.

[0063] Step 1.4: Define the smart contract: (1) Trigger the event when the carbon transaction of the "subchain" is completed: upload the data to the consortium blockchain. (2) Grant the "subchain" access permissions: access the public data of other "subchains".

[0064] Step 1.5: When the data upload event is triggered, the "mother chain" uses the VDF algorithm as the consensus algorithm. After successful verification, the complete data of this transaction is recorded in the next block of the "mother chain".

[0065] Step 2: Nodes within the private chain elect representatives using the DPOS consensus algorithm and grant access permissions between different chains. The specific method is as follows:

[0066] Step 2.1: In the process of sharing carbon chain circular supply data, the private chains of five organizations, namely manufacturers, reverse logistics service providers, selection centers, carbon processing plants and recycling centers, need to elect representatives through DPOS consensus.

[0067] Step 2.2: After the "subchain" elects a representative, the "parent chain" manages and controls quotas, granting the representative the right to access public data across "subchains".

[0068] Step 3: The representative divides the data into public and private data using the ZK-STARKS consensus mechanism. The specific method is as follows:

[0069] Step 3.1: Representatives within the "subchain" use ZK-STARKS consensus to divide the company's carbon data D = {D1, D2, D3, D4, D5} into public data DP = {DP1, DP2, DP3, DP4, DP5} and private data DS = {DS1, DS2, DS3, DS4, DS5}.

[0070] Step 3.2: Set data permissions. Public data: visible to employees of the enterprise under the "sub-chain" (i.e., nodes under the "sub-chain", which are ordinary employees, and the representatives and decision-makers are selected from them) and representatives of other "sub-chains"; Private data: visible only to representatives within the enterprise.

[0071] Step 3.3: Generate a 32-byte hash value HASH = {H1, H2, H3, H4, H5} from the private data using the secure hash algorithm SHA256, and put it into the public data to generate a new public dataset Dp = {Dp1, Dp2, Dp3, Dp4, Dp5}.

[0072] Step 4: Perform a secondary DPOS consensus algorithm to elect a private chain decision-maker from among the representatives. Verify the public data using VDF. Once consensus is reached, pass the public data to the next organization for verification. The specific method is as follows:

[0073] Step 4.1: Conduct a second DOPS consensus, dividing the representatives into decision-makers and validators.

[0074] Step 4.2: The decision-maker holds the VDF private key M = {M1, M2, M3, M4, M5} and makes decisions based on the public data.

[0075] Step 4.3: The verifier verifies the decision-maker's results.

[0076] Step 4.4: Once verification is successful and a consensus is reached, the publicly available data will be passed on to the next organization receiving the data for verification.

[0077] Step 4.5: If verification fails, return to the secondary DOPS consensus and re-elect the decision-maker.

[0078] Step 4.6: Once the organization has reached a consensus, it will publicly release the carbon data Dp. n (1≤n≤5) Pack the data and send it to the next organization that receives the data. Before proceeding with its own process, the next organization must first process the data Dp from the previous organization. n Perform VDF verification.

[0079] Step 4.7: After verification is completed, proceed with the internal data sharing and consensus process.

[0080] Step 4.8: Verification failed, end this carbon transaction.

[0081] Step 5: After the five organizations complete this transaction process, they will upload the complete transaction data to the consortium blockchain. The specific method is as follows:

[0082] Step 5.1: Repeat step 4 until all five organizations have completed their respective carbon consensus verification and endorsed the previous organization's carbon data.

[0083] Step 5.2: Trigger the smart contract event and upload the carbon transaction data to the consortium blockchain.

[0084] Step 5.3: The authoritative institutions in the consortium blockchain provide authoritative nodes as decision-makers for this VDF consensus, evaluate and judge this carbon trading event, and delegated representatives from one round of DPOS among the five organizations serve as verification members and conduct verification.

[0085] Step 5.4: Verification passed, the carbon trading data from this transaction will be recorded by MES to the consortium blockchain.

[0086] Step 5.5: Verification failed. The authoritative node will investigate this transaction event to determine if there is any data tampering or irregular process.

[0087] Step 5.6: After verification, the authoritative node, with the highest authority, annotates the transaction event in plaintext and uploads it to the consortium blockchain to ensure the integrity of the chain and its subsequent operation.

[0088] The above embodiments are only for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement it accordingly. They should not be used to limit the scope of protection of the present invention. All equivalent modifications or alterations made in accordance with the spirit and essence of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for sharing carbon chain circular supply data based on blockchain multi-chain, characterized in that, Includes the following steps: Step 1: Construct a multi-chain blockchain structure, including a consortium blockchain and private chains of N organizations; Step 2: Nodes within the private chain elect representatives using the DPOS consensus algorithm and grant access permissions between different chains; Step 3: The representative divides the data into public data and private data using the ZK-STARKS consensus mechanism; Step 4: Perform a second DPOS consensus algorithm to elect a private chain decision-maker from among the representatives, verify the public data through the VDF algorithm, and after reaching a consensus, pass the public data to the next data receiving organization for verification; Step 4.1: Conduct a second DOPS consensus, dividing the representatives into decision-makers and validators; Step 4.2: The decision-maker holds the VDF private key and makes decisions based on the public data; Step 4.3: The verifier verifies the decision-maker's results; Step 4.4: Once verification is successful and a consensus is reached, the publicly available data will be passed on to the next organization receiving the data for verification. Step 4.5: If verification fails, return to the secondary DOPS consensus and re-elect the decision-maker; Step 4.6: After the consensus is reached, the publicly available carbon data is packaged and sent to the next organization receiving the data. Before proceeding with its own process, the next organization needs to perform VDF verification on the data from the previous organization. Step 4.7: After verification, proceed with the internal data sharing and consensus process. Step 4.8: Verification failed, end this carbon transaction; Step 5: Once N organizations have completed this carbon trading process, they will upload the complete transaction data to the consortium blockchain. Step 5.1: Repeat step 4 until N organizations have completed their respective carbon value consensus verification and recognized the previous carbon value data; Step 5.2: Trigger the smart contract event and upload the carbon transaction data to the consortium blockchain; Step 5.3: The authoritative institution in the consortium blockchain provides an authoritative node as the decision-maker for this VDF consensus, evaluates and judges this carbon trading event, and the delegated representative of one round of DPOS from N organizations acts as a verification member and performs verification. Step 5.4: Verification successful; this carbon trading event will be recorded on the consortium blockchain. Step 5.5: Verification failed. The authoritative node will investigate this transaction event to determine if there is any data tampering or irregular process. Step 5.6: After verification, the authoritative node, with the highest authority, uploads a plaintext note to the consortium blockchain to ensure the integrity of the chain and its subsequent operation.

2. The method for sharing carbon chain circular supply data based on blockchain multi-chain as described in claim 1, characterized in that, The specific method for step 1 is as follows: Step 1.1: Construct a consortium blockchain as a "mother blockchain". Each block in the "mother blockchain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain. Step 1.2: Construct multiple organizations' private chains as "child chains" of the "mother chain". Each block in the "child chain" contains the hash value of the previous block and is connected to form an irreversible, time-ordered blockchain. Step 1.3: The "child chain" creates an independent sidechain address on the "parent chain". The "parent chain" defines and constrains the rules of the "child chain" through smart contracts. Step 1.4: Define the smart contract: (1) When the carbon trading of the "sub-chain" is completed, the following event is triggered: the data is uploaded to the consortium blockchain; (2) Grant access permissions to "subchains": access public data of other "subchains"; Step 1.5: When the data upload event is triggered, the "mother chain" uses the VDF algorithm as the consensus algorithm. After verification, the complete data of this transaction is recorded in the next block of the "mother chain".

3. The method for sharing carbon chain circular supply data based on blockchain multi-chain as described in claim 1, characterized in that, The specific method for step 2 is as follows: Step 2.1: In the process of sharing carbon chain circular supply data, there are N private chains of organizations, and representatives are elected through DPOS consensus; Step 2.2: After the "subchain" elects a representative, the "mother chain" manages and controls quotas, granting the representative the right to access public data across "subchains".

4. The method for sharing carbon chain circular supply data based on blockchain multi-chain as described in claim 1, characterized in that, The specific method for step 3 is as follows: Step 3.1: Representatives within the "subchain" divide the company's carbon data into public and private data using the ZK-STARKS consensus mechanism; Step 3.2: Set data permissions. Public data: visible to employees of the enterprise under the "sub-chain" and representatives of other "sub-chains"; Private data: visible only to representatives within the enterprise. Step 3.3: Generate a 32-byte hash value from the private data using the SHA256 secure hash algorithm, and then place it into the public data.

Images