Carbon emission factor data traceability management system based on blockchain

Abstract

The present invention discloses a carbon emission factor data traceability management system based on blockchain, which specifically relates to the technical field of cross-supply chain carbon data management. It is used to solve the problem that carbon emission data cannot be effectively linked across enterprises / industries under the existing single-chain architecture, resulting in repeated calculation of carbon emission data of the same product throughout its life cycle and overlapping accounting boundaries. The data acquisition module obtains the carbon emission factor data packet of each participant; the block evidence module writes the data packet into the blockchain to generate an unalterable block; the cross-chain identification module creates a cross-chain traceability identifier for the block that includes the product batch number and emission stage mark; the coherence detection module analyzes the data coherence when requesting across the chain, and triggers cross-chain verification based on matching of mark and batch number if it is lower than the threshold; the batch verification module performs repeatability verification on data of the same batch at different stages after verification; the traceability integration module integrates the verified data to generate a global carbon footprint traceability record and stores it in 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, and more specifically, to a blockchain-based carbon emission factor data traceability management system. Background Art

[0002] In the field of carbon emissions management, blockchain technology, due to its tamper-proof nature, has been applied to internal carbon data traceability within enterprises. Current mainstream solutions utilize a single-chain architecture (such as private blockchains based on Hyperledger Fabric or Ethereum) to record and verify carbon emissions within a single enterprise's production process. ISO 14067, the International Organization for Standardization, explicitly requires the calculation of a product's carbon footprint throughout its entire life cycle, covering multiple stages, including raw materials, manufacturing, and transportation.

[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 emissions data for 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 linked, resulting in overlapping accounting boundaries. The repeated counting of carbon emissions caused by these multi-chain data islands has caused an inflated carbon footprint of the entire supply chain. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a blockchain-based carbon emission factor data traceability management system to solve the problems raised in the above-mentioned background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] The blockchain-based carbon emission factor data traceability management system includes:

[0007] Data collection module: obtains carbon emission factor data packages submitted by various supply chain participants;

[0008] Blockchain Evidence Module: Writes the carbon emission factor data packet into the blockchain node through a distributed consensus mechanism, generating an unalterable data block with a timestamp;

[0009] Cross-chain identification module: Creates a cross-chain traceability identifier for each tamper-proof data block. The cross-chain traceability identifier includes the product batch number and emission stage mark;

[0010] Coherence detection module: When the cross-chain gateway captures a data call request, it performs Fourier transform on the data related to the emission stage and calculates the cross-spectral density coherence. If the cross-spectral density coherence is lower than the preset coherence threshold, the emission stage tag and product batch number are matched through the cross-chain verification protocol to determine whether the cross-chain verification has passed;

[0011] Batch Verification Module: When cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number;

[0012] Traceability integration module: Integrate the carbon emission factor data packages that have passed repeatable verification according to the product batch number, generate a global carbon footprint traceability record and store it in a cross-chain shared ledger.

[0013] In a preferred embodiment, the method for obtaining the carbon emission factor data package submitted by each supply chain participant includes:

[0014] Receive carbon emission factor data packages uploaded by various supply chain participants. The carbon emission factor data packages contain emission stage code, product batch number, direct emission data, indirect emission data, timestamp and measurement unit.

[0015] In a preferred embodiment, the carbon emission factor data packet is written into the blockchain node through a distributed consensus mechanism to generate an unalterable data block with a timestamp, including:

[0016] Verify that the carbon emission factor data package contains the complete field combination;

[0017] When more than a preset proportion of verification nodes confirm that the fields are complete and conform to the predefined data structure, the hash value of the latest block in the current blockchain is extracted and combined with the carbon emission factor data packet to generate a new block data body;

[0018] The proof-of-work algorithm is executed on the new block data body to calculate a random number that meets the target difficulty, and the random number is added to the new block data body to form a complete data block;

[0019] Generate an unalterable data block with coordinated universal time data and a timestamp field based on the complete data block.

[0020] In a preferred embodiment, a cross-chain traceability identifier is created for each immutable data block, including:

[0021] Extract the product batch number and emission stage code contained in the tamper-proof data block;

[0022] Concatenate the product batch number and the emission stage code in a preset order to form an original identification string;

[0023] Perform a SHA-256 hash operation on the original identification string to generate a 256-bit binary digest data;

[0024] Convert the binary summary data into a sixty-four-bit hexadecimal encoding string as a base identifier;

[0025] Append the Coordinated Universal Time timestamp field carried by the unalterable data block to the end of the basic identifier;

[0026] The appended string is combined with the current blockchain network identification code to generate the final cross-chain traceability identifier, which includes the product batch number and emission stage mark.

[0027] In a preferred embodiment, when the cross-chain gateway captures a data call request, it performs Fourier transform on the data related to the emission phase and calculates the cross-spectral density coherence, including:

[0028] When the cross-chain gateway captures a data call request, it performs Fourier transform on the data involved in the emission phase in the data call request, and calculates the cross-spectral density coherence based on the Fourier transform results.

[0029] In a preferred embodiment, if the cross-spectral density coherence is lower than a preset coherence threshold, the emission stage mark and the product batch number are matched through a cross-chain verification protocol and a determination is made as to whether the cross-chain verification is successful, including:

[0030] Query the cross-chain traceability identifier associated with the hash value of the current immutable data block through the cross-chain index database;

[0031] Reversely parse the original metadata including the product batch number and emission stage code based on the cross-chain traceability identifier;

[0032] Perform a full-field comparison of the product batch number obtained by reverse parsing with the product batch number included in the data call request;

[0033] Perform character-level matching between the emission stage code obtained through reverse parsing and the emission stage tag included in the data call request;

[0034] Cross-chain verification is considered successful only when all fields of the product batch number are matched and the character-level match of the emission stage code is successful.

[0035] In a preferred embodiment, when cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number, including:

[0036] Based on the discharge stage mark, the temperature, pressure and flow sensor data are synchronously acquired, and the residual sequence is generated through the fluid mechanics energy conservation equation;

[0037] Generate confidence parameters based on the standard deviation of the residual sequence and the adaptive threshold;

[0038] If the confidence parameter is lower than the preset confidence threshold, the carbon emission factor data packet marked with the corresponding emission stage will be discarded;

[0039] Extracting the peak sequence of mass spectrometry detection substances from the retained emission phase markers to construct a reaction topology map and extracting the feature vector of the reaction topology map;

[0040] Calculate the cosine similarity between the feature vectors of the pairwise reaction topology graphs of all non-discarded emission stage markers under the same product batch number to form a similarity matrix between emission stage markers;

[0041] Based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check has passed.

[0042] In a preferred embodiment, whether the repeatability check passes is determined based on the similarity matrix and the carbon emission intensity difference, specifically:

[0043] When the cosine similarity values ​​of all emission stage marks in the similarity matrix are not lower than the preset similarity threshold, and the absolute values ​​of the carbon emission intensity differences in the carbon emission factor data packages of all emission stage marks are lower than the preset emission intensity difference threshold, the repeatability check of the product batch number corresponding to the mark passes;

[0044] When the cosine similarity value of two emission stage marks is 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 stage marks is lower than the preset emission intensity difference threshold, a hidden anomaly alarm is triggered.

[0045] In a preferred embodiment, the carbon emission factor data packages that have passed the repetitive verification are integrated by product batch number to generate a global carbon footprint traceability record and store it in a cross-chain shared ledger, including:

[0046] Aggregate the carbon emission factor data packages that have passed the repeatability check by product batch number to form a global carbon footprint traceability record corresponding to the product batch number;

[0047] The global carbon footprint traceability records are synchronously stored in the cross-chain shared ledger, where the global carbon footprint traceability records stored in the cross-chain shared ledger are linked to the on-chain data traceability through the product batch number.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] By building a cross-chain collaborative carbon emissions data management architecture, the problem of overlapping accounting boundaries caused by multi-chain data silos is effectively overcome. Each carbon emissions data block stored on the chain is assigned a cross-chain identifier containing the product batch number and emission stage mark, providing a unified index basis for subsequent cross-system data association. When a cross-chain data call request occurs, the system does not simply transmit the data, but instead uses a coherence detection module to perform spectral analysis (Fourier transform and cross-spectral density coherence calculation) on the data related to the emission stage. It can intelligently identify whether data submitted on different chains for the same product batch but different emission stages have inherent correlation (that is, whether they belong to the same product life cycle flow). If insufficient coherence is detected (below the preset threshold), the cross-chain verification protocol is triggered, and the mapping relationship between the product batch number and the emission stage mark is used for precise matching verification. Only data that passes this verification will enter the subsequent batch verification link, eliminating the isolated accounting and repeated calculation of carbon emissions of the same product on different enterprise chains, and ensuring the clarity and uniqueness of the carbon footprint accounting boundaries.

[0050] By establishing association links through cross-chain identifiers, and using intelligent judgment of signal coherence to trigger cross-chain verification, and after verification, repeatedly verifying and integrating data from different emission stages of the same product batch, it ensures that the final 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 the inflated data caused by system fragmentation, and providing reliable technical support for cross-supply chain carbon management collaboration. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 This is a structural diagram of the blockchain-based carbon emission factor data traceability management system of the present invention. DETAILED DESCRIPTION

[0052] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0053] Example: Figure 1 The structural diagram of the blockchain-based carbon emission factor data traceability management system of the present invention is given. The blockchain-based carbon emission factor data traceability management system includes:

[0054] Data collection module: obtains carbon emission factor data packages submitted by various supply chain participants;

[0055] Blockchain Evidence Module: Writes the carbon emission factor data packet into the blockchain node through a distributed consensus mechanism, generating an unalterable data block with a timestamp;

[0056] Cross-chain identification module: Creates a cross-chain traceability identifier for each tamper-proof data block. The cross-chain traceability identifier includes the product batch number and emission stage mark;

[0057] Coherence detection module: When the cross-chain gateway captures a data call request, it performs Fourier transform on the data related to the emission stage and calculates the cross-spectral density coherence. If the cross-spectral density coherence is lower than the preset coherence threshold, the emission stage tag and product batch number are matched through the cross-chain verification protocol to determine whether the cross-chain verification has passed;

[0058] Batch Verification Module: When cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number;

[0059] Traceability integration module: Integrate the carbon emission factor data packages that have passed repeatable verification according to the product batch number, generate a global carbon footprint traceability record and store it in a cross-chain shared ledger.

[0060] The technical connection relationship and implementation logic of the six modules are as follows:

[0061] After the data acquisition module obtains the carbon emission factor data package submitted by the supply chain participants, it transmits the original data package to the block evidence module; the block evidence module writes the data package into the blockchain node through the distributed consensus mechanism, generates an unalterable 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 (including product batch number and emission stage mark) for each data block, and binds the identifier to the corresponding data block for storage; when the cross-chain gateway captures the data call request, the coherent detection module extracts the data related to the emission stage in the request and performs Fourier transform. The cross-spectral density coherence is converted and calculated: 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 determines 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 (for example, confidence analysis based on 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.

[0062] Obtain the carbon emission factor data package submitted by each supply chain participant. The specific implementation is as follows:

[0063] To obtain carbon emission factor data packages submitted by various supply chain participants, a data collection interface deployed on a cloud server first receives the data packages uploaded by each supply chain participant via an encrypted transmission channel. These data packages contain six structured data fields: emission phase code, product batch number, direct emission data, indirect emission data, timestamp, and unit of measure. The data collection interface performs an integrity check on the uploaded data package, requiring that all six fields must be present and non-null. If any fields are missing or have null values, an error handling process is triggered, and a notification message containing a list of missing fields is returned to the participant.

[0064] The emission stage code is selected and input by the participant based on the life cycle stage of the product's actual production process. This 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 further divided into several subcategories. For example, if the participant is an automotive parts manufacturer, the emission stage code corresponding to its metal stamping process is defined as the metal forming processing subcategory under the manufacturing stage. This code is selected and input through a standardized option menu provided by the data collection interface. The option menu content is dynamically loaded based on the production type registered by the participant.

[0065] Product batch numbers are generated using a hierarchical coding scheme. The coding structure consists of three fixed-length components: an 8-digit unique manufacturer identifier, a 4-digit product type identifier, and a 6-digit production batch serial number. These three components are combined to form an 18-character fixed-length string. This number is automatically generated by the participating party's internal production management system when the product line is started. For example, when the production management system detects that a brake pad product has entered the electroplating process, it generates the number "690123450000123456" and binds it to all process records for that batch. Upon receiving a data packet, the data acquisition interface verifies whether a valid production record exists for the batch number by querying the distributed database. If verification fails, the data packet is rejected from storage.

[0066] Direct emissions data records greenhouse gas emissions from the combustion of fossil fuels during the production process. This data is generated by using a mass flow meter installed on the fuel lines of production equipment to collect fuel consumption during the production cycle of a specific batch of products. Fuel consumption is recorded in real time in cubic meters. This fuel consumption is then multiplied by the emission conversion factor corresponding to the fuel type to obtain the CO2 equivalent value. The emission conversion factor is derived from a publicly available database regularly published by official agencies. For example, the emission conversion factor for natural gas is 2.18 kilograms of CO2 equivalent per cubic meter. A calculation unit built into the collection interface automatically performs the multiplication of the consumption by the factor, retaining two decimal places of precision.

[0067] Indirect emissions data records greenhouse gas emissions associated with purchased energy, specifically divided into electricity and heat. Electricity emissions are obtained by reading data from smart meters installed on the production line's main circuit. Smart meters record electricity consumption (in kilowatt-hours) during the production period of a specific batch of products, multiplied by the emissions conversion factor currently applicable in the electricity supply region (e.g., 0.581 kg CO2 equivalent per kilowatt-hour). Heat emissions are obtained by multiplying the readings from flow meters installed on steam pipelines (in gigajoules) by the emissions conversion factor provided by the heat supplier (e.g., 85 kg CO2 equivalent per gigajoule of steam). All meter data is transmitted in real time to the data collection interface via an IoT gateway.

[0068] The timestamp marks the time when the carbon emission factor data packet is verified in the system. This timestamp is automatically generated by the data acquisition interface's backend service after passing integrity verification. The time data includes year, month, day, hour, minute, second, and millisecond information, and the time zone is marked as Coordinated Universal Time. Time data is obtained by calling the operating system kernel time service. The operating system kernel time is synchronized with the timing server through a dedicated time synchronization protocol, and the time synchronization error is controlled within a range of plus or minus 50 milliseconds. For example, if 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.

[0069] The Units field specifies the standard unit of measurement for emissions data. This field is a predefined option field, and both direct and indirect emissions data use kilograms of CO2 equivalent as the standard unit of measurement. When participants' raw data uses other units of measurement, the data collection interface performs a unit standardization conversion: if the raw data uses tons, it is multiplied by 1000 to convert to kilograms; if it uses grams, it is divided by 1000 to convert to kilograms. A detailed log of the conversion operation is recorded, including the original value, original unit, conversion factor, and conversion result. For example, the raw data of 0.85 tons is converted to 850 kilograms of CO2 equivalent.

[0070] The technical linkage of various fields in this implementation is achieved through the following mechanisms: the product batch number serves as a core index to link all field data; the emission phase code and timestamp are combined to generate a unique data packet identifier; and direct and indirect emission data are superimposed within the same measurement unit system. Once all processed field data is encapsulated into a data object according to a predefined structure, it is transmitted to the next processing node via a message queue.

[0071] The carbon emission factor data package is written into the blockchain node through a distributed consensus mechanism to generate an unalterable data block with a timestamp. The specific implementation is as follows:

[0072] When writing a verified carbon emission factor data package to the blockchain, a distributed consensus verification is first performed by no fewer than three validating nodes in the blockchain network. This verification process specifically involves checking whether the carbon emission factor data package contains a complete combination of six fields: the emission phase code, product batch number, direct emissions data, indirect emissions data, timestamp, and unit of measurement. The emission phase code is an eight-digit alphanumeric string (e.g., "MANU_001"). The product batch number is encoded using a 13-digit number format (e.g., 2024061500001). Direct emissions data is expressed in kilograms of CO2 equivalent per product unit, while indirect emissions data is expressed in megajoules per product unit. The timestamp field stores millisecond-level time data in Coordinated Universal Time (e.g., 2024-06-15T08:30:45.123Z). The unit of measurement is fixed to a predefined enumeration value, such as "per product" or "per ton of raw materials." Data type verification is performed synchronously during field validation: the emission stage code must match the record in the pre-registered factory production stage identification library, the product batch number must comply with the coding rule of year, month, day plus a six-digit serial number (for example, 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 value range must be limited to between 0.001 and 1000000.

[0073] When more than two-thirds of validating nodes confirm that all fields are complete and conform to data structure requirements (this percentage is set based on the Byzantine Fault Tolerance algorithm's total node count constraint of 3f+1≤n, where f is the maximum number of fault-tolerant nodes and n is the total number of nodes. This percentage can be configured to any value between 50% and 75%), the system automatically extracts the 256-bit hash value of the latest block from the blockchain ledger. This hash value is generated using the SHA-256 algorithm and is represented as a 64-digit hexadecimal string (e.g., 5a3b9f...e82c). Immediately after extraction, the latest block hash value is binary concatenated with the carbon emission factor data packet to form a new block data body for the unfinished proof of work. This data structure consists of two consecutive storage segments: the first 64 bytes store the latest block hash value, and the subsequent storage segment contains, in field order, the emission phase 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 unit of measure (12-byte string).

[0074] When executing the proof-of-work algorithm on a new block's data, an iterative calculation method is used to find a random number that meets the target difficulty. The specific process is as follows: A four-byte random number space is reserved in the header of the new block's data, and the random number is initialized to 0. The following steps are then performed in a loop: the current random number is written into the reserved space, the SHA-256 hash of the entire data is calculated, and the number of leading zero bits in the binary representation of the hash value is checked to see if it meets the current network difficulty target value N (N is an integer). If not, the random number is incremented by 1 and the calculation is repeated. The calculation stops when the number of leading zero bits meets N, and the valid random number value is recorded. The difficulty target N is dynamically adjusted based on the average generation time of the blockchain's last ten blocks: assuming the actual average block time is T seconds and the target interval is 600 seconds, the new difficulty N_new = N_old × (T / 600). The adjusted N value is limited to a range of 16 to 32 (i.e., the number of leading zero bits must be 16-32 bits). The random number search range is limited to 0 to 4294967295 (the maximum value of a four-byte unsigned integer). If no solution is found after traversing the entire range, the difficulty target value N is temporarily reduced by 1 and the search is repeated.

[0075] Once a matching random number is found, it is written into the reserved space to form a complete data block. The data block size is fixed at: four bytes of random number + sixty-four bytes of parent hash value + sixty-five bytes of carbon emission factor packet field data (8+13+4+4+24+12=65 bytes). When generating the final, unalterable data block from this complete data block, the system automatically appends a creation timestamp in Coordinated Universal Time (UTC). This timestamp is derived from the weighted average of at least three timing servers (for example, using the NTP protocol to synchronize from time.windows.com, ntp.aliyun.com, and pool.ntp.org, with weights assigned based on the historical clock deviation of each server, with the weight decreasing by 10% for every millisecond increase in deviation). The timestamp is stored in an eight-byte field at the end of the data block and is written in the format YYYYMMDDhhmmssmmm (for example, 20240615083045123).

[0076] The immutability of this data block is achieved through a two-pronged mechanism: first, the hash value of the latest block contained within the block forms a forward pointer to the cryptographic digest of the previous block in the blockchain. Second, when subsequent blocks are generated, their headers will contain the SHA-256 hash value of the current block, forming a chain of backward pointers. Modifying any block's data will cause its hash value to change, thereby breaking the chain. For example, if the product batch number field is tampered with (for example, changing 2024061500001 to 2024061500002), the recalculated data block hash value will change, invalidating the original proof-of-work random number (the number of leading zeros in the new hash value will not meet the difficulty target) and will not match the original hash value stored in subsequent blocks.

[0077] During ongoing maintenance after data is written, each validator node performs a chain integrity check every hour. Starting from the current block and tracing back to the genesis block, each block performs the following operations: reading the parent block hash value H1 stored in the current block, calculating the actual hash value H2 of the previous block, and triggering the split resolution mechanism when H1 and H2 are inconsistent. The specific process of split resolution is: broadcasting a fork alert to the entire network, counting the block heights held by all nodes, and selecting the valid chain with the largest height as the main chain (a valid chain is defined as a chain that has continuously passed proof-of-work verification). The block generation rate is controlled to produce a new block every ten minutes, which is achieved by dynamically adjusting the target difficulty value of the proof of work. The difficulty coefficient adjustment is performed every Sunday at 0:00: Assume that the actual average block generation time last week is T seconds (calculated based on the block timestamp), and the baseline difficulty last week is D_old, then the new difficulty D_new = D_old × (T / 600), where D_new ranges from 65536 to 4294967296 (corresponding to 2 to the power of 16 to 2 to the power of 32). If T < 300 seconds, 300 seconds is taken, and if T > 1200 seconds, 1200 seconds is taken as the calculated value.

[0078] Create a cross-chain traceability identifier for each immutable data block. The specific implementation is as follows:

[0079] When generating a cross-chain traceability identifier, the product batch number and emission phase code are first extracted from a fixed storage location in the immutable data block. The product batch number is located between bytes 13 and 25 of the data block, and the emission phase code is located between bytes 6 and 13. The extraction operation automatically verifies the validity of the fields: the product batch number must be 13 consecutive numeric characters, such as 2024061500001; the emission phase code must consist of 8 letters or numbers, such as MANU_001. If non-numeric characters or insufficient length are detected, the process is terminated and an error report is generated.

[0080] The product batch number and the emission phase code are concatenated in a predefined order to form the original identification string. This predefined order is fixed: the emission phase code comes first, followed by the product batch number, without a separator. During the concatenation process, character set conversion is performed: lowercase letters in the emission phase code are converted to uppercase, for example, manu_001 is converted to MANU_001; the product batch number remains in its original numeric form. The resulting original identification string is 21 characters long and is stored as a UTF-8 encoded byte array. 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, 49].

[0081] When performing a SHA-256 hash operation on the original identifier string, the input data is the aforementioned byte array, and the hash calculation buffer is initialized to 512 bits. The operation process consists of 64 iterative processes, each of which involves reading a 512-bit block from the input data, performing a cryptographic transformation on the block using a combination of a bit selection function, modular addition, and circular shift operations, updating the intermediate hash value state register, and finally outputting a 256-bit binary digest data. This operation follows the algorithm flow defined by the Internet Engineering Task Force RFC 6234 standard. Identical inputs always produce identical outputs. For example, the input MANU_0012024061500001 always outputs a fixed binary sequence. A timeout protection mechanism is implemented during the operation: if the calculation time exceeds 1000 milliseconds, it is forcibly terminated and a backup computing unit is activated.

[0082] When converting the 256-bit binary digest data to a 64-bit hexadecimal string, the data is split into groups of four binary digits each. Each group is mapped to a hexadecimal character in sequence. The mapping rule is: 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. The conversion process performs a parity check: every byte consisting of two hexadecimal characters must contain an even number of 1s in binary form. If the check fails, the hash operation is re-executed.

[0083] The Coordinated Universal Time timestamp field carried by the immutable data block is appended to the end of the base identifier. The timestamp field is located in the last 8 bytes of the data block and is stored as a consecutive numeric combination of year, month, day, hour, minute, second, and millisecond. The append operation uses a delimiter concatenation strategy: an underscore character is inserted between the base identifier and the timestamp, for example, 5A3B9F...E82C_20240615083045123. The timestamp is validated before appending: year values ​​are limited to the range 2000 to 2100, for example, 2024; month values ​​are limited to the range 1 to 12, for example, 6; and day values ​​are dynamically limited based on the month, for example, June is limited to the range 1 to 30. If the value is out of range, it is replaced with the latest synchronization time of the blockchain network.

[0084] In the step of generating the final cross-chain traceability identifier, the timestamp-appended string is combined with the current blockchain network identifier according to pre-set rules. The blockchain network identifier consists of three fixed-length fields in sequence: the first two digits are the two-digit country code defined by the International Organization for Standardization (ISO) 3166-1 standard; the middle nine digits are the enterprise registration code, taken from the 9th to 17th digits of the unified social credit code registered in the National Enterprise Credit Information Publicity System; and the last three digits are the chain type code, a combination of uppercase letters and numbers indicating the blockchain network type. During the combination, the blockchain network identifier is placed at the beginning of the appended string using a colon delimiter, for example, forming the structure CN123456789BC:5A3B9F...E82C_20240615083045123. This final cross-chain traceability identifier implicitly includes the product batch number and emission stage marker through the base identifier. This is because the base identifier is a unique representation generated by hashing the product batch number and emission stage code, and its hexadecimal encoded string is irreversibly mathematically linked to the original product batch number and emission stage marker. The total length of the generated identifier is fixed at 85 characters. When written into the cross-chain index database, two pairs of key-value relationships are established to achieve bidirectional mapping: the first pair uses the hash value of the tamper-proof data block 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 emission stage code as the value, ensuring that the product batch number and emission stage mark can be reversely parsed through the identifier.

[0085] During the character conversion phase, the hexadecimal mapping process is implemented using a predefined conversion table containing 16 entries, each of which stores a mapping between a 4-bit binary pattern and a corresponding hexadecimal character. When verifying timestamp validity, the date range is limited based on the Gregorian calendar's leap year rules: when the year is divisible by 4 but not by 100, or by 400, the upper limit for February dates is 29 days; otherwise, it is 28 days. The enterprise registration code in the blockchain network identifier is derived from the unified social credit code, which is uniformly assigned by the State Administration for Market Regulation. It consists of five components: the registration management department code, the organization category code, the registration management authority administrative region code, the entity identification code, and a checksum. Bits 9 to 17 are the entity identification code, which serves as the unique enterprise identifier. The cross-chain index database utilizes a distributed key-value storage architecture, enabling forward queries by storing immutable data block hashes as keys and cross-chain traceability identifiers as values. It also maintains an inverted index using the cross-chain traceability identifier as the key and the block hash as the value for reverse queries.

[0086] When the cross-chain gateway captures the data call request, it performs Fourier transform on the data involved in the emission phase and calculates the cross-spectral density coherence. The specific implementation is as follows:

[0087] When the cross-chain gateway captures a data call request, it performs a Fourier transform on the emission-phase data in the request and calculates the cross-spectral density coherence based on the Fourier transform results. Emission-phase data refers to a collection of time-series monitoring data related to carbon emissions during the product production process, extracted by the cross-chain gateway from the data call request. Specifically, this data includes instantaneous energy consumption of production equipment (unit: kilowatt-hours), raw material decomposition rate (unit: kilograms / minute), and other time-series data generated at a fixed sampling frequency. The implementation process of Fourier transform includes four core steps: first, the emission stage data is discretized into equally spaced sampling points according to the time series. The sampling interval is set according to the monitoring frequency of the data generating equipment. For example, when the industrial sensor adopts a 10 Hz sampling rate, 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, the fast Fourier transform algorithm is applied 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 component, and the imaginary part represents the phase characteristics; third, the real part amplitude value of the target frequency band is extracted from the complex spectrum to form the first spectrum vector. The target frequency band range is set to 0.5 Hz to 5 Hz. This range is determined according to the typical vibration frequency of industrial equipment defined by the international standard ISO 10816; fourth, the imaginary part amplitude value of the same frequency band is extracted to form the second spectrum vector. The cross-spectral density coherence calculation process includes: calculating the cross-spectral matrix of the first spectral vector and the second spectral vector, the diagonal elements of which are the auto-power spectral densities of each spectral vector, and the off-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 spectral vector and the auto-power spectral density of the second spectral vector". The calculation result is a dimensionless value between 0 and 1. The closer the value is to 1, the stronger the linear correlation between the spectral components.

[0088] If the cross-spectral density coherence is lower than the preset coherence threshold, the emission stage mark and product batch number are matched through the cross-chain verification protocol to 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:

[0089] If the calculated cross-spectral density coherence falls below a preset coherence threshold, the cross-chain verification protocol is triggered to match the emission phase tag with the product batch number. The preset coherence threshold is set by collecting 1,000 sets of emission phase data samples from a historically normal production cycle and calculating the cross-spectral density coherence value for each set. The arithmetic mean and standard deviation of the coherence values ​​for all samples are then calculated. The threshold is calculated by subtracting three standard deviations from the mean. For example, if 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 adheres to the statistical 3σ principle, ensuring coverage of 99.7% of the normally distributed data range. When the real-time calculated coherence falls below 0.86, the data is deemed to be abnormally perturbed or potentially tampered with. The triggering of the cross-chain verification protocol strictly relies on this threshold comparison to avoid unnecessary consumption of system resources.

[0090] The matching process in the cross-chain verification protocol first queries the cross-chain index database for the cross-chain traceability identifier associated with the current immutable data block hash value. The immutable data block hash value refers to the unique cryptographic digest value of a data block confirmed by the consensus mechanism on the blockchain. It uses the SHA-3 algorithm to generate a fixed-length 256-bit binary string. 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 is encoded as a 32-byte string encoded in Base58. This mapping relationship is synchronously written to 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 currently 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 between hash values ​​and identifiers; returning the cross-chain traceability identifier that exactly matches the input key; and terminating the verification process with an error code 404 if no match is found.

[0091] The original metadata, including the product batch number and emission phase code, is reverse parsed based on 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 emission phase code using the HMAC-SHA256 algorithm. The reverse parsing process requires three steps: First, the identifier is input into the key management decryption module and decrypted using the same AES-256 symmetric key used during generation, with a fixed key length of 256 bits. Second, the decrypted intermediate string is split into two parts using a hyphen separator. For example, the string "P12345-E2" is split into "P12345" and "E2." Third, the first part of the string is UTF-8 decoded to restore it to the product batch number, and the second part to restore it to the emission phase code. The original metadata structure is a JSON object with two fixed fields: "product_batch_id" stores the product batch number, and "emission_phase_code" stores the emission phase code, for example, {"product_batch_id": "P12345", "emission_phase_code": "E2"}.

[0092] A full-field comparison is performed on the product batch number obtained through reverse parsing against the product batch number included in the data call request. The product batch number in the data call request is passed as a Uniform Resource Locator parameter named "batch_id." URL decoding and special character filtering are performed during extraction. For example, the request path " / api / data?batch_id=P%31%32%33%34%35" decodes to "P12345." The full-field comparison is implemented as follows: First, the byte lengths of the two product batch number strings are compared; if the lengths are different, a mismatch is returned. Second, the ASCII code values ​​of the two strings are compared byte by byte, for example, comparing the binary encoding of each character in "P12345" with "P12345." Third, a match is considered only when the ASCII code values ​​of all characters are identical, disabling fuzzy matching.

[0093] The emission phase code obtained through reverse parsing is matched against the emission phase marker included in the data call request at the character level. The emission phase marker is transmitted in the data call request as a Hypertext Transfer Protocol request header field named "X-Emission-Phase". During extraction, the field value is verified to conform to the predefined regular expression "^[AZ][0-9]{1,2}$". For example, "E2" is a legal value, while "A12a" is not. Character-level matching involves: first, converting the emission phase code and marker into character arrays of equal length. For example, the code "E2" is converted into the array ['E','2']. Second, comparing the Unicode code point values ​​of each character in the array index order. For example, comparing 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 strictly case-sensitive. For example, the code "E2" and the marker "e2" are considered mismatched due to the code point difference.

[0094] Cross-chain verification is considered successful only if all fields of the product batch number match and the emission phase code matches at the character level. This dual matching condition forms a logical AND relationship; failure of either condition triggers an error handling mechanism: if the product batch number matches but the emission phase code fails to match (for example, the request tag is "E3" and the parsed code is "E2"), error code 501 is returned; if the emission phase code matches but the product batch number fails (for example, the request number is "P12346" and the parsed number is "P12345"), error code 502 is returned; if both conditions fail, error code 503 is returned. A successful verification result triggers two actions: authorizing the cross-chain gateway to access the requested emission data and submitting a verification success transaction to the blockchain network. This transaction contains the data call request hash, a verification timestamp, and a matching result field. The timestamp format is ISO 8601 standard UTC time (for example, "2023-08-15T14:30:00Z").

[0095] When cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number. The specific implementation is as follows:

[0096] First, based on the discharge phase marker, temperature, pressure, and flow sensor data are synchronously acquired. Temperature sensor data is collected in real time at a sampling frequency of once per second by a K-type thermocouple installed on the discharge pipe, covering a range of -50°C to 300°C with an accuracy of ±0.5°C. Pressure sensor data is collected at a frequency of 10 Hz by a piezoresistive sensor, covering a range of 0-10 MPa with an error of no more than 0.1% of full scale. Flow sensor data is acquired at a frequency of five times per second by a turbine flowmeter, covering a range of 0.5 to 50 m³ / min with a linear error of less than 0.2%. After time-aligning the data points from the three sensors at the same timestamp, the residuals are calculated using the fluid dynamics energy conservation equation. The calculation process is as follows: For each sensor data point, a theoretical energy conservation model is established based on the Bernoulli equation. The absolute value of the deviation between the measured flow rate and the model prediction is used as the residual at that time point. 600 sets of data at each time point within 60 seconds are continuously processed to form a residual sequence with 600 elements.

[0097] Next, a confidence parameter is generated based on the standard deviation of the residual sequence and an adaptive threshold. The standard deviation σ of the residual sequence is calculated as follows: the square root of the variance of all elements in the residual sequence, using an unbiased estimate (the denominator is the sequence length minus 1). The adaptive threshold is generated through a dynamic learning mechanism: the moving average μ and moving standard deviation δ of the standard deviation of the most recent 30 residual sequences from the same production equipment under normal operating conditions are calculated, and the adaptive threshold is set 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%. When the ratio is greater than or equal to 1, the confidence parameter is reset 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%.

[0098] If the confidence parameter falls below a preset confidence threshold, the carbon emission factor data packet associated with the corresponding emission phase marker is discarded. The preset confidence threshold is set during system initialization based on the device type: 85% for chemical reaction equipment and 90% for combustion equipment. This threshold is based on the differences in sensor measurement error tolerance across different device types. The discard operation specifically includes writing a "low confidence" status code to the metadata associated with the emission phase marker and moving the corresponding carbon emission factor data packet to an isolated storage area. Subsequent processing will skip the discarded data packet.

[0099] The reaction topology map was constructed by extracting the mass spectrometry peak sequence from the retained emission phase markers. The mass spectrometry peak sequence was acquired by continuously scanning the quadrupole mass spectrometer during the emission phase: scanning in 0.1 atomic mass unit steps over the m / z range of 20-400, recording the ion current intensity value for each mass channel, and forming a substance peak sequence containing 3800 intensity values. The reaction topology map was constructed by first identifying all peaks in the substance peak sequence whose intensities exceeded three standard deviations of the baseline noise, and assigning the substance molecular formula corresponding to each peak as a node. Edges were then established based on the chemical reaction potential between the substances. If the reaction Gibbs free energy change ΔG between the two substances was less than 0 and the catalytic conditions were known, a directed edge was established between the corresponding nodes. This ultimately generated a directed graph structure with substance molecular formulas as nodes and reaction pathways as edges.

[0100] A feature vector is extracted based on the reaction topology graph. The feature vector is fixed at 256 dimensions and generated according to the following rules: the first 128 dimensions are node feature codes. The molecular formulas corresponding to all nodes in the topology graph are hashed, and the first 32 bits of the MD5 hash of the molecular formula SMILES string are converted into a 128-dimensional binary vector. The second 128 dimensions are edge feature codes. The distribution of reaction types (oxidation, reduction, cleavage, and polymerization) is calculated for all reaction edges. The counts of the four reaction types are normalized to probabilities and then converted to a 128-dimensional feature vector using a Fourier transform. Finally, the first and second feature vectors are concatenated to form a 256-dimensional feature vector for the reaction topology graph.

[0101] The cosine similarity between the feature vectors of the reaction topologies of all undiscarded emission stage markers for the same product batch number is calculated. The cosine similarity is calculated using the standard vector angle formula: for two 256-dimensional feature vectors A and B, the similarity is equal to the dot product of A and B divided by the product of the modulus of A and the modulus of B. For each product batch number with N retained emission stage markers, an N×N symmetric similarity matrix is ​​generated. The diagonal elements of the matrix are fixed to 1 (self-similarity for identical markers), and the off-diagonal elements store the similarity values ​​between each marker.

[0102] When the cosine similarity values ​​of all emission phase markers in the similarity matrix are greater than or equal to the preset similarity threshold, and the absolute values ​​of the carbon emission intensity differences in the carbon emission factor data packages for all emission phase markers are less than the preset emission intensity difference threshold, the repeatability verification for the product batch number is marked as passed. The preset similarity threshold is set to 0.92, which was determined based on a mass spectrometry repeatability experiment: 10 replicates of the same emission sample were performed, and the minimum similarity between the reaction topology feature vectors was calculated as the threshold benchmark. The carbon emission intensity difference refers to the difference in carbon emissions per unit product (kgCO2 / ton of product) in the different emission phase marker data packages. The preset emission intensity difference threshold is set to 5% of the baseline emission intensity (the baseline value is the historical average emission intensity for the product model). After the verification passes, the "Repeatability Verification Passed" status flag is written to the product batch number metadata.

[0103] A hidden anomaly alarm is triggered when the cosine similarity value of two emission phase markers is less than the preset similarity threshold, and the absolute value of the carbon emission intensity difference in the carbon emission factor data packets of the two emission phase markers is less than the preset emission intensity difference threshold. This contradictory state indicates that although the total carbon emissions data are similar (the emission intensity difference is small), there are significant differences in the material reaction pathways (low similarity), indicating possible data tampering or hidden equipment failure. After the alarm is triggered, three actions are performed: freeze the write permission of all carbon emission factor data packets for the batch; initiate the cross-chain data traceability verification process; and send an alarm code containing the conflict marker ID to the supervision node (code format: CAE_Conflict Marker ID1_Conflict Marker ID2).

[0104] The carbon emission factor data packages that have passed the repeatable verification are integrated according to the product batch number to generate a global carbon footprint traceability record and store it in the cross-chain shared ledger. The specific implementation is as follows:

[0105] The operation of aggregating 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 packet output by the repeatability check step, use the product batch number field as the unique index key, and classify 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 field in each data packet, and perform weighted average calculation based on the confidence weight obtained by each data packet in the repeatability check step to generate an integrated carbon emission factor value corresponding to the product batch number; the confidence weight is dynamically set based on the similarity matrix comparison result in the repeatability check step, and data packets with cosine similarity in the similarity matrix higher than a preset threshold are assigned a higher confidence weight. For example, when the similarity value of a data packet with other data packets in the same batch exceeds 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 final integrated carbon emission factor value is bound to the product batch number and serves as the core data field of the global carbon footprint traceability record.

[0106] The specific implementation of forming a global carbon footprint traceability record corresponding to the product batch number is as follows: after completing the aggregation of carbon emission factor data for the same product batch number, the basic product information corresponding to the product batch number is supplemented. The basic product information includes the product raw material source code, the production process line code and the logistics transfer node code. The raw material source code is generated by the upstream enterprise in the supply chain through 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 record of the logistics management system; the integrated carbon emission factor value and the product basic information are encapsulated according to the predefined data structure. Each field in the data structure contains 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 encapsulated global carbon footprint traceability record generates a unique data fingerprint. The data fingerprint is obtained by operating the binary sequence of all fields in the record using a hash algorithm for subsequent data integrity verification.

[0107] The specific implementation of synchronously storing the global carbon footprint traceability record in the cross-chain shared ledger is as follows: calling the cross-chain shared ledger adapter interface to convert the global carbon footprint traceability record into the 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 according to the structured data format required by the ledger; the transaction data is broadcast to the cross-chain shared ledger network after being signed by the node, 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 complies with the coding specification; after the transaction is verified, the global carbon footprint traceability record is written into a new block of the cross-chain shared ledger, and an on-chain storage certificate containing the block height, timestamp and transaction hash value is generated at the same time.

[0108] The specific implementation of on-chain data traceability is as follows: when the carbon footprint data of a specific product batch number needs to be queried, a query request containing the product batch number is submitted to the cross-chain shared ledger, and the ledger node locates the corresponding transaction in the on-chain index based on the product batch number; by parsing the core data fields in the transaction data, the original global carbon footprint traceability record is restored, and the integrity of the record is verified based on the data fingerprint in the transaction metadata field; during the traceability process, the product batch number can be used to link to the historical records of the batch of products in various links of the supply chain, such as retrieving the raw material production records of upstream suppliers through the raw material source code, and tracking the carbon emission data in the transportation stage through the logistics transfer node code. All related data are ensured to be tamper-proof through on-chain storage credentials.

[0109] The calculations involved in the embodiments are all dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to actual conditions.

[0110] It should be noted that the present invention can be deployed on the device itself to implement embedded applications, and can also be run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0111] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination. 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 comprises one or more computer instructions or computer programs. When loaded or executed on a computer, the processes or functions described in the embodiments of this application are fully or partially generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission (e.g., infrared, wireless, microwave, etc.); wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission methods include infrared, microwave, etc. The computer-readable storage medium can be any available medium accessible by a computer, or a data storage device such as a server or data center that contains a collection of one or more available media. The available medium can be magnetic media (e.g., floppy disk, hard disk, tape), optical media (e.g., DVD), or semiconductor media. The semiconductor medium may be a solid state drive.

[0112] Those skilled in the art will 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 aforementioned method embodiments and will not be repeated here.

[0113] In the several embodiments provided in this 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 schematic. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

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

[0115] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0116] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the 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 enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0117] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0118] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. The blockchain-based carbon emission factor data traceability management system is characterized by: include: Data collection module: obtains carbon emission factor data packages submitted by various supply chain participants; Blockchain Evidence Module: Writes the carbon emission factor data packet into the blockchain node through a distributed consensus mechanism, generating an unalterable data block with a timestamp; Cross-chain identification module: Creates a cross-chain traceability identifier for each tamper-proof data block. The cross-chain traceability identifier includes the product batch number and emission stage mark; Coherence detection module: When the cross-chain gateway captures a data call request, it performs Fourier transform on the data related to the emission stage and calculates the cross-spectral density coherence. If the cross-spectral density coherence is lower than the preset coherence threshold, the emission stage tag and product batch number are matched through the cross-chain verification protocol to determine whether the cross-chain verification has passed; Batch Verification Module: When cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number; Traceability integration module: Integrate the carbon emission factor data packages that have passed repeatable verification according to the product batch number, generate a global carbon footprint traceability record and store it in a cross-chain shared ledger.

2. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: Methods for obtaining carbon emission factor data packages submitted by various supply chain participants include: Receive carbon emission factor data packages uploaded by various supply chain participants. The carbon emission factor data packages contain emission stage code, product batch number, direct emission data, indirect emission data, timestamp and measurement unit.

3. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: The carbon emission factor data package is written into the blockchain node through a distributed consensus mechanism to generate an unalterable data block with a timestamp, including: Verify that the carbon emission factor data package contains the complete field combination; When more than a preset proportion of verification nodes confirm that the fields are complete and conform to the predefined data structure, the hash value of the latest block in the current blockchain is extracted and combined with the carbon emission factor data packet to generate a new block data body; The proof-of-work algorithm is executed on the new block data body to calculate a random number that meets the target difficulty, and the random number is added to the new block data body to form a complete data block; Generate an unalterable data block with coordinated universal time data and a timestamp field based on the complete data block.

4. The blockchain-based carbon emission factor data traceability management system according to claim 1 is 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 tamper-proof 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 summary data into a sixty-four-bit hexadecimal encoding string as a base identifier; Append the Coordinated Universal Time timestamp field carried by the unalterable data block to the end of the basic identifier; The appended string is combined with the current blockchain network identification code to generate the final cross-chain traceability identifier, which includes the product batch number and emission stage mark.

5. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: When the cross-chain gateway captures the data call request, it performs Fourier transform on the data involved in the emission phase and calculates the cross-spectral density coherence, including: When the cross-chain gateway captures a data call request, it performs Fourier transform on the data involved in the emission phase in the data call request, and calculates the cross-spectral density coherence based on the Fourier transform results.

6. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: If the cross-spectral density coherence is lower than the preset coherence threshold, the emission stage mark and product batch number are matched through the cross-chain verification protocol to determine whether the cross-chain verification is passed, including: Query the cross-chain traceability identifier associated with the hash value of the current immutable data block through the cross-chain index database; Reversely parse the original metadata including the product batch number and emission stage code based on the cross-chain traceability identifier; Perform a full-field comparison of the product batch number obtained by reverse parsing with the product batch number included in the data call request; Perform character-level matching between the emission stage code obtained through reverse parsing and the emission stage tag included in the data call request; Cross-chain verification is considered successful only when all fields of the product batch number are matched and the character-level match of the emission stage code is successful.

7. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: When cross-chain verification is passed, repeatability verification is performed on the carbon emission factor data packages marked with different emission stages under the same product batch number, including: Based on the discharge stage mark, the temperature, pressure and flow sensor data are synchronously acquired, and the residual sequence is generated through the fluid mechanics energy conservation equation; Generate confidence parameters based on the standard deviation of the residual sequence and the adaptive threshold; If the confidence parameter is lower than the preset confidence threshold, the carbon emission factor data packet marked with the corresponding emission stage will be discarded; Extracting the peak sequence of mass spectrometry detection substances from the retained emission phase markers to construct a reaction topology map and extracting the feature vector of the reaction topology map; Calculate the cosine similarity between the feature vectors of the pairwise reaction topology graphs of all non-discarded emission stage markers under the same product batch number to form a similarity matrix between emission stage markers; Based on the similarity matrix and the carbon emission intensity difference, determine whether the repeatability check has passed.

8. The blockchain-based carbon emission factor data traceability management system according to claim 7 is characterized in that: Based on the similarity matrix and the carbon emission intensity difference, it is determined whether the repeatability check has passed, specifically: When the cosine similarity values ​​of all emission stage marks in the similarity matrix are not lower than the preset similarity threshold, and the absolute values ​​of the carbon emission intensity differences in the carbon emission factor data packages of all emission stage marks are lower than the preset emission intensity difference threshold, the repeatability check of the product batch number corresponding to the mark passes; When the cosine similarity value of two emission stage marks is 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 stage marks is lower than the preset emission intensity difference threshold, a hidden anomaly alarm is triggered.

9. The blockchain-based carbon emission factor data traceability management system according to claim 1 is characterized in that: The carbon emission factor data packages that have passed the repeatable verification are integrated by 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 packages that have passed the repeatability check by product batch number to form a global carbon footprint traceability record corresponding to the product batch number; The global carbon footprint traceability records are synchronously stored in the cross-chain shared ledger, where the global carbon footprint traceability records stored in the cross-chain shared ledger are linked to the on-chain data traceability through the product batch number.

Images