Carbon emission factor data traceability management system based on block chain

Abstract

The invention discloses a block chain-based carbon emission factor data traceability management system, particularly relates to the technical field of cross-supply-chain carbon data management, and is used for solving the problem that cross-enterprise / cross-industry effective association of carbon emission data under an existing single-chain architecture cannot be realized. The problems that the whole life cycle carbon emission data of the same product is repeatedly calculated and accounting boundaries are overlapped are solved; the method comprises the following steps: acquiring a carbon emission factor data packet of each participant through a data acquisition module; the block evidence storage module writes the data packet into a block chain to generate a non-tampering block; the cross-chain identification module creates a cross-chain traceability identifier containing a product batch number and an arrangement stage mark for the block; the coherence detection module analyzes data coherence during cross-chain request, and if the data coherence is lower than a threshold value, cross-chain verification based on matching of the mark and the batch number is triggered; the batch verification module executes repeatability verification on data in different stages of the same batch after verification is passed; and the traceability integration module integrates the verification data to generate a global carbon footprint traceability record and stores the global carbon footprint traceability record to a cross-chain shared account book.

Description

Technical Field

[0001] The present invention relates to the technical field of cross - supply - chain carbon data management. More specifically, the present invention relates to a blockchain - based carbon emission factor data traceability management system. Background Art

[0002] In the field of carbon emission management, due to its non - tamperable feature, blockchain technology has been applied to the carbon data traceability within enterprises. The current mainstream solutions adopt a single - chain architecture (such as private chains based on Hyperledger Fabric or Ethereum) to achieve the carbon emission records and verification of a single enterprise's production process. The International Organization for Standardization (ISO) 14067 clearly requires that the carbon footprint of a product throughout its life cycle should cover multiple links such as raw materials, manufacturing, transportation, etc.

[0003] In the cross - enterprise / cross - industry supply - chain collaboration scenario, the existing single - chain traceability system lacks data interoperability between systems, resulting in the repeated calculation of carbon emission data of the same product on different enterprise chains. For example, the emission data of battery manufacturers and the logistics data of automobile manufacturers cannot be automatically associated, forming overlapping accounting boundaries. This repeated carbon emission statistics caused by multi - chain data islands leads to an inflated carbon footprint of the overall supply chain. Summary of the Invention

[0004] In order to overcome the above - mentioned defects of the prior art, the embodiments of the present invention provide a blockchain - based carbon emission factor data traceability management system to solve the problems put forward in the above - mentioned background art.

[0005] To achieve the above object, the present invention provides the following technical solutions: A blockchain - based carbon emission factor data traceability management system, comprising: A data acquisition module: obtaining carbon emission factor data packets submitted by each participant in the supply chain; A block deposit and certification module: writing the carbon emission factor data packets into blockchain nodes through a distributed consensus mechanism to generate non - tamperable data blocks with time stamps; A cross - chain identification module: creating a cross - chain traceability identifier for each non - tamperable data block, and the cross - chain traceability identifier includes a product batch number and an emission stage mark; A coherence detection module: when a data call request is captured by a cross - chain gateway, performing Fourier transform on the data related to the emission stage and calculating the cross - spectral density coherence. If the cross - spectral density coherence is lower than a preset coherence threshold, matching the emission stage mark with the product batch number through a cross - chain verification protocol and determining whether the cross - chain verification is passed; A batch verification module: when the cross - chain verification is passed, performing a repeatability check on the carbon emission factor data packets with different emission stage marks under the same product batch number; Traceability integration module: Integrate the carbon emission factor data packets that have passed the repeatability verification according to the product batch number, generate a global carbon footprint traceability record, and store it in the cross-chain shared ledger.

[0006] In a preferred embodiment, the method for obtaining the carbon emission factor data packets submitted by each participant in the supply chain includes: Receive the carbon emission factor data packets uploaded by each participant in the supply chain. The carbon emission factor data packets include an emission stage code, a product batch number, direct emission data, indirect emission data, a timestamp, and a measurement unit.

[0007] In a preferred embodiment, write the carbon emission factor data packets into the blockchain nodes through a distributed consensus mechanism to generate an immutable data block with a timestamp, including: Verify whether the carbon emission factor data packets contain a complete field combination; When more than a preset proportion of the verification nodes confirm that the fields are complete and conform to the predefined data structure, extract the hash value of the latest block in the current blockchain and combine it with the carbon emission factor data packets to generate a new block data body; Execute the proof-of-work algorithm on the new block data body to calculate a random number that meets the target difficulty, and add the random number to the new block data body to form a complete data block; Generate an immutable data block carrying Coordinated Universal Time data with a timestamp field based on the complete data block.

[0008] In a preferred embodiment, create a cross-chain traceability identifier for each immutable data block, including: Extract the product batch number and emission stage code contained in the immutable data block; Concatenate the product batch number and the emission stage code in a preset order to form an original identification string; Perform SHA-256 hashing on the original identification string to generate a 256-bit binary digest data; Convert the binary digest data into a sixty-four-bit hexadecimal encoded string as the basic identifier; Append the Coordinated Universal Time timestamp field carried by the immutable data block to the end of the basic identifier; Combine the appended string with the current blockchain network identification code to generate the final cross-chain traceability identifier, which includes the product batch number and the emission stage mark.

[0009] In a preferred embodiment, when the cross-chain gateway captures a data call request, perform a Fourier transform on the data related to the emission stage and calculate the cross-spectral density coherence, including: When the cross-chain gateway captures a data call request, perform a Fourier transform on the data related to the emission stage in the data call request, and calculate the cross-spectrum density coherence based on the Fourier transform result.

[0010] In a preferred embodiment, if the cross-spectrum density coherence is lower than a preset coherence threshold, match the emission stage label with the product batch number through the cross-chain verification protocol and determine whether the cross-chain verification passes, including: Query the cross-chain traceability identifier associated with the current non-tamperable data block hash value through the cross-chain index database; Reverse-resolve the original metadata containing the product batch number and the emission stage code based on the cross-chain traceability identifier; Perform a full-field comparison of the product batch number obtained by reverse resolution with the product batch number included in the data call request; Perform a character-level match of the emission stage code obtained by reverse resolution with the emission stage label included in the data call request; Determine that the cross-chain verification passes only when the full-field comparison of the product batch numbers is consistent and the character-level match of the emission stage codes is successful.

[0011] In a preferred embodiment, when the cross-chain verification passes, perform a repeatability check on the carbon emission factor data packets with different emission stage labels under the same product batch number, including: Synchronously obtain the temperature, pressure, and flow sensor data based on the emission stage label, and generate a residual sequence through the fluid mechanics energy conservation equation; Generate a confidence parameter according to the standard deviation of the residual sequence and the adaptive threshold; If the confidence parameter is lower than the preset confidence threshold, discard the carbon emission factor data packet corresponding to the emission stage label; Extract the mass spectrometry detection substance peak sequence for the retained emission stage label to construct a reaction topology graph and extract the reaction topology graph feature vector; Calculate the cosine similarity between the pairwise reaction topology graph feature vectors of all non-discarded emission stage labels under the same product batch number to form a similarity matrix of emission stage labels; Based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check passes.

[0012] In a preferred embodiment, based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check passes, specifically: When the cosine similarity values of all emission stage labels in the similarity matrix are not lower than the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets of all emission stage labels is lower than the preset emission intensity difference threshold, mark that the repeatability check of the corresponding product batch number passes; When the cosine similarity values of two emission stage markers are lower than a preset similarity threshold, and the absolute value of the difference in carbon emission intensity in the carbon emission factor data packets corresponding to the two emission stage markers is lower than a preset emission intensity difference threshold, a concealed anomaly alarm is triggered.

[0013] In a preferred embodiment, the carbon emission factor data packets that have passed the repeatability check are integrated according to the product batch number to generate a global carbon footprint traceability record and store it in a cross-chain shared ledger, including: Aggregate the carbon emission factor data packets that have passed the repeatability check according to the product batch number to form a global carbon footprint traceability record corresponding to the product batch number; Synchronously store the global carbon footprint traceability record in the cross-chain shared ledger, where the global carbon footprint traceability records stored in the cross-chain shared ledger are associated with the on-chain data traceability through the product batch number.

[0014] Compared with the prior art, the present invention has the following beneficial effects: By constructing a cross-chain collaborative carbon emission data management architecture, it effectively overcomes the problem of overlapping accounting boundaries caused by multi-chain data silos; assigns a cross-chain identifier containing the product batch number and emission stage marker to each carbon emission data block stored on the chain, providing a unified indexing basis for subsequent cross-system data association; when a cross-chain data call request occurs, the system does not simply transfer data, but performs spectral analysis (Fourier transform and cross-spectrum density coherence calculation) on the data related to the emission stage through a coherence detection module; can intelligently identify whether there is an inherent correlation (i.e., whether it belongs to the same product life cycle flow) between the data submitted on different chains for the same product batch but different emission stages; if the detected coherence is insufficient (lower than the preset threshold), a cross-chain verification protocol is triggered, and the mapping relationship between the product batch number and the emission stage marker is used for accurate matching verification; only the data that passes this verification will enter the subsequent batch verification link, eliminating the isolated accounting and duplicate calculation of the carbon emissions of the same product on different enterprise chains, and ensuring the clarity and uniqueness of the carbon footprint accounting boundary; By establishing an association link through the cross-chain identifier, intelligently judging and triggering cross-chain verification using signal coherence, and performing repeatability verification and integration on the data of different emission stages under the same product batch after the verification passes, it ensures that the finally generated global carbon footprint traceability record can accurately reflect the total carbon emissions of the entire chain from raw materials to final delivery of the product, effectively avoiding data inflation caused by system fragmentation, and providing a reliable technical support for cross-supply chain carbon management collaboration. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic structural diagram of the carbon emission factor data traceability management system based on blockchain of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0016] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0017] Embodiment: Figure 1 A structural schematic diagram of the carbon emission factor data traceability management system based on the blockchain of the present invention is given. The carbon emission factor data traceability management system based on the blockchain includes: Data acquisition module: Obtain carbon emission factor data packets submitted by each participant in the supply chain; Block storage and certification module: Write the carbon emission factor data packet into the blockchain node through the distributed consensus mechanism to generate an immutable data block with a time stamp; Cross-chain identification module: Create a cross-chain traceability identifier for each immutable data block. The cross-chain traceability identifier includes the product batch number and the emission stage mark; Coherence detection module: When the cross-chain gateway captures a data call request, perform Fourier transform on the data related to the emission stage and calculate the cross-spectral density coherence. If the cross-spectral density coherence is lower than the preset coherence threshold, match the emission stage mark with the product batch number through the cross-chain verification protocol and determine whether the cross-chain verification is passed; Batch verification module: When the cross-chain verification is passed, perform a repeatability check on the carbon emission factor data packets with different emission stage marks under the same product batch number; Traceability integration module: Integrate the carbon emission factor data packets that have passed the repeatability check according to the product batch number, generate a global carbon footprint traceability record, and store it in the cross-chain shared ledger.

[0018] The technical connection relationship and implementation logic of the six modules are as follows: After the data acquisition module obtains the carbon emission factor data packet submitted by the supply chain participants, it transmits the original data packet to the block storage and certification module; the block storage and certification module writes the data packet into the blockchain node through the distributed consensus mechanism, generates an immutable data block with a timestamp, and outputs the data block to the cross-chain identification module; the cross-chain identification module creates a cross-chain traceability identifier for each data block (including the product batch number and the emission stage mark), and binds and stores the identifier with the corresponding data block; when the cross-chain gateway captures a data call request, the coherence detection module extracts the data related to the emission stage in the request, performs Fourier transform and calculates the cross-spectral density coherence: if the cross-spectral density coherence is lower than the preset coherence threshold, the cross-chain verification protocol is triggered; the cross-chain verification protocol judges the verification result by comparing the mapping relationship between the emission stage mark and the product batch number; when the cross-chain verification passes, the batch verification module retrieves the data packets with different emission stage marks under the same batch according to the product batch number, and performs repeatability verification (such as confidence analysis based on the time series volatility); the traceability integration module aggregates the data packets that pass the verification according to the product batch number, generates a global carbon footprint traceability record and writes it into the cross-chain shared ledger, where the product batch number is used as the cross-chain retrieval primary key.

[0019] Obtain the carbon emission factor data packets submitted by each participant in the supply chain, and the specific implementation is as follows: In the operation of obtaining the carbon emission factor data packets submitted by each participant in the supply chain, first, the data acquisition interface deployed on the cloud server receives the carbon emission factor data packets uploaded by each participant in the supply chain through the encrypted transmission channel. The carbon emission factor data packet contains six structured data fields: emission stage code, product batch number, direct emission data, indirect emission data, timestamp, and measurement unit. The data acquisition interface performs integrity verification on the uploaded data packet. The verification rule is that the data packet must contain all six fields at the same time and each field value is non-empty. If there are missing fields or null values, an error handling process is triggered and a prompt message containing the list of missing fields is returned to the participant.

[0020] Among them, the emission stage code is selected and input by the participant according to the life cycle stage in which the product is actually produced. The code uses a hierarchical classification system to identify the specific link where carbon emissions occur. The hierarchical classification system includes five main stage categories: raw material acquisition stage, product manufacturing stage, transportation and distribution stage, use and maintenance stage, and waste recycling stage. Each main stage is subdivided into several subcategories. For example, when the participant is an auto parts manufacturer, the emission stage code corresponding to its metal stamping process is defined as the metal forming and processing subclass under the manufacturing stage. This code is selected and input through the standardized option menu provided by the data acquisition interface, and the content of the option menu is dynamically loaded according to the production type registered by the participant.

[0021] The product batch number is generated according to a hierarchical coding rule. The coding structure consists of three parts with fixed lengths: the first part is the unique manufacturer identification code composed of 8 digits, the second part is the product type identification code composed of 4 digits, and the third part is the production batch serial number composed of 6 digits. The three parts are continuously combined to form an 18-digit fixed-length character. This number is automatically generated by the internal production management system of the participating party when starting the product production line. For example, when the production management system detects that the brake pad product starts to enter the electroplating process, it generates the number "690123450000123456" and binds it to all process records of this batch. After receiving the data packet, the data acquisition interface verifies whether there is a valid production record for this batch number by querying the distributed database. If the verification fails, the data packet is rejected from being stored in the database.

[0022] The direct emission data records the greenhouse gas emissions generated by the combustion of fossil fuels during the production process. The method for generating its value is as follows: The participating party collects the fuel consumption during the production cycle of a specific batch of products through a mass flow meter installed on the fuel pipeline of the production equipment. The fuel consumption is recorded in real time in cubic meters; multiplying the fuel consumption by the emission conversion coefficient corresponding to the fuel type to obtain the carbon dioxide equivalent value. The emission conversion coefficient is sourced from the public database regularly released by the official agency. For example, the emission conversion coefficient for natural gas fuel is 2.18 kilograms of carbon dioxide equivalent per cubic meter. The built-in calculation unit of the acquisition interface automatically performs the multiplication operation of the consumption and the coefficient, and the calculation result is retained with two decimal places of precision.

[0023] The indirect emission data records the greenhouse gas emissions corresponding to the purchased energy, which are specifically divided into two categories: electricity consumption emissions and heat consumption emissions. The electricity consumption emissions are obtained by reading the data of the smart meter installed on the main circuit of the production line. The smart meter records the power consumption (in kilowatt-hours) during the production period of a specific batch of products and multiplies it by the currently applicable emission conversion coefficient in the power supply area (for example, 0.581 kilograms of carbon dioxide equivalent per kilowatt-hour); the heat consumption emissions are obtained by multiplying the reading of the flow meter installed on the steam pipeline (in gigajoules) by the emission conversion coefficient provided by the heat supplier (for example, 85 kilograms of carbon dioxide equivalent per gigajoule of steam). All the data of the measuring instruments are transmitted to the data acquisition interface in real time through the Internet of Things gateway.

[0024] The timestamp marks the time point when the carbon emission factor data packet is successfully verified in the system. This timestamp is automatically generated by the background service of the data acquisition interface after passing the integrity verification. The time data includes year, month, day, hour, minute, second, and millisecond information, and the time zone information is marked as Coordinated Universal Time (UTC). The time data is obtained by calling the operating system kernel time service, and the operating system kernel time is synchronized with the time server through a dedicated time synchronization protocol, with the time synchronization error controlled within the range of plus or minus 50 milliseconds. For example, when the data packet is verified at 14:25:36.123 on August 19, 2023, the timestamp data "2023-08-19 14:25:36.123 UTC" is generated.

[0025] The measurement unit field declares the standard measurement form of the emission data. This field is a predefined option field, and both direct emission data and indirect emission data uniformly use kilograms of carbon dioxide equivalent as the standard measurement unit. When the original data of the participant uses other measurement units, the data acquisition interface performs a unit standardization conversion operation: if the original data uses tons as the unit, it is multiplied by 1000 to be converted to kilograms; if it uses grams as the unit, it is divided by 1000 to be converted to kilograms. The conversion operation records detailed logs, which include the original value, original unit, conversion coefficient, and conversion result. For example, the original data of 0.85 tons is recorded as 850 kilograms of carbon dioxide equivalent after conversion.

[0026] The technical associations of each field in the above implementation process are achieved through the following mechanisms: The product batch number is used as the core index to associate all field data; the emission stage code and the timestamp jointly generate a unique identifier for the data packet; the direct emission data and the indirect emission data can be numerically added under the same measurement unit system. The field data after all processing is encapsulated into a data object according to a predefined structure and transmitted to the next processing node through a message queue.

[0027] The carbon emission factor data packet is written into the blockchain node through a distributed consensus mechanism to generate an immutable data block with a timestamp. The specific implementation is as follows: In the process of writing the verified carbon emission factor data packet into the blockchain, first, no less than three verification nodes in the blockchain network perform distributed consensus verification. The verification process specifically includes: checking whether the carbon emission factor data packet completely contains the combination of six fields, namely the emission stage code, product batch number, direct emission data, indirect emission data, timestamp, and measurement unit. Among them, the emission stage code is an alphanumeric mixed string with a length of eight characters (e.g., "MANU_001"), the product batch number adopts a thirteen-digit digital coding rule (e.g., 2024061500001), the unit of direct emission data is kilograms of carbon dioxide equivalent per product unit, the unit of indirect emission data is megajoules per product unit, the timestamp field stores millisecond-level time data in Coordinated Universal Time format (e.g., 2024-06-15T08:30:45.123Z), and the measurement unit is fixed to predefined enumeration values such as "per product" or "per ton of raw material". When validating the fields, data type verification is performed synchronously: the emission stage code must match the records in the pre-registered factory production stage identification library, the product batch number must conform to the coding rule of year, month, day plus six-digit serial numbers (e.g., 2024061500001 represents the first batch of products on June 15, 2024), and the direct emission data and indirect emission data must be floating-point numbers greater than zero and the numerical range is limited between 0.001 and 1000000.

[0028] When more than two-thirds of the verification nodes confirm that all fields are complete and meet the data structure requirements (this ratio is set according to the node total constraint of 3f + 1 ≤ n in the Byzantine fault tolerance algorithm, where f is the maximum number of fault-tolerant nodes and n is the total number of nodes, and the ratio can be configured to any value within the range of 50% to 75%), the system automatically extracts the 256-bit hash value of the current latest block from the blockchain ledger. This hash value is generated through the SHA-256 algorithm and is specifically represented as a sixty-four-bit hexadecimal string (e.g., 5a3b9f...e82c). Immediately after extraction, the latest block hash value and the carbon emission factor data packet are combined in binary to form a new block data body that has not completed the proof of work. Its data structure contains two consecutive storage segments: the first sixty-four bytes store the latest block hash value, and the subsequent storage area arranges the emission stage code (8 bytes), product batch number (13 bytes), direct emission data (4-byte floating-point number), indirect emission data (4-byte floating-point number), timestamp (24-byte string), and measurement unit (12-byte string) in field order.

[0029] When performing the proof-of-work algorithm on the new block data body, an iterative calculation method is used to find a random number that meets the target difficulty. The specific process is as follows: Reserve a four-byte random number space at the head of the new block data body, initialize the random number value to 0, and loop through the following operations: Write the current random number into the reserved space, calculate the SHA-256 hash value of the entire data body, check whether the number of leading zero bits in the binary form of the hash value reaches the current network difficulty target value N (N is an integer). If it does not reach, add 1 to the random number and repeat the calculation. Stop the calculation when the number of leading zeros ≥ N, and record the valid random number value at this time. The difficulty target value N is dynamically adjusted according to the average generation time of the last ten blocks in the blockchain: Let the actual average block time be T seconds, and the target interval be 600 seconds, then the new difficulty N_new = N_old×(T / 600), and the adjusted N value range is limited between 16 and 32 (that is, the number of leading zeros is required to be 16 - 32 bits). The random number search range is limited between 0 and 4294967295 (that is, the maximum value of a four-byte unsigned integer). If no solution is found after traversing the entire range, temporarily reduce the difficulty target value N by 1 and search again.

[0030] When a random number that meets the requirements is found, write it into the reserved space to form a complete data block. At this time, the data block size is fixed as: four-byte random number + sixty-four-byte parent hash value + sixty-five-byte carbon emission factor data packet field data (8 + 13 + 4 + 4 + 24 + 12 = 65 bytes). When generating the final immutable data block based on this complete data block, the system automatically attaches a creation timestamp in Coordinated Universal Time format. This timestamp data is sourced from the weighted average time of at least three time servers (for example, synchronized using the NTP protocol from time.windows.com, ntp.aliyun.com, pool.ntp.org, and weights are assigned based on the historical clock deviation values of each server. The weight decreases by 10% for every 1 millisecond increase in deviation). The timestamp storage location is fixed in the eight-byte field at the end of the data block, and the writing format is YYYYMMDDhhmmssmmm (for example, 20240615083045123).

[0031] The immutability of the data block is achieved through a dual mechanism: The first is that the latest block hash value contained within the block forms a forward pointer to the cryptographic digest of the previous block in the blockchain; the second is that when subsequent blocks are generated, their headers will contain the SHA-256 hash value of this block, forming a backward pointer chain. Modifying any block's data will cause its hash value to change, thereby breaking the chain association. For example, if the product batch number field is tampered with (such as changing 2024061500001 to 2024061500002), the recalculated hash value of the data block will change, causing the original proof-of-work nonce to become invalid (the number of leading zeros in the new hash value does not meet the difficulty target), and it will not match the original hash value stored in the subsequent blocks.

[0032] In the continuous maintenance after data is written, each verification node performs a chain integrity check once an hour: Starting from the current block and tracing back to the genesis block, perform the following operations block by block: Read the hash value H1 of the parent block stored in the current block, calculate the actual hash value H2 of the previous block. When H1 and H2 are inconsistent, trigger the resolution mechanism. The specific process of the resolution is as follows: Broadcast a fork alert to the entire network, count the block heights held by all nodes, and select the valid chain with the highest height as the main chain (a valid chain is defined as a chain that continuously passes the proof-of-work verification). The block generation rate is controlled to generate a new block every ten minutes, which is achieved by dynamically adjusting the target difficulty value of the proof-of-work. The difficulty coefficient is adjusted at 0:00 every Sunday: Let the actual average block generation time of last week be T seconds (calculated based on the block timestamp), and the benchmark difficulty of last week be D_old, then the new difficulty D_new = D_old × (T / 600), where the value range of D_new is from 65536 to 4294967296 (corresponding to 2 to the 16th power to 2 to the 32nd power). If T < 300 seconds, take 300 seconds; if T > 1200 seconds, take 1200 seconds as the calculated value.

[0033] Create a cross-chain traceability identifier for each immutable data block, and the specific implementation is as follows: During the process of generating the cross-chain traceability identifier, first extract the product batch number and the emission stage code from the fixed storage location of the immutable data block. The product batch number is located in the range from the 13th byte to the 25th byte of the data block, and the emission stage code is located in the range from the 6th byte to the 13th byte. When the extraction operation is executed, the field validity is automatically verified: The product batch number must be 13 consecutive numeric characters, such as 2024061500001; the emission stage code must consist of 8 letters or numbers, such as MANU_001; if non-numeric characters are detected or the length is insufficient, the process is terminated and an error report is generated.

[0034] Concatenate the product batch number and the emission stage code in a preset order to form an original identification string. The preset order is fixed with the emission stage code first and the product batch number second, without adding a separator in the middle. During the concatenation process, character set conversion is performed: convert the lowercase letters in the emission stage code to uppercase. For example, convert manu_001 to MANU_001; the product batch number remains in its original numerical state. The final original identification string has a length of 21 characters, and its storage format is a byte array encoded in UTF-8. For example, MANU_0012024061500001 corresponds to the byte sequence [77,65,78,85,95,48,48,49,50,48,50,52,48,54,49,53,48,48,48,48,49].

[0035] When performing the SHA-256 hash operation on the original identification string, the input data is the aforementioned byte array, and the hash calculation buffer is initialized to 512 bits. The operation process includes 64 rounds of iterative processing. Each round of processing includes: reading a 512-bit block from the input data, performing an encryption transformation that combines a bit selection function, modular addition operation, and circular shift operation on this block, updating the intermediate hash value status register, and finally outputting 256-bit binary digest data. This operation follows the algorithm process defined by the Internet Engineering Task Force (IETF) RFC 6234 standard. The same input will always produce the same output. For example, when the input is MANU_0012024061500001, a fixed binary sequence is always output. A timeout protection mechanism is set during the operation process: if the calculation time exceeds 1000 milliseconds, the operation is forced to terminate and a backup calculation unit is enabled.

[0036] When converting the 256-bit binary digest data into a 64-bit hexadecimal encoded string, it is split into groups of 4 binary digits each, and each group is mapped to a hexadecimal character in sequence. The mapping rules are as follows: 0000 is mapped to 0, 0001 is mapped to 1, 0010 is mapped to 2, 0011 is mapped to 3, 0100 is mapped to 4, 0101 is mapped to 5, 0110 is mapped to 6, 0111 is mapped to 7, 1000 is mapped to 8, 1001 is mapped to 9, 1010 is mapped to A, 1011 is mapped to B, 1100 is mapped to C, 1101 is mapped to D, 1110 is mapped to E, and 1111 is mapped to F. The converted string is stored in a 64-byte fixed-length buffer, and leading and trailing whitespace characters are automatically removed. For example, the binary sequence 101101...0011 is converted to 5A3B9F...E82C. A parity check is performed during the conversion process: in each byte composed of two hexadecimal characters, the binary form must contain an even number of 1s. If the check fails, the hash operation is performed again.

[0037] Append the Coordinated Universal Time (UTC) timestamp field carried by the additional non-tamperable data block to the end of the basic identifier. The timestamp field is located in the last 8 bytes of the data block and is stored in the format of a continuous digital combination of year, month, day, hour, minute, second, and millisecond. The append operation adopts a delimiter connection strategy: insert an underscore character between the basic identifier and the timestamp. For example, 5A3B9F...E82C_20240615083045123. Verify the validity of the timestamp before appending: the range of the year value is limited to the interval from 2000 to 2100, such as 2024; the range of the month value is limited to 1 to 12, such as 6; the date value is dynamically limited according to the month. For example, in June, it is limited to 1 to 30. If the value exceeds the boundary, it will be replaced with the latest synchronized time of the blockchain network.

[0038] In the step of generating the final cross-chain traceability identifier, combine the string after appending the timestamp with the current blockchain network identification code according to a preset rule. The blockchain network identification code consists of three fields with fixed lengths in sequence: the first two digits are the two-letter country code defined by the International Organization for Standardization (ISO) 3166-1 standard; the middle nine digits are the enterprise registration code, which is taken from the 9th to 17th digits of the unified social credit code registered in the National Enterprise Credit Information Publicity System; the last three digits are the chain type code, which is represented by a combination of uppercase letters and numbers to indicate the blockchain network type. When combining, use a colon delimiter to place the blockchain network identification code at the front of the appended string. For example, form a structure like CN123456789BC:5A3B9F...E82C_20240615083045123. The final cross-chain traceability identifier implicitly contains the product batch number and the emission stage mark through the basic identifier because the basic identifier is a unique representation generated by hashing the product batch number and the emission stage code, and its hexadecimal encoded string has an irreversible mathematical correlation with the original product batch number and the emission stage mark. The generated identifier has a fixed total length of 85 characters. When writing to the cross-chain index database, a two-way mapping is achieved by establishing two pairs of key-value relationships: the first pair uses the non-tamperable data block hash value as the key and the cross-chain traceability identifier as the value; the second pair uses the cross-chain traceability identifier as the key and the original metadata containing the product batch number and the emission stage code as the value, ensuring that the product batch number and the emission stage mark can be reversely resolved through the identifier.

[0039] In the character conversion stage, the hexadecimal mapping process is implemented using a predefined conversion look-up table that contains 16 entries, each storing the mapping relationship between a 4-bit binary pattern and the corresponding hexadecimal character. When validating the timestamp validity, the date range limit is implemented based on the Gregorian leap year rule: when the year is divisible by 4 but not divisible by 100, or divisible by 400, the upper limit of the date in February is 29 days; otherwise, it is 28 days. The enterprise registration code in the blockchain network identification code is extracted from the unified social credit code, which is uniformly allocated by the State Administration for Market Regulation and contains five parts: the registration management department code, the institutional category code, the administrative division code of the registration management authority, the subject identification code, and the check code. Among them, the 9th to 17th digits are the subject identification code, which is used as the unique enterprise identifier. The cross-chain index database adopts a distributed key-value storage architecture, realizes forward query through the storage method with the hash value of the immutable data block as the key and the cross-chain traceability identifier as the value, and maintains an inverted index with the cross-chain traceability identifier as the key and the block hash value as the value to realize reverse query.

[0040] When the cross-chain gateway captures a data call request, it performs Fourier transform on the data involved in the emission stage and calculates the cross-spectral density coherence. The specific implementation is as follows: When the cross-chain gateway captures a data call request, it performs a Fourier transform on the data related to the emission stage in the data call request, and calculates the cross-spectral density coherence based on the Fourier transform result. The data in the emission stage refers to the set of time-series monitoring data related to carbon emissions in the product production process extracted by the cross-chain gateway from the data call request, specifically including the instantaneous values of production equipment energy consumption (unit: kilowatt-hour), raw material decomposition rate (unit: kilogram / minute), etc., which are time-series data generated at a fixed sampling frequency. The implementation process of the Fourier transform includes four core steps: First, discretize the data in the emission stage into equally spaced sampling points according to the time series. The sampling interval is set according to the monitoring frequency of the data generation device. For example, when an industrial sensor uses a sampling rate of 10 Hz, the time interval is set to 0.1 second. The discretization formula is to convert the continuous-time signal into a sequence of 10 data points per second; Second, apply the fast Fourier transform algorithm to the discretized data sequence to convert the time-domain signal into a frequency-domain complex spectrum. The real part of the complex spectrum represents the amplitude characteristics of the frequency components, and the imaginary part represents the phase characteristics; Third, extract the real part amplitude values of the target frequency band from the complex spectrum to form the first spectrum vector. The target frequency band range is set to 0.5 Hz to 5 Hz, and this range is determined according to the typical vibration frequencies of industrial equipment defined by the international standard ISO 10816; Fourth, extract the imaginary part amplitude values of the same frequency band to form the second spectrum vector. The calculation process of the cross-spectral density coherence includes: calculating the cross-spectral matrix of the first spectrum vector and the second spectrum vector. The diagonal elements of this matrix are the auto-power spectral densities of their respective spectrum vectors, and the non-diagonal elements are the cross-power spectral densities; The cross-spectral density coherence value is obtained by dividing the square of the modulus of the cross-power spectral density by the product of the two auto-power spectral densities. The calculation formula is expressed as "the coherence value is equal to the square of the absolute value of the cross-power spectral density divided by the product of the auto-power spectral density of the first spectrum vector and the auto-power spectral density of the second spectrum vector". Its calculation result is a dimensionless value between 0 and 1. The closer the value is to 1, the stronger the linear correlation between the spectrum components.

[0041] If the cross-spectral density coherence is lower than the preset coherence threshold, match the emission stage tag with the product batch number through the cross-chain verification protocol and determine whether the cross-chain verification is passed. If it is higher than the coherence threshold, no action is taken. The specific implementation is as follows: If the calculated cross - spectral density coherence is lower than the preset coherence threshold, the cross - chain verification protocol is triggered to match the emission stage tag with the product batch number. The preset coherence threshold is set as follows: collect 1000 groups of emission stage data samples during the historical normal production cycle, and calculate the cross - spectral density coherence value for each group; calculate the arithmetic mean and standard deviation of all sample coherence values; use the result of subtracting 3 times the standard deviation from the mean as the threshold. For example, when the average coherence is 0.92 and the standard deviation is 0.02, the threshold is set to 0.92 minus 3 times 0.02, which equals 0.86. This setting follows the statistical 3σ principle to ensure coverage of 99.7% of the normal distribution data range. When the real - time calculated coherence is lower than 0.86, it is determined that there are abnormal perturbations or potential tampering risks in the data. The triggering of the cross - chain verification protocol strictly depends on the result of this threshold comparison to avoid unnecessary consumption of system resources.

[0042] In the matching process of the cross - chain verification protocol, first query the cross - chain traceability identifier associated with the hash value of the current immutability data block through the cross - chain index database. The hash value of the immutability data block refers to the unique encrypted digest value of the data block confirmed by the consensus mechanism on the blockchain, which is generated as a 256 - bit binary string using the SHA - 3 algorithm; the cross - chain index database uses a key - value pair storage structure, where the key is the data block hash value and the value is the corresponding cross - chain traceability identifier. The identifier encoding format is a 32 - byte string encoded in Base58. This mapping relationship is synchronously written into the database by the smart contract when the data is uploaded to the chain. The query operation specifically includes: using the block hash value associated with the current processed data call request as the input key; locating the storage node through the B + tree index. The leaf nodes of the B + tree store the mapping entries of the hash value and the identifier; return the cross - chain traceability identifier that exactly matches the input key; if no matching item is found, terminate the verification process and return the error code 404.

[0043] Reverse-resolve the original metadata containing the product batch number and the emission phase code from the cross-chain traceability identifier. The cross-chain traceability identifier is an encrypted string generated in the previous step by combining the product batch number and the emission phase code, with the generation algorithm being HMAC-SHA256. The reverse-resolution process requires three steps: First, input the identifier into the decryption module of the key management and decrypt it using the same AES-256 symmetric key as when generating, with the key length fixed at 256 bits; Second, split the decrypted intermediate string into two parts by the dash separator. For example, the string "P12345-E2" is split into "P12345" and "E2"; Third, the first part of the string is decoded back to the product batch number through UTF-8 decoding, and the second part of the string is restored to the emission phase code. The original metadata structure is a JSON object, containing two fixed fields: the field "product_batch_id" stores the product batch number, and the field "emission_phase_code" stores the emission phase code. For example, {"product_batch_id": "P12345", "emission_phase_code": "E2"}.

[0044] Perform a full-field comparison between the product batch number obtained by reverse-resolution and the product batch number included in the data call request. The product batch number in the data call request is passed in the form of a uniform resource locator parameter, with the parameter name "batch_id". When extracting, perform URL decoding and special character filtering processing. For example, the request path " / api / data?batch_id=P%31%32%33%34%35" is decoded to "P12345". The implementation rules for the full-field comparison include: First, compare the byte lengths of the two product batch number strings. If the lengths are not equal, directly return a non-matching result; Second, compare the ASCII code values of the two strings byte by byte. For example, compare the binary encoding of each character in "P12345" and "P12345"; Third, only when the ASCII code values of all characters are exactly the same is it determined to be a match, and the fuzzy matching strategy is disabled.

[0045] Perform character-level matching between the emission phase code obtained from reverse parsing and the emission phase marker included in the data call request. The emission phase marker is transmitted as a hypertext transfer protocol request header field in the data call request, with the field name "X-Emission-Phase". When extracting, verify whether the field value conforms to the predefined regular expression "^[A-Z][0-9]{1,2}$". For example, "E2" is a legal value while "A12a" is an illegal value. The operations for character-level matching include: First, convert the emission phase code and the emission phase marker into character arrays of equal length. For example, the code "E2" is converted into the array ['E', '2']; Second, compare the Unicode code point values of the characters one by one in the order of array indices. For example, compare the character 'E' (code point U+0045) at index 0 with the character '2' (code point U+0032) at index 1; Third, the matching process is case-sensitive. For example, the code "E2" and the marker "e2" are determined to be unmatched due to code point differences.

[0046] Only when the full-field comparison of the product batch number is consistent and the character-level matching of the emission phase code is successful, it is determined that the cross-chain verification passes. These two matching conditions form a logical AND relationship. The failure of either condition triggers the error handling mechanism: If the product batch number comparison is consistent but the emission phase code matching fails (for example, the request marker is "E3" while the parsed code is "E2"), return the error code 501; If the emission phase code matching is successful but the product batch number comparison fails (for example, the request number is "P12346" while the parsed number is "P12345"), return the error code 502; If both fail, return the error code 503. The determination result of successful verification triggers two operations: Authorize the cross-chain gateway to access the requested emission data and submit a verification success transaction to the blockchain network. This transaction includes the data call request hash value, verification timestamp, and matching result fields. The timestamp format is UTC time in the ISO 8601 standard (for example, "2023-08-15T14:30:00Z").

[0047] When the cross-chain verification passes, perform a repeatability check on the carbon emission factor data packets with different emission phase markers under the same product batch number. The specific implementation is as follows: First, synchronously obtain the temperature sensor data, pressure sensor data, and flow sensor data based on the emission stage marker. The temperature sensor data is collected in real-time by a K-type thermocouple installed on the emission pipeline at a sampling frequency of once per second, with a measurement range of -50°C to 300°C and a measurement accuracy of ±0.5°C; the pressure sensor data is collected by a piezoresistive sensor at a frequency of 10 Hz, with a measurement range covering 0 - 10 MPa and an error not exceeding 0.1% of the full scale; the flow sensor data is obtained by a turbine flowmeter at a frequency of 5 times per second, with a measurement range of 0.5 - 50 m³ / min and a linear error less than 0.2%. After time-aligning the data points of the above three types of sensors at the same time stamp, input them into the fluid mechanics energy conservation equation to calculate the residual quantity. The specific calculation process is as follows: for the sensor data at each time point, establish a theoretical energy conservation model according to Bernoulli's equation, and take the absolute value of the deviation between the measured flow value and the model prediction value as the residual quantity at this time point. Continuously process 600 sets of time point data within 60 seconds to form a residual quantity sequence with 600 elements.

[0048] Next, generate the confidence parameter based on the standard deviation of the residual quantity sequence and the adaptive threshold. The calculation formula for the standard deviation σ of the residual quantity sequence is: take the square root of the variance of all elements of the residual quantity sequence, and use the unbiased estimation form when calculating the variance (the denominator is the sequence length minus 1). The adaptive threshold is generated through a dynamic learning mechanism: obtain the historical residual sequences of the last 30 normal operating condition emission stage markers of the same production equipment, calculate the moving average μ and moving standard deviation δ of the standard deviations of these sequences, and set the adaptive threshold to μ + 3δ. The confidence parameter is defined as the ratio of σ to the adaptive threshold. When the ratio is less than 1, the confidence parameter is equal to (1 - ratio) × 100%, and when the ratio is greater than or equal to 1, the confidence parameter is set to zero. For example, when σ = 0.25 and the adaptive threshold is 0.3, the confidence parameter = (1 - 0.25 / 0.3) × 100% = 16.7%.

[0049] If the confidence parameter is lower than the preset confidence threshold, discard the carbon emission factor data packet corresponding to the emission stage marker. The preset confidence threshold is set in the system initialization stage according to the equipment type: set to 85% for chemical reaction equipment and 90% for combustion equipment. The basis for setting this threshold is the difference in the tolerance of sensor measurement errors for different equipment types. The discard operation specifically includes: writing the "low confidence" status code in the metadata of the emission stage marker, and moving the corresponding carbon emission factor data packet to the isolation storage area. The subsequent processing flow will skip the discarded data packets.

[0050] Extract the peak sequence of the mass spectrometry-detected substances from the retained emission stage markers to construct a reaction topology graph. The peak sequence of the mass spectrometry-detected substances is obtained by continuous scanning with a quadrupole mass spectrometer during the emission stage: scanning in steps of 0.1 atomic mass unit in the range of m / z 20 - 400, and recording the ion current intensity values for each mass number channel to form a peak sequence of substances containing 3,800 intensity values. The process of constructing the reaction topology graph is as follows: First, identify all peak points in the peak sequence of substances whose intensity exceeds 3 times the standard deviation of the baseline noise, and use the molecular formula of the substance corresponding to each peak point as a node; then establish edge connections based on the possibility of chemical reactions between substances. If two substances satisfy the change in Gibbs free energy of the reaction ΔG < 0 and there is a known catalytic condition, a directed edge is established between the corresponding nodes. Finally, a directed graph structure with molecular formulas of substances as nodes and reaction paths as edges is generated.

[0051] Extract feature vectors based on the reaction topology graph. The dimension of the feature vector is fixed at 256 dimensions and is generated according to the following rules: The first 128 dimensions are node feature encodings. Perform a hash operation on the molecular formulas of the substances corresponding to all nodes in the topology graph, and take the first 32 bits of the MD5 hash value of the SMILES string of the molecular formula to convert it into a 128-dimensional binary vector; the last 128 dimensions are edge feature encodings. Count the distribution of reaction types of all reaction edges (four types: oxidation reaction, reduction reaction, cracking reaction, polymerization reaction), normalize the counts of the four types of reactions to probability values, and then convert them into 128-dimensional feature vectors through Fourier transform. Finally, splice the feature vectors of the first and second parts to form a 256-dimensional reaction topology graph feature vector.

[0052] Calculate the cosine similarity between the pairwise reaction topology graph feature vectors of all non-discarded emission stage markers under the same product batch number. The cosine similarity calculation uses the standard vector angle formula: For two 256-dimensional feature vectors A and B, their similarity is equal to the dot product of A and B divided by the product of the norm of A and the norm of B. If there are N retained emission stage markers under each product batch number, an N×N symmetric similarity matrix is generated. The diagonal elements of the matrix are fixed at 1 (self-similarity of the same marker), and the non-diagonal elements store the similarity values between pairwise markers.

[0053] When the cosine similarity values of all emission stage markers in the similarity matrix are greater than or equal to the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets of all emission stage markers is less than the preset emission intensity difference threshold, the repeatability check of the product batch number is passed. The preset similarity threshold is set to 0.92, and this value is determined based on the repeatability experiment of mass spectrometry detection: the same emission sample is detected 10 times repeatedly, and the minimum value of the similarity between the eigenvectors of the reaction topology map is calculated as the threshold reference. The carbon emission intensity difference refers to the difference in the carbon emissions per unit product (kgCO2 / ton of product) in the data packets of different emission stage markers, and the preset emission intensity difference threshold is set to 5% of the baseline emission intensity (the baseline value is taken as the historical average emission intensity of this product model). After the check passes, the status flag of "qualified repeatability verification" is written into the metadata of the product batch number.

[0054] When the cosine similarity values of two emission stage markers are less than the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets of these two emission stage markers is less than the preset emission intensity difference threshold, a hidden anomaly alarm is triggered. This contradictory state indicates that although the total carbon emission data is similar (small emission intensity difference), there are significant differences in the material reaction paths (low similarity), suggesting that there may be data tampering or hidden device failures. After the alarm is triggered, three operations are performed: freeze the write permission of all carbon emission factor data packets of this batch; start the cross-chain data traceability verification process; send an alarm code containing the conflicting marker IDs to the regulatory node (code format: CAE_conflicting marker ID1_conflicting marker ID2).

[0055] Integrate the carbon emission factor data packets that pass the repeatability check according to the product batch number, generate a global carbon footprint traceability record, and store it in the cross-chain shared ledger. The specific implementation is as follows: The operation of aggregating the carbon emission factor data packets that have passed the repeatability check by product batch number is specifically implemented as follows: Extract the product batch number field carried in the carbon emission factor data packets output by the repeatability check step. Using this product batch number field as the unique index key, group the carbon emission factor data packets belonging to the same product batch number into the same data set. For multiple carbon emission factor data packets corresponding to the same product batch number, extract the carbon emission factor value fields in each data packet, and perform a weighted average calculation according to the confidence weights obtained by each data packet in the repeatability check step to generate the integrated carbon emission factor value corresponding to this product batch number. The confidence weights are dynamically set based on the comparison results of the similarity matrix in the repeatability check step. Data packets with a cosine similarity higher than the preset threshold in the similarity matrix are given higher confidence weights. For example, when the similarity values of a certain data packet with other data packets in the same batch all exceed 0.95, its confidence weight is set to 0.8, and the remaining weights are allocated to the remaining data packets according to the similarity ratio. The finally integrated carbon emission factor value is bound to this product batch number and serves as the core data field for the global carbon footprint traceability record.

[0056] The specific implementation of forming the global carbon footprint traceability record corresponding to the product batch number is as follows: After completing the aggregation of the carbon emission factor data for the same product batch number, supplement the product basic information corresponding to this product batch number. The product basic information includes the raw material source code of the product, the production process line code, and the logistics transfer node code. Among them, the raw material source code is generated by the upstream enterprise in the supply chain according to the predefined coding rules, the production process line code is automatically assigned by the manufacturing execution system according to the actual production rhythm, and the logistics transfer node code is extracted from the transportation batch records in the logistics management system. Package the integrated carbon emission factor value and the product basic information according to the predefined data structure. Each field in the data structure includes the field name, field type, field length constraint, and data source identifier. For example, the product batch number field is defined as a fixed-length 12-digit numeric character, and the raw material source code field is defined as a fixed-length 18-digit alphanumeric mixed code. The packaged global carbon footprint traceability record generates a unique data fingerprint, which is obtained by performing an operation on the binary sequence of all fields in the record using the hash algorithm and is used for subsequent data integrity verification.

[0057] The specific implementation of synchronously storing the global carbon footprint traceability record in the cross-chain shared ledger is as follows: Call the cross-chain shared ledger adaptation interface to convert the global carbon footprint traceability record into a transaction data format supported by the target blockchain. The conversion process includes writing the product batch number as the primary key into the transaction tag field, writing the data fingerprint into the transaction metadata field, and serializing the core data field in the structured data format required by the ledger; After the transaction data is signed by the node, it is broadcast to the cross-chain shared ledger network, and the consensus nodes in the network verify the validity of the transaction according to the pre-configured consensus rules. The consensus rules require that the transaction data contains a valid data fingerprint and the product batch number conforms to the coding specification; After the transaction verification passes, the global carbon footprint traceability record is written into a new block of the cross-chain shared ledger, and at the same time, an on-chain storage certificate containing the block height, timestamp, and transaction hash value is generated.

[0058] The specific implementation of realizing on-chain data traceability association is as follows: When querying the carbon footprint data of a specific product batch number, submit a query request containing the product batch number to the cross-chain shared ledger. The ledger node locates the corresponding transaction in the on-chain index according to the product batch number; By parsing the core data field in the transaction data, the original global carbon footprint traceability record is restored, and at the same time, the record integrity is verified according to the data fingerprint in the transaction metadata field; During the traceability process, the historical records of each link of the batch of products in the supply chain can be associated through the product batch number. For example, the raw material production records of the upstream supplier can be retrieved through the raw material source code, and the carbon emission data in the transportation stage can be traced through the logistics transfer node code. All associated data is ensured to be tamper-proof through the on-chain storage certificate.

[0059] The calculations involved in the embodiments are all dimensionless numerical calculations, and the preset parameters and threshold selections in the calculations are set by those skilled in the art according to the actual situation.

[0060] It should be noted that the present invention can be deployed on the device itself to achieve embedded applications, or can also run on a PC or other terminals with a user interface, so as to meet various hardware environments and usage requirements.

[0061] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center in a wireless or wired manner (such as infrared, wireless, microwave, etc.); where the wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more collections of available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

[0062] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the systems, devices, and modules described above can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0063] In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the modules is only a logical function division, and there can be other division methods in actual implementation. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces. The indirect couplings or communication connections of the devices or modules can be in electrical, mechanical, or other forms.

[0064] The modules described as separate components may or may not be physically separated. The components shown as modules may or may not be physical modules. They can be located in one place or distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0065] In addition, in each embodiment of the present application, each functional module can be integrated into a processing module, or each module can exist physically alone, or two or more modules can be integrated into one module.

[0066] If the above-mentioned function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0067] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present application, and all of them should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0068] Finally: The above is only the preferred embodiment of the present invention and is not used to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A carbon emission factor data traceability management system based on blockchain, characterized in that Including: Data acquisition module: Obtain the carbon emission factor data packets submitted by each participant in the supply chain; Block storage and certification module: Write the carbon emission factor data packets into the blockchain nodes through a distributed consensus mechanism to generate an immutable data block with a timestamp; Cross-chain identification module: Create a cross-chain traceability identifier for each immutable data block. The cross-chain traceability identifier includes the product batch number and the emission stage mark; Coherence detection module: When the cross-chain gateway captures a data call request, perform Fourier transform on the data related to the emission stage and calculate the cross-spectral density coherence. If the cross-spectral density coherence is lower than the preset coherence threshold, match the emission stage mark with the product batch number through the cross-chain verification protocol and determine whether the cross-chain verification is passed; Batch verification module: When the cross-chain verification is passed, perform a repeatability check on the carbon emission factor data packets with different emission stage marks under the same product batch number; Traceability integration module: Integrate the carbon emission factor data packets that have passed the repeatability check according to the product batch number, generate a global carbon footprint traceability record, and store it in the cross-chain shared ledger.

2. The carbon emission factor data traceability management system based on blockchain according to claim 1, characterized in that, The method for obtaining the carbon emission factor data packets submitted by each participant in the supply chain includes: Receive the carbon emission factor data packets uploaded by each participant in the supply chain. The carbon emission factor data packets include the emission stage code, product batch number, direct emission data, indirect emission data, timestamp, and measurement unit.

3. The carbon emission factor data traceability management system based on blockchain according to claim 1, wherein Write the carbon emission factor data packets into the blockchain nodes through a distributed consensus mechanism to generate an immutable data block with a timestamp, including: Verify whether the carbon emission factor data packets contain a complete field combination; When more than a preset proportion of the verification nodes confirm that the fields are complete and conform to the predefined data structure, extract the hash value of the latest block in the current blockchain and combine it with the carbon emission factor data packets to generate a new block data body; Execute the proof-of-work algorithm on the new block data body to calculate a random number that meets the target difficulty, and add the random number to the new block data body to form a complete data block; Generate an immutable data block with Coordinated Universal Time (UTC) data carrying a timestamp field based on the complete data block.

4. The carbon emission factor data traceability management system based on blockchain according to claim 1, characterized in that, Create a cross-chain traceability identifier for each immutable data block, including: Extract the product batch number and emission stage code contained in the immutable data block; Concatenate the product batch number and the emission stage code in a preset order to form an original identification string; Perform a SHA-256 hash operation on the original identification string to generate a 256-bit binary digest data; Convert the binary digest data into a sixty-four-bit hexadecimal encoded string as the basic identifier; Append the UTC timestamp field carried by the immutable data block to the end of the basic identifier; Combine the appended string with the current blockchain network identification code to generate the final cross-chain traceability identifier. The cross-chain traceability identifier includes the product batch number and the emission stage mark.

5. The blockchain-based carbon emission factor data traceability management system according to claim 1, wherein When the cross-chain gateway captures a data call request, perform Fourier transform on the data related to the emission stage and calculate the cross-spectral density coherence, including: When the cross-chain gateway captures a data call request, perform Fourier transform on the data related to the emission stage in the data call request, and calculate the cross-spectral density coherence based on the Fourier transform result.

6. The blockchain-based carbon emission factor data traceability management system according to claim 1, characterized in that, If the coherence of the cross-spectral density is lower than the preset coherence threshold, match the emission phase tag with the product batch number through the cross-chain verification protocol and determine whether the cross-chain verification passes, including: Query the cross-chain traceability identifier associated with the hash value of the current tamper-proof data block through the cross-chain index database; Reverse-resolve the original metadata containing the product batch number and the emission phase code based on the cross-chain traceability identifier; Perform a full-field comparison of the product batch number obtained by reverse resolution with the product batch number included in the data call request; Perform a character-level match of the emission phase code obtained by reverse resolution with the emission phase tag included in the data call request; Determine that the cross-chain verification passes only when the full-field comparison of the product batch numbers is consistent and the character-level match of the emission phase codes is successful.

7. The carbon emission factor data traceability management system based on blockchain according to claim 1, characterized in that, When the cross-chain verification passes, perform a repeatability check on the carbon emission factor data packets with different emission phase tags under the same product batch number, including: Synchronously obtain the temperature, pressure, and flow sensor data based on the emission phase tag, and generate a residual sequence through the hydrodynamic energy conservation equation; Generate a confidence parameter according to the standard deviation of the residual sequence and the adaptive threshold; If the confidence parameter is lower than the preset confidence threshold, discard the carbon emission factor data packet corresponding to the emission phase tag; Extract the mass spectrometry detection substance peak sequence for the retained emission phase tags to construct a reaction topology graph and extract the reaction topology graph feature vector; Calculate the cosine similarity between the pairwise reaction topology graph feature vectors of all undiscarded emission phase tags under the same product batch number to form a similarity matrix of emission phase tags; Based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check passes.

8. The blockchain-based carbon emission factor data traceability management system according to claim 7, wherein Based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check passes. Specifically: When the cosine similarity values of all emission phase tags in the similarity matrix are not lower than the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets of all emission phase tags is lower than the preset emission intensity difference threshold, mark that the repeatability check of the corresponding product batch number passes; When there are two emission phase tags with cosine similarity values lower than the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets corresponding to the two emission phase tags is lower than the preset emission intensity difference threshold, trigger a concealed anomaly alarm.

9. The carbon emission factor data traceability management system based on blockchain according to claim 1, wherein Integrate the carbon emission factor data packets that pass the repeatability check according to the product batch number, generate a global carbon footprint traceability record, and store it in the cross-chain shared ledger, including: Aggregate the carbon emission factor data packets that pass the repeatability check according to the product batch number to form a global carbon footprint traceability record corresponding to the product batch number; Synchronously store the global carbon footprint traceability record in the cross-chain shared ledger, where the global carbon footprint traceability records stored in the cross-chain shared ledger are associated with the on-chain data traceability through the product batch number.

Images