A carbon footprint accounting and tracing method based on cross-chain technology

Abstract

The present invention discloses a carbon footprint accounting and tracing method based on cross-chain technology, which belongs to the field of carbon footprint accounting, including: an initiator provides information to a cross-chain transaction contract; the initiators negotiate a shared key and open an off-chain state channel; the initiator deploys a cross-chain carbon footprint accounting contract; different initiators submit cross-chain transactions at the same time, and the cross-chain transaction contract verifies the transactions and packages them, triggering cross-chain events on the chain; the cross-chain agent sends the cross-chain transactions to the leader node, and the leader node selects the transactions and broadcasts them; the transaction status is sharded and tasks are distributed; after the shard server completes the task, the cross-chain agent collects the results and aggregates the status; the cross-chain agent generates a pre-submitted block and broadcasts it; the cross-chain agent that receives the pre-submitted block verifies the block header, updates the channel status after passing, and submits the pre-submitted block to the cross-chain transaction contract; when the cross-chain agent submits a new block, it confirms whether all carbon accounting initiators have correctly submitted the new block; and a new leader node is randomly generated.

Description

Technical Field

[0001] The present invention belongs to the technical field of carbon footprint accounting, and specifically relates to a carbon footprint accounting and tracing method based on cross-chain technology. Background Art

[0002] Carbon footprint accounting is an indicator that measures the total amount of greenhouse gases released by a product during its life cycle. It includes the total amount of greenhouse gases released by a product at each stage of its life cycle, including production, manufacturing, transportation, use, and disposal. By reducing the carbon footprint of products, companies can reduce energy consumption, reduce the waste of raw materials, and increase the recycling rate of material resources, thereby reducing operating costs and risks and improving the environmental benefits and competitiveness of products.

[0003] Traditional carbon footprint accounting mainly includes life cycle assessment (LCA) and product carbon footprint management. Life cycle assessment is a method for evaluating the environmental impact of a product throughout its life cycle. It covers the collection and analysis of carbon emission data at all stages of the product, from raw material acquisition, production and manufacturing, distribution and transportation, product use to product disposal. Product carbon footprint management involves product modeling, carbon emission accounting, statistical analysis, data management and other functions. It integrates the internationally accepted carbon footprint accounting standards ISO14067 and PAS2050, and incorporates a large number of carbon emission factors to participate in the accurate calculation and multi-dimensional analysis of carbon footprint data at all stages of the product life cycle. However, the traditional carbon footprint accounting method has the following disadvantages:

[0004] (1) The authenticity of the data is difficult to guarantee: Traditional methods mainly rely on data provided by enterprises. If there is no effective supervision and audit mechanism, enterprises may falsify or conceal data in order to reduce costs, resulting in inaccurate carbon footprint accounting results.

[0005] (2) Difficulty in data sharing: Traditional methods mainly conduct carbon footprint accounting within enterprises. It is difficult to share data between different enterprises and between enterprises and governments and research institutions, making it difficult to achieve carbon footprint monitoring and management for the entire society.

[0006] (3) Lack of transparency and accountability: Traditional methods mainly rely on corporate self-reporting and government supervision, and lack the participation and supervision of third-party institutions. As a result, the authenticity and reliability of carbon footprint data cannot be guaranteed, and companies cannot be effectively held accountable.

[0007] (4) Lack of scalability and flexibility: Traditional methods mainly conduct carbon footprint assessments on specific products and industries. They may have limitations for complex products and cross-industry collaborations and are difficult to adapt to the rapidly developing green technology field.

[0008] In contrast, cross-chain blockchain technology can solve the problems of traditional carbon footprint accounting methods through the characteristics of distributed accounting, immutability, transparency and traceability. For example, through distributed accounting, data sharing can be achieved throughout society, and the authenticity and reliability of data can be improved; through immutability, the authority and fairness of carbon footprint data can be ensured; through transparency and traceability, the carbon footprint monitoring and accountability mechanism of the whole society can be realized; through smart contracts, the threshold of carbon footprint accounting can be lowered and user participation can be improved. Summary of the invention

[0009] In view of this, the purpose of the present invention is to provide a carbon footprint accounting and tracing method based on cross-chain technology.

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

[0011] A carbon footprint accounting and tracing method based on cross-chain technology, comprising the following steps:

[0012] S1: The carbon accounting initiator provides identity information to the cross-chain transaction contract of the data chain to which it belongs; the carbon accounting initiators negotiate a shared key through the Pedersen VSS algorithm and open an off-chain state channel, and perform cross-chain transactions in the off-chain state channel. The shared key is used to encrypt the blocks generated in the channel;

[0013] S2: The carbon accounting initiator deploys a cross-chain carbon footprint accounting contract in the state channel. The cross-chain carbon footprint accounting contract is a collection of a series of states and their operation functions on each data chain;

[0014] S3: Different carbon accounting initiators submit cross-chain transactions to their respective data chains at the same time. The cross-chain transaction contract batches these transactions after verifying their legitimacy and triggers cross-chain events on the chain.

[0015] S4: The cross-chain proxy that monitors cross-chain events on its own data chain sends the received cross-chain transactions to the leader node in the channel. The leader node selects transactions that meet the conditions from the transaction pool according to the state channel configuration information and broadcasts the transactions in the channel; the transactions are sharded according to the states involved, and then the cross-chain proxy distributes the execution tasks to the shard servers;

[0016] S5: After the shard server completes the task, the cross-chain proxy collects the execution results and performs status aggregation; after completing the collection and aggregation, the cross-chain proxy packages the executed transactions and results and generates a pre-submitted block, and broadcasts the pre-submitted block in the channel; the cross-chain proxy node that receives the pre-submitted block verifies the block header, and when all cross-chain proxies pass the verification, they update the channel status and submit the pre-submitted block to the cross-chain transaction contract of the data chain to which they belong; when the cross-chain proxy submits a new block, it confirms through the SPV trust chain whether all carbon accounting initiators have submitted the new block correctly; a new leader node is randomly generated through the VRF algorithm after each round of new block generation.

[0017] Furthermore, the steps for establishing the off-chain state channel are as follows:

[0018] The carbon accounting initiator of the data chain Chain1, as the initiator U of the state channel establishment, sends a channel establishment request to the cross-chain transaction contract CTC; the channel establishment request includes U's cross-chain identity information CCIdInfo and the cross-chain identity information of other carbon accounting initiators P that need to be included in the channel;

[0019] After verifying that U's cross-chain identity information is legitimate, the cross-chain transaction contract of a data chain sends a VRF selection instruction to the cross-chain proxy cluster; the VRF selection instruction randomly selects one from multiple cross-chain proxies to join the state channel, namely, cross-chain proxy 1;

[0020] After the cross-chain proxy 1 parses the request, it submits the request to the cross-chain transaction contract through the proxy of data chain Chain2 according to the source chain identity information of the carbon accounting initiator P; after verifying that the identity information contained in the request is correct, P submits a channel response message to the cross-chain transaction contract and randomly selects cross-chain proxy 2 again through VRF;

[0021] Cross-chain agent 1 and cross-chain agent 2 establish a relay communication channel and negotiate channel preparation information, which includes the channel identifier channelId and the identity information of all carbon accounting initiators.

[0022] Furthermore, the VRF selection instruction is used to randomly select a cross-chain proxy to join the state channel. The selection process is as follows:

[0023] (1) The user generates a key pair (pk, sk) through an asymmetric encryption algorithm, where pk is the public key and sk is the secret key;

[0024] (2) The user inputs the message m and private key sk into the VRF generation function to obtain a pseudo-random number r and the proof pi corresponding to r:

[0025] (r,pi)←VRF GEN (sk,m)(1)

[0026] (3) The verifier inputs r, pi and pk into the VRF verification function to determine whether r is generated by sk held by the user based on the message m. If the verification passes, then:

[0027] VRF VERIFY (r,pi,pk)==true (2).

[0028] Further, the step of negotiating a shared key through the PedersenVSS algorithm specifically includes:

[0029] The initiator who requests to open the cross-chain state channel is U; U initializes the following parameters: the number of carbon accounting initiators n, the selected large prime numbers p and q, q is the large prime factor of p-1, group G q It's Z p * = {1...p-1} unique subgroup of order q, g and h are G q The generator and discrete logarithm log g h unknown;

[0030] (1) Initialization phase

[0031] 1) U selects a t-1 order polynomial (3), where s is a randomly selected key, a i ∈Z p * is a randomly selected polynomial coefficient, 1≤i≤t-1; for each coefficient a of the polynomial i , U selects a random number b i ∈Z p * , public polynomial coefficient a i The commitment value E i =E(a i ,b i ), E i Calculate using formula (4);

[0032]

[0033]

[0034] 2) U chooses another t-1 order polynomial (5), where r is a random number, and publicly commits to the value E 0 =E(s,r).

[0035]

[0036] U Calculations k =f(k) and r k =g(k), where 1≤k≤n, and (sk ,r k ) is sent as a secret share to the carbon accounting initiator P;

[0037] (2) Secret Share Verification Phase

[0038] Carbon accounting initiator P k When receiving the secret share, use formula (6) to determine the correctness of the secret share:

[0039]

[0040] After verifying the correctness of the secret share, the carbon accounting initiator uses the public key contained in the cross-chain identity information declared in the state channel to encrypt the secret share and put it into the genesis block of the state channel. The genesis block is stored in the cross-chain transaction contract process on all business chains through the cross-chain proxy as the genesis block of the cross-chain transaction blockchain;

[0041] (3) Key reconstruction phase

[0042] When the state channel submits a new block to the chain, it uses a shared key for encryption; the carbon accounting initiator encrypts its own secret share with the public keys of other carbon accounting initiators and sends it to the corresponding carbon accounting initiator. After receiving the encrypted secret share, it uses the private key to decrypt it to obtain the sender's secret share; when reconstructing the secret, the participant P k Formula (6) is used to verify the validity of the secret shares sent by other participants. After collecting t secret shares, the Lagrange interpolation method is used according to formula (7) to reconstruct the secret. The carbon accounting initiator uses the reconstructed shared key to encrypt the block and upload the encrypted block to the chain through the cross-chain proxy.

[0043]

[0044] Furthermore, the cross-chain carbon footprint accounting contract is formed through the following steps:

[0045] (1) The cross-chain proxy requests the cross-chain transaction contract to build a cross-chain carbon footprint accounting contract;

[0046] (2) The cross-chain transaction contract calls the state locking interface of the business contract to lock the state. The locked state can only be modified by submitting a block to the cross-chain transaction contract. The cross-chain transaction contract calls the state update interface provided by the business contract to complete the state modification;

[0047] (3) Each cross-chain agent mutually verifies the validity of the on-chain state locking transaction through SPV;

[0048] (4) The cross-chain proxy requests the cross-chain transaction contract to return the corresponding state operation function, and based on this, builds a real cross-chain smart contract in the off-chain state channel.

[0049] Further, the cross-chain transaction blockchain is composed of blocks that the cross-chain agent continuously submits to the data chain;

[0050] The cross-chain transaction blockchain regards each data chain as a node and combines the business contracts on each data chain to obtain a cross-chain smart contract;

[0051] Each block of the cross-chain transaction blockchain is submitted by the cross-chain agent to the cross-chain transaction contract of each data chain. The block contains a block header and a block body; the block header contains a block height (BlockHeight), a block hash (BlockHash), a previous block hash (PreHash), a timestamp (Timestamp), a block proposer (Proposer), an endorsement (Endorsement), a state channel identifier (ChannelId), a cross-chain transaction Merkle root (CTXRoot), a channel world state Merkle root (StateRoot) and a block validity field (ValidFlag); the proposer of the block is the leader of the current state channel, and the proposer changes with the change of the block height, that is, after each block is produced, the off-chain cross-chain agents randomly select a new proposer through VRF;

[0052] The endorsement field stores the digital signatures of all cross-chain proxies in the state channel to which the current block belongs on the current transaction root and state root; the endorsement field combines the digital signatures of multiple proxies into one through an aggregate signature algorithm;

[0053] The state channel identifier of a block indicates the state channel to which the block belongs. Each state channel corresponds to a cross-chain transaction blockchain.

[0054] The transaction root is the root of the Merkle tree formed by recursive hashing of cross-chain transactions in pairs; the state root is the root of the Merkle tree formed by recursive hashing of the world state of the state channel in pairs after all cross-chain transactions in the current block are executed.

[0055] Furthermore, the detailed structure of the state (State) is used to indicate the operation method (Method1-n) of a business contract (ContractName) on a certain data chain (ChainId) for a certain state (Key);

[0056] The state channel identifier field (ChannelId) in the cross-chain transaction (CTX) is used to indicate the state channel to which the cross-chain transaction received by the cross-chain transaction contract belongs;

[0057] The sender field and signature field of the cross-chain transaction respectively represent the identity information of the sender of the current cross-chain transaction and the digital signature information signed using the key corresponding to the identity information. The identity information includes the data chain identifier (ChainId) and the user identifier (UserId);

[0058] The effective execution load in a cross-chain transaction is multiple cross-chain sub-transactions (SubCTX), each of which contains a state and its corresponding operation method index (MethodIndex) and call parameters;

[0059] Each cross-chain transaction combines multiple cross-chain sub-transactions involving different data chain states to complete different cross-chain interoperability functions;

[0060] The Flag field in a cross-chain transaction indicates the execution status of the cross-chain transaction.

[0061] Furthermore, the execution process of cross-chain transactions is described as follows:

[0062] (1) The cross-chain agent parses the cross-chain transaction to obtain relevant information of the cross-chain transaction blockchain and verifies the legitimacy of the cross-chain transaction based on the carbon accounting initiator information of the chain;

[0063] (2) The cross-chain proxy broadcasts the cross-chain transaction within the channel;

[0064] (3) The leader node of the cross-chain channel selects a batch of cross-chain transactions and distributes them to the working nodes for execution using a parallel scheduling algorithm;

[0065] (4) The leader node collects the execution results, generates a pre-committed block and broadcasts it within the channel;

[0066] (5) Each cross-chain agent independently verifies the correctness of the pre-submitted block and submits the block to the cross-chain transaction contract of the data chain to which it belongs;

[0067] (6) The channel re-elects the leading node for the next round of transaction execution process.

[0068] Furthermore, sharding the transaction according to the states involved specifically includes:

[0069] Abstract cross-chain transactions into a queue of state operations, where each element in the queue corresponds to a cross-chain sub-transaction;

[0070] Select a cross-chain transaction that can be executed concurrently from the head of the queue and add it to the execution round. If there is still an unempty queue, enter the next concurrent execution round until all cross-chain transactions are divided;

[0071] There are two aspects to determine whether a cross-chain sub-transaction can be added to a certain concurrent execution round:

[0072] (1) The cross-chain sub-transaction to be added cannot conflict with other elements in the queue to which the cross-chain sub-transactions already added to the execution round belong;

[0073] (2) The cross-chain sub-transaction to be added cannot conflict with the elements already added to the execution round;

[0074] The state sharding steps are as follows:

[0075] 1. Initialize the variable round to 0, indicating the number of execution rounds; initialize the variable concurrenceIndexes to an empty array, representing the set of cross-chain transaction labels (sequence numbers) that have already been added to the concurrent set; initialize the variable concurrenceRounds to a mapping, with the key being the label (sequence number) of the concurrent set and the value being the set of cross-chain sub-transactions that can be executed concurrently;

[0076] 2. For each cross-chain transaction CTX in CTXs = {CTX 1 ,..., CTX n}, perform the following operations: i Do the following:

[0077] 2.1 If CTX i no longer contains cross-chain sub-transactions, then process the next cross-chain transaction, that is, return to 2;

[0078] 2.2 Obtain the first cross-chain sub-transaction subCTX in CTX i ;

[0079] 2.3 Determine whether subCTX can be added to the concurrent set;

[0080] 2.3.1 Check whether the status of subCTX is the same as that of the jth (j < i) CTX j . If they are the same, there is a conflict;

[0081] 2.3.2 Check whether the status of subCTX is the same as the status already added to the concurrent round (needs to cooperate with concurrenceIndexes). If they are the same, there is a conflict;

[0082] 2.4 If there is a conflict in any step of 2.3.1 or 2.3.2, then subCTX cannot be added to the round round, and return to 2;

[0083] 2.5 If there is no conflict between 2.3.1 and 2.3.2, add subCTX to the concurrent set, that is, add subCTX to the round-th concurrent set in concurrenceRounds, and add the index i of the current cross-chain transaction to the concurrenceIndexes array;

[0084] 2.6 Remove CTX i subCTX in;

[0085] 3. If there are still undivided cross-chain transactions in CTXs, the round is incremented by 1 and enters the next division round, that is, returns to 2;

[0086] 4. Return the division result concurrenceRounds.

[0087] Furthermore, the steps for the cross-chain proxy to execute cross-chain transactions in parallel are as follows:

[0088] (1) The cross-chain proxy dispatches the corresponding cross-chain sub-transaction execution tasks to the working nodes. The cross-chain proxy uses formula (8) to determine the dispatch process, where HASH(state) is the hash function and n is the number of state shard servers owned by the cross-chain proxy. The state is mapped by the hash function to dynamically respond to inputs of different data types and distribute them in a relatively uniform manner.

[0089] The state shards are mapped to the working nodes;

[0090] SHARD_OF(state)=HASH(state)%n(8)

[0091] (2) Between two execution rounds, the cross-chain proxy collects the execution results of the previous execution round and aggregates the results with the current world state. Then, before starting the next execution round, the latest aggregated world state is broadcast between the working nodes to achieve state sharing of the working nodes between the two execution rounds. The state aggregation operation is expressed by formula (9):

[0092]

[0093] RoundState i Indicates the round state after the i-th execution round is completed, WorkerState 1-n They respectively represent the execution results returned by the working node of the cross-chain proxy, which contain the state shards modified by the cross-chain sub-transaction;

[0094] (3) After completing all execution rounds, the cross-chain agent obtains the latest world state that needs to be recorded in the block by finding the union of all round states, expressed as:

[0095]

[0096] Where WorldState i It indicates the corresponding world state after the execution of the i-th block. The first world state is obtained by state locking;

[0097] (4) If the cross-chain proxy finds that any cross-chain transaction has an abnormality in its execution, the cross-chain proxy will roll back the state, discard the pre-committed block, and move the transactions in the block back into the transaction pool to wait for the next execution.

[0098] The beneficial effect of the present invention is that the cross-chain proxy in the state channel uses the same sharding strategy and world state update method, and different working node clusters can perform the same execution of cross-chain transactions in the block and check the results with other clusters. In this way, the consistency of the state sharding can be guaranteed, ensuring that the carbon accounting data is calculated strictly in accordance with the accounting logic specified in the cross-chain carbon footprint accounting contract.

[0099] Other advantages, objectives and features of the present invention will be described in the following description and will be apparent to those skilled in the art to some extent, or those skilled in the art may be taught from the practice of the present invention. The objectives and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0100] In order to make the purpose, technical solution and beneficial effects of the present invention clearer, the present invention provides the following drawings for illustration:

[0101] Figure 1 A carbon footprint accounting system model based on cross-chain technology;

[0102] Figure 2 System architecture for cross-chain methods;

[0103] Figure 3 Create an initialization phase flow chart for off-chain status communication;

[0104] Figure 4 My cross-chain carbon footprint accounting contract;

[0105] Figure 5 It is a cross-chain transaction blockchain block structure diagram;

[0106] Figure 6 My cross-chain transaction turn-based execution graph based on state sharding; DETAILED DESCRIPTION

[0107] The carbon footprint accounting and traceability system proposed in the present invention is as follows Figure 1As shown in the figure. The system mainly includes carbon emission monitoring area, carbon emission collection node, data chain, supervision chain and cross-chain interaction platform. The cross-chain interaction platform is composed of cross-chain transaction blockchain and cross-chain carbon footprint accounting contract. Both of them do not really exist, but are a virtual state maintained by the cross-chain interaction algorithm. These virtual states are scattered on various data chains and supervision chains. This solution ensures that there will be no single point of failure and centralization problems.

[0108] The carbon emission data generated in the carbon emission monitoring area is monitored by the carbon emission data collection node and uploaded to the data chain in real time. The carbon emission data collection node mainly monitors the direct and indirect emissions of greenhouse gases. Indirect emissions include emissions from energy utilization such as electricity and heat, emissions from industrial production side effects, and emissions from agricultural activities. The carbon emission node is functionally equivalent to the light node of the data chain. It is only responsible for collecting carbon emission data in a real and effective manner and uploading it to the data chain node, and does not participate in the consensus of the data chain. Multiple collection nodes are not aware of each other and upload monitoring data to the data chain node independently. The data uploaded by the data collection node is judged by the data chain node whether it is true or not. The malicious behavior of a few collection nodes will not change the authenticity of the data.

[0109] The supervision chain can initiate a construction request between any data chains, which will lead to the establishment of a virtual cross-chain transaction blockchain, which stores all cross-chain transaction processes. The interconnection of carbon footprint data is the prerequisite for carbon footprint accounting. On the cross-chain transaction blockchain, the supervision chain initiates a cross-chain carbon footprint accounting contract construction request, which will enable the carbon trading data on each data chain to be shared globally and break the information island. Since different carbon emission monitoring areas or even the same carbon emission monitoring area have different types of carbon emission entities, the carbon footprint accounting contract must be able to support multiple accounting objects and accounting algorithms. Blockchain smart contracts can do this well. The accounting rules of the cross-chain carbon footprint accounting contract are defined by the supervision chain, which is open, transparent and supports flexible configuration. The accounting results and accounting process of the accounting contract are all recorded on the cross-chain transaction blockchain and shared globally through the cross-chain platform.

[0110] In addition, since the real-time and throughput of most blockchains are low, in order to cope with the performance bottleneck in high concurrency and massive data scenarios, an algorithm that can efficiently execute cross-chain transactions and process carbon trading accounting needs to be designed on the carbon trading cross-chain platform. The following will expand on these two aspects.

[0111] Different accounting methods require different data. Diversified data collection nodes collect carbon data from carbon emission monitoring areas and report them to the data chain, which initiates carbon accounting. For different application scenarios, regulators need to flexibly specify different carbon accounting standards. The following lists several typical carbon accounting scenarios and their accounting ideas.

[0112] Hydropower carbon footprint accounting method: Hydropower occupies an important position in the field of clean energy. Compared with other clean energy power generation systems, it has higher stability, adjustability and longer operating life. However, due to its reliance on natural watersheds or reservoirs, it has a more profound impact on the environment. Not only does the construction and operation of hydropower stations require the consumption of a large amount of materials and energy, but it will also have a long-term negative impact on the ecological environment around the waters. LCA research objectively evaluates the clean attributes of hydropower systems over a long period of time from a life cycle perspective.

[0113] The existing research on carbon emission accounting of hydropower systems mainly focuses on three types of hydropower stations: run-of-river hydropower stations, reservoir hydropower stations, and pumped storage hydropower stations. The accounting method of carbon emissions in the life cycle of hydropower systems is as follows:

[0114]

[0115] Among them, C hyd is the total carbon emissions of the hydropower system during its life cycle; n is the activities involved in the accounting within the system boundary defined in the study of carbon emissions accounting of the hydropower system life cycle, usually involving raw material production, equipment production, power station construction, operation and maintenance, decommissioning and other activities; a i represents the emission factor for each specific activity; M i Represents a measure of activity, such as supplies used, energy consumed, etc.

[0116] Wind power carbon footprint accounting: Wind power is one of the main energy technologies for achieving low-carbon energy strategies. In order to adapt to the diverse electricity demand and power generation scenarios, different wind power systems use wind turbines with different motor types, rated capacities, capacity factors, and installation locations, which results in differences in energy consumption and consumables during the manufacturing, maintenance, and recycling stages of various wind turbines.

[0117] Compared with small wind turbines with smaller rated capacity, the manufacture and transportation of large wind turbines require more materials and primary energy. Intuitively, large wind turbines will have greater negative environmental impacts in the production and operation and maintenance stages. However, since large wind turbines can capture more wind energy and obtain greater energy output, they can offset the energy consumed in the construction and operation and maintenance stages more quickly and reduce carbon emissions generated by other high-carbon emission power generation equipment, and have a strong indirect emission reduction capacity. Therefore, with the increase of turbine rated capacity and capacity factor, the average greenhouse gas emissions of large wind turbines tend to decrease. In addition, compared with land, the sea has more abundant and high-quality wind resources and a wider available area, and offshore wind power has a higher carbon reduction potential. However, since offshore wind turbines are mostly deployed in deep seas, additional structures are required to fix offshore floating platforms and higher transportation and maintenance costs. There are also certain differences in carbon emissions from different fixing methods, which to a certain extent reduces its advantage of high energy output.

[0118] In addition to using wind turbines as accounting objects alone, there are also studies that combine supporting infrastructure and electrical equipment (such as energy storage equipment, cables, substations, etc.) to quantitatively evaluate the environmental impact of wind farms. In recent years, some studies have further considered the organic combination of wind farm construction and transmission network construction, taking the complete wind power project as the accounting object, and analyzing and calculating the life cycle carbon footprint of wind farms and their corresponding networking project construction from a systematic perspective.

[0119] Carbon footprint accounting of nuclear power generation: Carbon emissions generated during the life cycle of nuclear fuel account for the majority of carbon emissions during the entire life cycle of nuclear power generation, including uranium exploration, mining, grinding, conversion and enrichment, production of nuclear fuel rods, fuel transportation and storage, and back-end radioactive nuclear waste treatment. Since the final storage and reprocessing projects of back-end radioactive nuclear waste usually involve confidential information, it is difficult to define clear system boundaries and obtain detailed and accurate data, resulting in a high degree of uncertainty in the accounting results. Carbon emission accounting research on front-end nuclear fuel acquisition and manufacturing is relatively more extensive and mature, but different assessment studies often produce differentiated accounting results, which are directly affected by factors such as front-end mining technology, ore quality, enrichment technology, and geographical location.

[0120] The life cycle of a nuclear power plant mainly includes the construction, operation and decommissioning of the power plant. Nuclear fission reactions are special and risky, so nuclear power plants are composed of a large number of components and equipment, and the structure is highly complex. The construction process consumes a lot of materials such as concrete and steel, as well as energy such as electricity and fossil fuels. The average carbon emissions of nuclear power plant construction phases in early LCA assessments were about 46% of the average carbon emissions at the front end. Due to the confidentiality of nuclear power plant design plans and the lack of data, the carbon emissions during the construction phase are usually underestimated. With the development and construction of new nuclear reactors, the design and structure of nuclear power plants are more complex, and the carbon emission intensity is higher during the construction phase. The inventory and data of equipment maintenance and update, nuclear fuel rod replacement, energy consumption and other links in the operation phase of nuclear power plants are also difficult to obtain and accurately analyze, which will also lead to an underestimate of carbon emissions in this stage. The decommissioning phase of a nuclear power plant is the last link in the life cycle of a nuclear power plant and the link with the greatest impact on the environment. It usually requires a "safe closure period" of several decades, which involves not only the demolition and treatment of buildings and equipment, but also the decontamination of radioactive materials. At present, LCA research at this stage is mostly based on assumptions and approximations. The long decommissioning process and a small number of nuclear power plant decommissioning research samples result in large errors and high uncertainties in the existing accounting results.

[0121] Photovoltaic carbon footprint accounting: The carbon emissions of the photovoltaic system's life cycle mainly occur in the manufacturing and construction stages, and the manufacturing of photovoltaic cells is the most complex, time-consuming, and carbon-emitting process in the construction process. Currently, common photovoltaic cells include silicon-based photovoltaic cells, thin-film photovoltaic cells, new photovoltaic cells (including dye-sensitized photovoltaic cells, perovskite photovoltaic cells, and quantum dot photovoltaic cells, etc.). Silicon-based photovoltaic cells (including single-crystal and multi-crystal photovoltaic cells) are mainstream products on the market because of their high conversion rate and cost-effectiveness, but their production process is complex and involves high-temperature purification, which consumes a lot of energy and produces more carbon emissions. Thin-film photovoltaic cells are a new generation of photovoltaic cells that emerged after silicon-based photovoltaic cells, including amorphous silicon photovoltaic cells, cadmium telluride photovoltaic cells, copper indium gallium selenide thin-film photovoltaic cells, etc. Compared with silicon-based photovoltaic cells, the process is relatively simple, uses less materials, does not involve high-temperature processes, and consumes less energy and carbon emissions. In addition, the construction of photovoltaic systems also needs to consider the manufacturing of supporting electrical equipment such as system balance and inverters, the transportation and installation of materials and equipment, and the wiring and component interconnection processes.

[0122] In order to enable the carbon emission data on the data chain to circulate, an efficient cross-chain interoperable system is needed. The system architecture of the cross-chain method proposed in this invention is as follows: Figure 2As shown in the figure. The figure mainly includes data chains (chain1 and chain2) and carbon accounting initiators attached to the data chains (regulatory nodes, data chain nodes, carbon accounting initiators), cross-chain transaction contracts, cross-chain proxies, shard servers, off-chain state channels, and cross-chain transaction blockchains. The cross-chain transaction contract verifies the identity information of cross-chain users, receives cross-chain transactions issued by users and performs legality checks, and packages valid cross-chain transactions into a processing batch. The cross-chain proxy is a key factor for heterogeneous blockchain systems to access the cross-chain platform. It needs to adapt to different blockchain systems at the bottom layer and provide a unified access interface to the outside at the upper layer. In addition to eliminating the heterogeneity between different blockchain systems, the cross-chain proxy is also a relay gateway for cross-chain transactions, an intermediary for off-chain state channel negotiations, an executor of state shards, and a submitter of cross-chain transaction blocks. The shard server is the executor of cross-chain sub-transactions. It executes cross-chain sub-transactions according to the state shards distributed by the cross-chain proxy and returns the execution results to the cross-chain proxy. After the cross-chain proxy completes the result collection and state aggregation, it submits the block, and the submitted block is stored on the chain through the cross-chain transaction contract. In order to further enhance the security of cross-chain interoperability, the cross-chain transaction contract also needs to receive the challenge raised by the carbon accounting initiator and issue a rollback instruction to the cross-chain proxy when the challenge is successful. The architecture of multiple cross-chain proxy nodes and multi-task execution nodes can reduce the risks brought by centralization to a certain extent, and can effectively alleviate the cross-chain event spike impact problem in high-performance blockchain systems.

[0123] Based on the above system architecture, a brief description of the carbon accounting process is as follows:

[0124] (1) The carbon accounting initiator provides identity information to the cross-chain transaction contract of the data chain to which it belongs. This identity information includes the data chain information chainInfo and user information userInfo, etc.

[0125] The carbon accounting initiators negotiate a shared key through the Pedersen VSS algorithm and open an off-chain state channel. Cross-chain transactions are executed in this state channel, and the shared key is used to encrypt the blocks generated in the channel.

[0126] (2) The carbon accounting initiator deploys a cross-chain carbon footprint accounting contract in the state channel. This contract is a cross-chain interoperability protocol recognized by all carbon accounting initiators. Its initial state data consists of the on-chain state data locked when the state channel is opened.

[0127] (3) Different carbon accounting initiators can submit cross-chain transactions to their respective data chains at the same time. After verifying the legitimacy of these transactions, the cross-chain transaction contract will batch them and trigger cross-chain events on the chain.

[0128] (4) The cross-chain proxy that monitors cross-chain events on its own data chain sends the received cross-chain transactions to the leader node in the channel. The leader node selects transactions that meet the conditions from the transaction pool according to the state channel configuration information and broadcasts the transactions in the channel. These transactions will be sharded according to the states they involve. After the state sharding is completed, the cross-chain proxy distributes the execution tasks to the shard servers to maximize the parallel execution of cross-chain transactions.

[0129] (5) After the shard server completes the execution, the cross-chain proxy begins to collect the execution results and perform status aggregation. After completing the collection and aggregation, the cross-chain proxy packages the executed transactions and results and generates a pre-submission block, which is broadcast in the channel. The cross-chain proxy node that receives the pre-submission block verifies the block header. When all cross-chain proxies pass the verification, they update the channel status and submit the block to the cross-chain transaction contract of the data chain to which they belong. When the cross-chain proxy submits a new block, it confirms through the SPV trust chain whether all carbon accounting initiators have correctly submitted the new block. The new leader node is randomly generated through the VRF algorithm after each round of new block generation.

[0130] To further improve the security of cross-chain interoperability, any carbon accounting initiator can view the blockchain generated by the cross-chain state channel through the cross-chain transaction contract, and can re-execute the questionable blocks to submit challenges. If the challenge is successful, the cross-chain transaction contract will initiate a rollback instruction to the state channel to roll back the current state of the state channel to the world state at the specified block height.

[0131] The off-chain state channel is a relay channel between carbon accounting initiators. The cross-chain agent performs transaction synchronization, status synchronization, cross-chain transaction execution, block packaging, and leadership node replacement within this channel.

[0132] The initialization phase of the off-chain state channel mainly completes two operations: cross-chain identity authentication and relay channel establishment. The main process of the initialization phase is as follows: Figure 3As shown in the figure. In the figure, the carbon accounting initiator of Chain1, as the initiator of the state channel establishment (denoted as U), sends a channel establishment request to the cross-chain transaction contract (CTC). The channel establishment request contains U's cross-chain identity information (CCIdInfo) and the cross-chain identity information of other carbon accounting initiators that the channel needs to include (here, the carbon accounting initiator P). After verifying that U's cross-chain identity information is legal, the cross-chain transaction contract of Chain1 sends a VRF selection instruction to the cross-chain proxy cluster, which randomly selects one of multiple cross-chain proxies to join the state channel, that is, cross-chain proxy 1 in the figure. After proxy 1 parses the request, it submits the request to the cross-chain transaction contract through the proxy of Chain2 (randomly selected) according to P's source chain identity information. After verifying that the identity information contained in the request is correct, P submits a channel response message to the cross-chain transaction contract and randomly selects cross-chain proxy 2 again through VRF. Proxy 1 and Proxy 2 establish a relay communication channel and negotiate channel preparation information, including the channel identifier (channelId) and the identity information of all carbon accounting initiators.

[0133] Randomly selecting cross-chain proxies to join the state channel through VRF can, to a certain extent, solve the problem of malicious cross-chain proxies joining the state channel that are completely controlled by malicious users. VRF ensures that the node selection process is not influenced or manipulated by any party, making it difficult for malicious actors to predict or control the selection process, and ensuring the transparency and trust of the selection process. For a message m and a private key (SecretKey, SK), VRF can generate a random number r and a proof of r. The verifier only needs to hold the public key (PublicKey, PK) corresponding to the private key, r, m and proof to verify whether r is generated by SK based on m. The VRF process is as follows:

[0134] (1) The user generates a key pair (pk, sk) through an asymmetric encryption algorithm, where pk is the public key and sk is the secret key.

[0135] (2) The user inputs the message m and private key sk into the VRF generation function to obtain a pseudo-random number r and the proof pi corresponding to r, as shown in formula (1).

[0136] (r,pi)←VRF GEN (sk,m)(1)

[0137] (3) The verifier inputs r, pi and pk into the VRF verification function to determine whether r is generated by sk held by the user based on the message m. If the verification passes, (2) holds:

[0138] VRF VERIFY (r,pi,pk)==true (2)

[0139] Since cross-chain operations involve multiple blockchain systems, the carbon accounting initiator does not want to disclose its own cross-chain information to all users of other business chains. This information should only be disclosed to the carbon accounting initiator in the state channel, so it is necessary to encrypt the block. The present invention uses a shared key scheme for encryption. The shared key scheme adopts the PedersenVSS design. PedersenVSS is a non-interactive VSS scheme that does not rely on a third party. The scheme is described in detail as follows.

[0140] The initiator of the request to open the cross-chain state channel is U. U initializes the following parameters: the number of carbon accounting initiators n, the selected large prime numbers p and q, q is the large prime factor of p-1, and the group G q It's Z p * = {1...p-1} unique subgroup of order q, g and h are G q The generator and discrete logarithm log g h unknown.

[0141] (1) Initialization phase

[0142] 1) U selects a t-1 order polynomial (3), where s is a randomly selected key, a i ∈Z p * (1≤i≤t-1) are randomly selected polynomial coefficients. For each coefficient a of the polynomial i , U selects a random number b i ∈Z p * , public polynomial coefficient a i The commitment value E i =E(a i ,b i ), E i Calculate using formula (4).

[0143]

[0144]

[0145] 2) U chooses another t-1 order polynomial (5), where r is a random number, and publicly commits to the value E 0 =E(s,r).

[0146]

[0147] U Calculations k =f(k) and r k =g(k), where 1≤k≤n, and (s k ,rk ) is sent as a secret share to the carbon accounting initiator P k At this point, all carbon accounting initiators already have their own secret share.

[0148] (2) Secret Share Verification Phase

[0149] Carbon accounting initiator P k Upon receiving the secret share, and because it is not possible to ensure that U will disclose the secret to all carbon accounting initiators P k The secret share is sent correctly, so P k When the secret share is received, the correctness of the secret share is determined using formula (6).

[0150]

[0151] After verifying the correctness of the secret share, the carbon accounting initiator uses the public key contained in the cross-chain identity information declared in the state channel to encrypt the secret share and put it into the genesis block of the state channel. This block will be stored in the cross-chain transaction contract process on all business chains through the cross-chain proxy as the genesis block of the cross-chain transaction blockchain.

[0152] (3) Key reconstruction phase

[0153] When the state channel submits a new block to the chain, it needs to use a shared key for encryption. The carbon accounting initiator encrypts its own secret share with the public keys of other carbon accounting initiators and sends it to the corresponding carbon accounting initiator. After receiving the encrypted secret share, it uses the private key to decrypt it to obtain the sender's secret share. When reconstructing the secret, the participant P k Formula (6) is used to verify the validity of the secret shares sent by other participants. After collecting t secret shares, the Lagrange interpolation method is used according to formula (7) to reconstruct the secret. The carbon accounting initiator uses the reconstructed shared key to encrypt the block and upload the encrypted block to the chain through the cross-chain proxy.

[0154]

[0155] It is emphasized here: Although the shared key negotiation process in the above description is completed by the carbon accounting initiator, in actual application scenarios, the carbon accounting initiator (cross-chain user) usually needs to rely on third-party proxy tools to complete key negotiation and reconstruction. The proxy tool can also be directly integrated into the cross-chain agent, which helps to reduce the complexity of the system, but the premise is that the carbon accounting initiator can trust the cross-chain agent to properly handle the reconstructed key and will not leak the secret share.

[0156] like Figure 4As shown, the present invention defines the cross-chain carbon footprint accounting contract as a set of a series of states and their operation functions on each data chain. The contract is formed by state locking and logically exists in the cross-chain state channel. The cross-chain carbon footprint accounting contract is logically composed of a part of the states in the business contracts belonging to different data chains and a part of the state operation functions that meet certain conditions. The cross-chain carbon footprint accounting contract shown in the figure is composed of the states (A, B and C) contained in the two business contracts (contract1 and contract2) on two data chains (chain1 and chain2) and their operation functions (Method1, Method2, Method3 and Method4). According to the diagram, it can be seen that the present invention requires that the state operation function in the business contract must be a pure function (the same output is always obtained given the same input) and the state will not be directly modified inside the function but the modified state will be returned as a result. After the cross-chain agent collects these results and verifies them, the state is uniformly modified through the state update interface provided by the business contract. The cross-chain transactions sent by the carbon accounting initiator complete different cross-chain interoperability functions by combining different state operation functions in the cross-chain carbon footprint accounting contract. The calls to the business contracts will eventually be completed by the cross-chain agent, and the validity of the transaction will be verified through SPV.

[0157] The state operation function in the cross-chain carbon footprint accounting contract can exist in the business contracts of each data chain, or it can be transferred to the off-chain state channel based on state locking. The difference between the two is that the former is logically present in the state channel, and the data chain contract needs to be called when the state operation function is actually executed, while the latter actually exists in the state channel. When executing the state operation function, there is no need to call the business contract. The result can be obtained by executing the state operation function by the cross-chain agent, but the premise is that the cross-chain agent can have a corresponding execution environment.

[0158] The formation of a cross-chain contract mainly requires the following steps:

[0159] (1) The cross-chain proxy requests the cross-chain transaction contract to build a cross-chain carbon footprint accounting contract;

[0160] (2) The cross-chain transaction contract calls the state locking interface of the business contract to lock the state. The locked state can only be modified by submitting a block to the cross-chain transaction contract. The cross-chain transaction contract will call the state update interface provided by the business contract to complete the state modification;

[0161] (3) Each cross-chain agent mutually verifies the validity of the on-chain state locking transaction through SPV;

[0162] (4) The cross-chain proxy requests the cross-chain transaction contract to return the corresponding state operation function, and based on this, builds a real cross-chain smart contract in the off-chain state channel.

[0163] The cross-chain transaction blockchain is composed of blocks that the cross-chain agent continuously submits to the data chain. The blockchain only exists logically, and there is no actual physical node to maintain the blockchain. The purpose of designing this chain is to ensure the trustworthiness, traceability, and rollback of cross-chain interoperability. The cross-chain transaction blockchain is logically equivalent to treating each data chain as a node, and combining the business contracts on each data chain to obtain a cross-chain smart contract. Each block of the chain is submitted by the cross-chain agent to the cross-chain transaction contract of each data chain. The block contains a block header and a block body. The specific structure is as follows: Figure 5 As shown. The block header contains block height (BlockHeight), block hash (BlockHash), previous block hash (PreHash), timestamp (Timestamp), block proposer (Proposer), endorsement (Endorsement), state channel identifier (ChannelId), cross-chain transaction Merkle root (CTXRoot), channel world state Merkle root (StateRoot) and block validity field (ValidFlag). The proposer of the block is the leader of the current state channel. The proposer will change with the change of block height, that is, after each block is produced, the cross-chain agents under the chain will randomly select a new proposer through VRF. The endorsement field stores the digital signatures of all cross-chain agents in the state channel to which the current block belongs for the current transaction root and state root. Technically, this field can merge the digital signatures of multiple agents into one through the aggregate signature algorithm, which can accelerate the block validity verification. The state channel identifier of the block indicates the state channel to which the block belongs. Each state channel corresponds to a cross-chain transaction blockchain. Both the transaction root and the state root are the roots of the Merkle tree. The difference is that the transaction root is formed by recursive hashing of cross-chain transactions in pairs, while the state root is formed by recursive hashing of the world state of the state channel in pairs after all cross-chain transactions in the current block are executed. There are two main reasons why the world state of the state channel is put into the block: first, each time the cross-chain transaction contract calls the business contract, it is necessary to check whether the state operation involved in the cross-chain sub-transaction is legal. The cross-chain transaction contract only needs to read the most recent block to obtain the latest world state; second, after each block is submitted, the cross-chain transaction contract updates the corresponding state of the corresponding business contract according to the latest world state contained in the block, that is, calling the business contract only outputs the call result but does not directly modify the state.

[0164] The detailed structure of the state (State) is used to indicate the operation method (Method1-n) of a business contract (ContractName) on a data chain (ChainId) for a state (Key). This indicates that the business contract cannot be a conventional smart contract, but a collection of multiple methods for operating different states, all of which are pure functions. The state channel identifier field (ChannelId) in the cross-chain transaction (CTX) is used to indicate the state channel to which the cross-chain transaction received by the cross-chain transaction contract belongs. Different state channels usually correspond to different carbon accounting initiators and different transaction validity check operations. The sender field and signature field of the cross-chain transaction respectively represent the sender identity information of the current cross-chain transaction and the digital signature information signed using the key corresponding to the identity information. The identity information includes the data chain identifier (ChainId) and the user identifier (UserId). The effective execution load in the cross-chain transaction is multiple cross-chain sub-transactions (SubCTX), each of which contains a state and its corresponding operation method index (MethodIndex) and call parameters. Each cross-chain transaction combines multiple cross-chain sub-transactions involving different data chain states to complete different cross-chain interoperability functions. The Flag field in the cross-chain transaction indicates the execution status of the cross-chain transaction.

[0165] The execution process of a cross-chain transaction is briefly described as follows:

[0166] (1) The cross-chain agent parses the cross-chain transaction to obtain relevant information of the cross-chain transaction blockchain, and verifies the legitimacy of the cross-chain transaction based on the carbon accounting initiator information of the chain (such as signature verification, time validity verification, etc.);

[0167] (2) The cross-chain proxy broadcasts the cross-chain transaction within the channel;

[0168] (3) The leader node of the cross-chain channel selects a batch of cross-chain transactions and distributes them to the working nodes (shard nodes) for execution using a parallel scheduling algorithm;

[0169] (4) The leader node collects the execution results, generates a pre-committed block and broadcasts it within the channel;

[0170] (5) Each cross-chain agent independently verifies the correctness of the pre-submitted block and submits the block to the cross-chain transaction contract of the data chain to which it belongs.

[0171] (6) The channel re-elects the leading node for the next round of transaction execution process.

[0172] In order to enable cross-chain transactions to be executed in parallel off-chain, all cross-chain transactions in a block (cross-chain transactions in a block are selected by the leading node) are obtained through parallel state sharding, which contains multiple rounds of execution. The cross-chain proxy dispatches the execution tasks of the corresponding cross-chain sub-transactions to the working nodes based on the sharding and collects and aggregates the states of the two execution rounds. Figure 6 The process is shown in Figure 1. The three cross-chain transactions in the figure involve four states, namely A, B, C and D. For simplicity, these states do not specify the data chain and business contract to which they belong in the figure, which does not affect the subsequent discussion. In the structure field of the cross-chain sub-transaction, as long as there is a difference in the chainId, ContractName and Key fields, it is considered a different state. The execution order of cross-chain sub-transactions in a cross-chain transaction should follow its order in the cross-chain transaction. For example, CTX 1 The sub-transaction B+20 in the transaction should be executed after A-10 and before D-10. However, operations on different states between different cross-chain transactions are mutually exclusive, so operations on these states can be executed in parallel. For example Figure 6 The two operations that can be executed in parallel in the first execution round operate on different states A and C respectively. These two operations are CTX 1 and CTX 2 The first cross-chain transaction in the block. If state sharding is not used to execute all cross-chain transactions in the block, it will take seven business contracts to complete the call in sequence, and more SPV verifications will be required (the specific number depends on the number of carbon accounting initiators); after state sharding, only four execution rounds are needed to complete the execution of the block, and at this time, the execution of cross-chain transactions does not need to call business contracts, which can not only reduce the pressure on the data chain to process cross-chain transactions, but also reduce the number of SPV verifications for on-chain transactions. Therefore, although there is network communication time between the cross-chain proxy and the working node, the state sharding that can be executed in parallel can still improve the execution efficiency of cross-chain transactions.

[0173] According to the above discussion, the key to completing the parallel execution of cross-chain transactions is to use a batch of cross-chain transactions as input to obtain a state sharding that can be executed in parallel based on a round-based system. The algorithm is shown in Algorithm 1. This algorithm abstracts cross-chain transactions into a queue of state operations, and each element in the queue corresponds to a cross-chain sub-transaction. Algorithm 1 loops and selects a cross-chain sub-transaction that can be executed concurrently from the head of the queue in the batch and adds it to the execution round. At this time, if there is still an unempty queue, it enters the division of the next concurrent execution round until all cross-chain sub-transactions are divided. There are two aspects to determine whether a cross-chain transaction can be added to a concurrent execution round:

[0174] (1) The cross-chain sub-transaction to be added cannot conflict with other elements in the queue of the cross-chain transactions that have already been added to the execution round. This ensures that there will be no write conflicts with other cross-chain transactions during the execution of a cross-chain transaction, such as other cross-chain transactions modifying the input status of the cross-chain sub-transaction that has not yet been executed;

[0175] (2) The cross-chain sub-transaction to be added cannot conflict with the elements that have already been added to the execution round. This ensures that only one cross-chain sub-transaction operating the same state can be executed in one execution round.

[0176] Algorithm 1

[0177]

[0178] After obtaining the state shards that can be executed in parallel based on the turn-based system, the cross-chain proxy can execute cross-chain transactions in parallel. The specific process is as follows:

[0179] (1) The cross-chain proxy needs to dispatch the corresponding cross-chain sub-transaction execution tasks to the working nodes. The cross-chain proxy uses formula (8) to determine the dispatch process, where HASH(state) is a hash function and n is the number of state shard servers owned by the cross-chain proxy. State mapping through hash functions can dynamically respond to inputs of different data types, and can also map state shards to working nodes in a relatively uniform manner, while also minimizing the situation where a large number of computing tasks are piled up on a small number of working nodes.

[0180] SHARD_OF(state)=HASH(state)%n(8)

[0181] (2) Between two execution rounds, the cross-chain proxy will collect the execution results of the previous execution round and aggregate the results with the current world state. Then, before starting the next execution round, the latest aggregated world state will be broadcast between the working nodes to achieve state sharing of the working nodes between the two execution rounds. The state aggregation operation can be expressed by formula (9). RoundState i Indicates the round state after the i-th execution round is completed, WorkerState 1-n They respectively represent the execution results returned by the working node of the cross-chain proxy, which contains the state shards modified by the cross-chain sub-transaction.

[0182]

[0183] Use XOR instead of continuous hashing or other methods to get RoundState iThe reason is that XOR has nothing to do with the order of operations. In multi-threaded communication within the cluster, the order of messages from the worker nodes to the cross-chain proxy may be different. Therefore, by using the XOR operation, the cross-chain proxy can process the returned results as quickly as possible without waiting for all worker nodes to return.

[0184] (3) After completing all execution rounds, the cross-chain agent obtains the latest world state that needs to be recorded in the block by finding the union of all round states. This operation can be expressed by formula (10), where WorldState i Indicates the corresponding world state after the execution of the i-th block. The first world state is obtained through state locking.

[0185]

[0186] (4) If the cross-chain proxy finds that any cross-chain transaction has an exception, the cross-chain proxy will roll back the state, discard the pre-committed block, and move the transactions in the block back into the transaction pool to wait for the next execution. In other words, any exception in the transactions in the block will cause all transactions in the block to fail. Although this is a one-size-fits-all approach, if the number of failed transactions is small, fewer blocks will fail.

[0187] After the above steps, the cross-chain proxy in the state channel uses the same sharding strategy and world state update method, and different working node clusters can perform the same execution of cross-chain transactions in the block and check the results with other clusters. In this way, the consistency of the state sharding can be guaranteed, ensuring that the carbon accounting data is calculated strictly according to the accounting logic specified in the cross-chain carbon footprint accounting contract.

[0188] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made in form and details without departing from the scope defined by the claims of the present invention.

Claims

1. A carbon footprint accounting and tracing method based on cross-chain technology, characterized by: The following steps are involved: S1: The carbon accounting initiator provides identity information to the cross-chain transaction contract of the data chain to which it belongs; The carbon accounting initiators negotiate a shared key through the Pedersen VSS algorithm and open an off-chain state channel, in which cross-chain transactions are performed. The shared key is used to encrypt the blocks generated in the channel. The steps for establishing the off-chain state channel are as follows: The carbon accounting initiator of the data chain Chain1, as the initiator U of the state channel establishment, sends a channel establishment request to the cross-chain transaction contract CTC; the channel establishment request includes U's cross-chain identity information CCIdInfo and the cross-chain identity information of other carbon accounting initiators P that need to be included in the channel; After verifying that U's cross-chain identity information is legitimate, the cross-chain transaction contract of a data chain sends a VRF selection instruction to the cross-chain proxy cluster; the VRF selection instruction randomly selects one from multiple cross-chain proxies to join the state channel, namely, cross-chain proxy 1; After the cross-chain proxy 1 parses the request, it submits the request to the cross-chain transaction contract through the proxy of data chain Chain2 according to the source chain identity information of the carbon accounting initiator P; after verifying that the identity information contained in the request is correct, P submits a channel response message to the cross-chain transaction contract and randomly selects cross-chain proxy 2 again through VRF; Cross-chain agent 1 and cross-chain agent 2 establish a relay communication channel and negotiate channel preparation information, including the channel identifier channelId and the identity information of all carbon accounting initiators; S2: The carbon accounting initiator deploys a cross-chain carbon footprint accounting contract in the state channel. The cross-chain carbon footprint accounting contract is a collection of a series of states and their operation functions on each data chain; S3: Different carbon accounting initiators submit cross-chain transactions to their respective data chains at the same time. The cross-chain transaction contract batches these transactions after verifying their legitimacy and triggers cross-chain events on the chain. S4: The cross-chain proxy that monitors cross-chain events on its own data chain sends the received cross-chain transactions to the leader node in the channel. The leader node selects transactions that meet the conditions from the transaction pool according to the state channel configuration information and broadcasts the transactions in the channel; the transactions are sharded according to the states involved, and then the cross-chain proxy distributes the execution tasks to the shard servers; S5: After the shard server completes the task, the cross-chain proxy collects the execution results and performs status aggregation. After the collection and aggregation are completed, the cross-chain proxy packages the executed transactions and results and generates a pre-committed block, and broadcasts the pre-committed block in the channel. The cross-chain proxy node that receives the pre-submitted block verifies the block header. When all cross-chain proxies pass the verification, the channel status is updated, and the pre-submitted block is submitted to the cross-chain transaction contract of the data chain to which they belong; When the cross-chain agent submits a new block, it confirms through the SPV trust chain whether all carbon accounting initiators have correctly submitted the new block; the new leader node is randomly generated through the VRF algorithm after each round of new block generation.

2. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 1 is characterized by: The VRF selection instruction is used to randomly select a cross-chain proxy to join the state channel. The selection process is as follows: (1) The user generates a key pair (pk, sk) through an asymmetric encryption algorithm, where pk is the public key and sk is the secret key; (2) The user inputs the message m and private key sk into the VRF generation function to obtain a pseudo-random number r and the proof pi corresponding to r: (r,pi)←VRF GEN (sk,m)(1) (3) The verifier inputs r, pi and pk into the VRF verification function to determine whether r is generated by sk held by the user based on the message m. If the verification passes, then: VRF VERIFY (r,pi,pk)==true(2)。 3. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 1 is characterized by: The process of negotiating a shared key through the PedersenVSS algorithm specifically includes: The initiator who requests to open the cross-chain state channel is U; U initializes the following parameters: the number of carbon accounting initiators n, the selected large prime numbers p and q, q is the large prime factor of p-1, group G q It's Z p * = {1...p-1} unique subgroup of order q, g and h are G q The generator and discrete logarithm log g h unknown; (1) Initialization phase 1) U selects a t-1 order polynomial (3), where s is a randomly selected key, 为 Randomly selected polynomial coefficients, 1≤i≤t-1; for each coefficient a of the polynomial i , U selects a random number b i ∈Z p * , public polynomial coefficient a i The commitment value E i =E(a i ,b i ), E i Calculate using formula (4); 2) U selects another t-1 order polynomial (5), where r is a random number, and publicly commits to the value E0 = E(s, r); U Calculations k =f(k) and r k =g(k), where 1≤k≤n, and (s k ,r k ) is sent as a secret share to the carbon accounting initiator P; (2) Secret Share Verification Phase Carbon accounting initiator P k When receiving the secret share, use formula (6) to determine the correctness of the secret share: After verifying the correctness of the secret share, the carbon accounting initiator uses the public key contained in the cross-chain identity information declared in the state channel to encrypt the secret share and put it into the genesis block of the state channel. The genesis block is stored in the cross-chain transaction contract process on all business chains through the cross-chain proxy as the genesis block of the cross-chain transaction blockchain; (3) Key reconstruction phase When the state channel submits a new block to the chain, it uses a shared key for encryption; the carbon accounting initiator encrypts its own secret share with the public keys of other carbon accounting initiators and sends it to the corresponding carbon accounting initiator. After receiving the encrypted secret share, it uses the private key to decrypt it to obtain the sender's secret share; when reconstructing the secret, the participant P k Formula (6) is used to verify the validity of the secret shares sent by other participants. After collecting t secret shares, the Lagrange interpolation method is used according to formula (7) to reconstruct the secret. The carbon accounting initiator uses the reconstructed shared key to encrypt the block and upload the encrypted block to the chain through the cross-chain proxy.

4. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 1 is characterized by: The cross-chain carbon footprint accounting contract is formed through the following steps: (1) The cross-chain proxy requests the cross-chain transaction contract to build a cross-chain carbon footprint accounting contract; (2) The cross-chain transaction contract calls the state locking interface of the business contract to lock the state. The locked state can only be modified by submitting a block to the cross-chain transaction contract. The cross-chain transaction contract calls the state update interface provided by the business contract to complete the state modification; (3) Each cross-chain agent mutually verifies the validity of the on-chain state locking transaction through SPV; (4) The cross-chain proxy requests the cross-chain transaction contract to return the corresponding state operation function, and based on this, builds a real cross-chain smart contract in the off-chain state channel.

5. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 3 is characterized by: The cross-chain transaction blockchain is composed of blocks that the cross-chain agent continuously submits to the data chain; The cross-chain transaction blockchain regards each data chain as a node and combines the business contracts on each data chain to obtain a cross-chain smart contract; Each block of the cross-chain transaction blockchain is submitted by the cross-chain agent to the cross-chain transaction contract of each data chain. The block contains a block header and a block body; the block header contains a block height BlockHeight, a block hash BlockHash, a previous block hash PreHash, a timestamp Timestamp, a block proposer Proposer, an endorsement Endorsement, a state channel identifier ChannelId, a cross-chain transaction Merkle root CTXRoot, a channel world state Merkle root StateRoot and a block validity field ValidFlag; the proposer of the block is the leader of the current state channel, and the proposer changes with the change of the block height, that is, after each block is produced, the off-chain cross-chain agents randomly select a new proposer through VRF; The endorsement field stores the digital signatures of all cross-chain proxies in the state channel to which the current block belongs on the current transaction root and state root; the endorsement field combines the digital signatures of multiple proxies into one through an aggregate signature algorithm; The state channel identifier of a block indicates the state channel to which the block belongs. Each state channel corresponds to a cross-chain transaction blockchain. The transaction root is the root of the Merkle tree formed by recursive hashing of cross-chain transactions in pairs; the state root is the root of the Merkle tree formed by recursive hashing of the world state of the state channel in pairs after all cross-chain transactions in the current block are executed.

6. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 3 is characterized by: The detailed structure of the state State is used to indicate the operation method Method1-n of a business contract ContractName on a data chain ChainId for a state Key; The state channel identifier field ChannelId in CTX in a cross-chain transaction is used to indicate the state channel to which the cross-chain transaction received by the cross-chain transaction contract belongs; The sender field and signature field of the cross-chain transaction respectively represent the identity information of the sender of the current cross-chain transaction and the digital signature information signed using the key corresponding to the identity information. The identity information includes the data chain identifier ChainId and the user identifier UserId; The effective execution load in a cross-chain transaction is multiple cross-chain sub-transactions SubCTX, each of which contains a state and its corresponding operation method index MethodIndex and call parameters; Each cross-chain transaction combines multiple cross-chain sub-transactions involving different data chain states to complete different cross-chain interoperability functions; The Flag field in a cross-chain transaction indicates the execution status of the cross-chain transaction.

7. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 3 is characterized by: The execution process of cross-chain transactions is described as follows: (1) The cross-chain agent parses the cross-chain transaction to obtain relevant information of the cross-chain transaction blockchain and verifies the legitimacy of the cross-chain transaction based on the carbon accounting initiator information of the chain; (2) The cross-chain proxy broadcasts the cross-chain transaction within the channel; (3) The leader node of the cross-chain channel selects a batch of cross-chain transactions and distributes them to the working nodes for execution using a parallel scheduling algorithm; (4) The leader node collects the execution results, generates a pre-committed block and broadcasts it within the channel; (5) Each cross-chain agent independently verifies the correctness of the pre-submitted block and submits the block to the cross-chain transaction contract of the data chain to which it belongs; (6) The channel re-elects the leading node for the next round of transaction execution process.

8. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 3 is characterized by: The sharding of the transaction according to the states involved specifically includes: Abstract cross-chain transactions into a queue of state operations, where each element in the queue corresponds to a cross-chain sub-transaction; Select a cross-chain transaction that can be executed concurrently from the head of the queue and add it to the execution round. If there is still an unempty queue, enter the next concurrent execution round until all cross-chain transactions are divided; There are two aspects to determine whether a cross-chain transaction can be added to a concurrent execution round: (1) The cross-chain transaction to be added cannot conflict with other elements in the queue of the cross-chain transaction that has already been added to the execution round; (2) The cross-chain transaction to be added cannot conflict with the elements that have already been added to the execution round; The steps for state sharding are as follows:

1. Initialize the variable round to 0, indicating the number of execution rounds; initialize the variable concurrenceIndexes to an empty array, indicating the set of cross-chain transaction numbers that have been added to the concurrent set; initialize the variable concurrenceRounds to a mapping, with the key being the concurrent set number and the value being the set of cross-chain sub-transactions that can be executed concurrently; 2. For CTXs = {CTX1, ..., CTX n Each cross-chain transaction CTX in i Do the following: 2.1 If CTX i If there is no cross-chain transaction in the transaction, the next cross-chain transaction is processed, that is, returning to step 2; 2.2 Obtain CTX i The first cross-chain transaction subCTX in 2.3 Determine whether subCTX can join the concurrent collection; 2.3.1 Check whether subCTX is consistent with the jth CTX j The states in are the same, if they are the same, there is a conflict, j <i; 2.3.2 Check whether the state of subCTX is the same as that of the concurrent rounds that have been added. If they are the same, there is a conflict; 2.4 If there is a conflict in any step of 2.3.1 or 2.3.2, subCTX cannot join the round and returns 2; 2.5 If there is no conflict between 2.3.1 and 2.3.2, add subCTX to the concurrent set, that is, add subCTX to the round-th concurrent set in concurrenceRounds, and add the index i of the current cross-chain transaction to the concurrenceIndexes array; 2.6 Remove CTX i subCTX in; 3. If there are still undivided cross-chain transactions in CTXs, the round is incremented by 1 and enters the next division round, that is, returns to 2; 4. Return the division result concurrenceRounds.

9. The carbon footprint accounting and tracing method based on cross-chain technology according to claim 3 is characterized by: The steps for the cross-chain proxy to execute cross-chain transactions in parallel are as follows: (1) The cross-chain proxy dispatches the corresponding cross-chain sub-transaction execution tasks to the working nodes. The cross-chain proxy uses formula (8) to determine the dispatch process, where HASH(state) is a hash function and n is the number of state shard servers owned by the cross-chain proxy. The state is mapped through the hash function to dynamically respond to inputs of different data types and map the state shards to the working nodes in a relatively uniform manner. SHARD_OF(state)=HASH(state)%n (8) (2) Between two execution rounds, the cross-chain proxy collects the execution results of the previous execution round and aggregates the results with the current world state. Then, before starting the next execution round, the latest aggregated world state is broadcast between the working nodes to achieve state sharing of the working nodes between the two execution rounds. The state aggregation operation is expressed by formula (9): RoundState i Indicates the round state after the i-th execution round is completed, WorkerState 1-n They respectively represent the execution results returned by the working node of the cross-chain proxy, which contain the state shards modified by the cross-chain sub-transaction; (3) After completing all execution rounds, the cross-chain agent obtains the latest world state that needs to be recorded in the block by finding the union of all round states, expressed as: Where WorldState i It indicates the corresponding world state after the execution of the i-th block. The first world state is obtained by state locking; (4) If the cross-chain proxy finds that any cross-chain transaction has an abnormality in its execution, the cross-chain proxy will roll back the state, discard the pre-committed block, and move the transactions in the block back into the transaction pool to wait for the next execution.

Images