A blockchain-based carbon emission monitoring system and method

Abstract

The application relates to the technical field of carbon emission monitoring, and discloses a carbon emission monitoring system and method based on a blockchain, the method comprising the following steps: obtaining original power consumption data and encrypting the original power consumption data to obtain initial ciphertext data; performing multiplication and addition operation and decryption on the ciphertext based on conversion rules to obtain carbon emission equivalent numerical values; generating a calculation process proof certificate and extracting a certificate hash value; constructing a storage certificate data packet by combining the certificate hash value and the equivalent numerical values and writing the storage certificate data packet into a blockchain; and according to a verification request, extracting the proof certificate to perform checking and generating an unaltered or abnormally altered judgment result. The method can realize safe and reliable management and control of a carbon emission accounting process and meet the core demand of verifiable calculation process.

Description

Technical Field

[0001] This invention relates to the field of carbon emission monitoring technology, and in particular to a blockchain-based carbon emission monitoring system and method. Background Technology

[0002] Currently, in the field of carbon emission monitoring technology, ensuring the security and reliability of the accounting process, as a key link in preventing data tampering and avoiding privacy leaks, has become a key research area in the field of industrial data analysis.

[0003] In one existing technology, a centralized aggregation accounting method is mainly used to ensure the reliability of the monitoring process. This method relies primarily on independent systems or single evidence indicators for evaluation, such as using a self-reporting mode to perform calculation tasks and judging data credibility by simply uploading the results to the blockchain. However, this approach is clearly insufficient in complex computing environments. Plaintext calculations cannot adapt to the dynamic needs of energy consumption data privacy protection. Single evidence evaluation is susceptible to algorithm replacement and human intervention. The lack of transparency in the calculation process and the complexity of parameter calls make it difficult to guarantee the security and reliability of the accounting process. For example, in scenarios with high-frequency flow of multi-source energy consumption data and complex accounting logic, it is difficult to avoid the problem that the accounting results are tampered with during the generation and transmission stages without being traceable. Regulators and verification agencies can only accept the on-chain evidence results, but have no way to verify whether the accounting process strictly follows the predetermined conversion rules or whether the parameters are replaced during transmission. At the same time, enterprises resist data sharing due to concerns that sensitive information such as production processes and equipment loads may be obtained by unrelated nodes on the blockchain and external entities, resulting in low effectiveness of monitoring execution.

[0004] In summary, existing technologies are insufficient to achieve secure and reliable control over the carbon emission accounting process, and cannot meet the core requirement of verifiable accounting processes when facing complex energy consumption calculations in carbon emission monitoring technologies. Summary of the Invention

[0005] This invention provides a blockchain-based carbon emission monitoring system and method to achieve secure and reliable control over the carbon emission accounting process, and to meet the core requirement of verifiable calculation process in carbon emission monitoring technology when facing complex energy consumption calculations.

[0006] Firstly, in order to solve the above-mentioned technical problems, the present invention provides a blockchain-based carbon emission monitoring method, comprising: Obtain raw power consumption data, and perform encryption processing on the raw power consumption data to obtain initial ciphertext data; The initial ciphertext data is multiplied and added according to the pre-established conversion rules to obtain the target ciphertext data; the target ciphertext data is then decrypted to obtain the carbon emission equivalent value. Based on the initial encrypted data, the conversion rules, and the carbon emission equivalent value, a proof encapsulation process is performed to obtain a proof certificate for the calculation process; a hash extraction process is then performed on the proof certificate to obtain the certificate hash value. A data packet for evidence storage is constructed based on the hash value of the credential and the carbon emission equivalent value; if a block construction instruction is received, the data packet for evidence storage is written into the distributed ledger to obtain the ledger record address; Obtain a verification request based on the ledger record address, extract the corresponding calculation process proof voucher according to the verification request, and generate an untampered determination result if the calculation process proof voucher meets the pre-obtained verification rules; otherwise, generate an abnormal tampering determination result.

[0007] Secondly, the present invention provides a blockchain-based carbon emission monitoring system, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the blockchain-based carbon emission monitoring method as described above.

[0008] Compared with the prior art, the present invention has the following beneficial effects: (1) This invention obtains the original energy consumption data, removes outliers and segments it by time window, and then uses a homomorphic encryption algorithm to perform encryption transformation and fragmentation splicing to obtain the initial ciphertext data. In the ciphertext state, the emission factor ciphertext is matched according to the conversion rules and multiplication and addition aggregation operations are performed to obtain the target ciphertext data. After decryption and conversion with the global warming potential value, the carbon emission equivalent value is obtained. This invention breaks through the limitations of the traditional plaintext accounting method, which cannot take into account both data privacy protection and computational integrity. The original energy consumption data is hidden in the ciphertext space throughout the process to complete the carbon emission conversion. This makes it impossible for unrelated nodes on the chain and external entities to obtain the plaintext energy consumption details. However, the regulators and verification agencies can still obtain the complete plaintext data for compliance review through the decryption process according to their legal authority. This invention accurately achieves the goal of secure accounting with data hierarchical visibility and solves the problem that enterprises resist data sharing due to concerns that sensitive information such as production process and equipment load will be obtained by unrelated parties on the chain. This invention provides a data security basis for full-link encryption protection for carbon emission monitoring.

[0009] (2) This invention performs arithmetic circuit transformation and polynomial constraint construction based on initial encrypted data, conversion rules and carbon emission equivalent values. After arithmetic circuit assignment, a witness dataset is generated and merged to respond to random challenge verification. Then, after hash compression and non-interactive encapsulation, a certificate of proof of the calculation process is generated. After extracting the hash value of the certificate, a data package of evidence storage is constructed with the carbon emission equivalent value and written into the distributed ledger. This invention breaks through the limitation that the traditional method of putting the result on the chain cannot prove the credibility of the numerical generation process. With zero-knowledge proof technology, a verifiable logical correctness certificate is generated without exposing the original data and complete calculation details. The verifier can complete the compliance verification of the accounting process with only the certificate of proof and the verification key published on the chain. The whole process does not touch the plaintext data of the enterprise. It accurately connects the trust transfer link between encrypted accounting and on-chain evidence storage, and solves the problem that the regulator can only accept the result but has no way to trace whether the calculation process has been tampered with or whether the parameters have been replaced. It provides an auditable objective evidence of the calculation process for the carbon trading market.

[0010] (3) This invention performs digital signature processing on the initial evidence data and registers the signature public key on the blockchain, enabling any verifier to further verify the authenticity and integrity of the data source in addition to performing zero-knowledge proof verification on the computation process proof certificate, thus supplementing the trust foundation from the data source. In the verification stage, a verification request based on the ledger record address is obtained, and the candidate transaction record set is scanned and matched after deserialization parsing and routing addressing, and the computation process proof certificate is extracted. The verification key is used to perform zero-knowledge proof verification operation on the proof data segment, without needing to obtain the enterprise's original power data, emission factor plaintext, or any intermediate plaintext variables. It independently completes the verification of calculation correctness, and generates an tamper-proof judgment result when the verification is passed. It builds a full-link trusted monitoring system from data source signature authentication, data encryption collection, encrypted accounting, proof encapsulation, on-chain evidence storage to zero-knowledge verification. It breaks through the limitations of traditional carbon emission monitoring that relies solely on self-reporting and random checks and lacks a technical verification closed loop. While protecting the privacy of corporate commercial data, it empowers regulators and verification agencies to independently verify the compliance of the accounting process and the reliability of data sources, effectively improving the credibility and compliance of carbon emission monitoring data, and meeting the core requirements of secure and trustworthy carbon emission accounting process and verifiable results under the dual carbon objectives. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a blockchain-based carbon emission monitoring method provided in the first embodiment of the present invention; Figure 2 This is a schematic diagram of the zero-knowledge proof verification response provided in the first embodiment of the present invention. Detailed Implementation

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

[0013] Reference Figure 1 The first embodiment of the present invention provides a blockchain-based carbon emission monitoring method, comprising the following steps: S11, Obtain the original power consumption data, and perform encryption processing on the original power consumption data to obtain the initial ciphertext data; S12, perform ciphertext multiplication and addition operations according to the initial ciphertext data and the pre-established conversion rules to obtain target ciphertext data; perform decryption operation on the target ciphertext data to obtain carbon emission equivalent value; S13, perform proof encapsulation processing based on the initial encrypted data, the conversion rule, and the carbon emission equivalent value to obtain a calculation process proof certificate; perform hash extraction processing on the calculation process proof certificate to obtain the certificate hash value; S14, construct a data packet for evidence storage based on the hash value of the credential and the carbon emission equivalent value; if a block construction instruction is received, write the data packet for evidence storage into the distributed ledger to obtain the ledger record address; S15, obtain a verification request based on the ledger record address, extract the corresponding calculation process proof certificate according to the verification request, if the calculation process proof certificate meets the pre-obtained verification rules, generate an untampered determination result; if the calculation process proof certificate does not meet the verification rules, generate an abnormal tampering determination result.

[0014] In step S11, raw power consumption data is acquired. The raw power consumption data is collected in real time by a power monitoring device deployed at the enterprise. This device includes a voltage transformer and a current transformer. It synchronously acquires the voltage and current values ​​during the operation of the device at a sampling interval of 1 second. The voltage and current are multiplied by the voltage and current to obtain the instantaneous power through an edge computing gateway, and then a collection timestamp is added to form a time-series data stream containing the timestamp and instantaneous power.

[0015] In one implementation, the step of encrypting the original power consumption data to obtain initial ciphertext data includes: Outlier removal processing is performed on the original power consumption data to obtain standard consumption data; Perform time window segmentation on the standard consumption data to obtain a data fragment set; Perform algebraic encryption transformation on the data fragment set to obtain fragmented ciphertext data; If the number of fragmented ciphertext data reaches a preset fragmentation and splicing threshold, then the fragmented ciphertext data is subjected to time-series splicing processing to obtain the initial ciphertext data.

[0016] It should be noted that outlier removal was first performed on the raw power consumption data. The Isolation Forest algorithm was used to detect outliers in the instantaneous power data, with 100 isolated trees and 256 sub-sampling sizes, limiting the maximum depth of a single isolated tree to 8. The Isolation Forest model performed a binary partition on the instantaneous power sequence by randomly selecting a split point, recording the path length of each sample in each tree, calculating the average path length, and normalizing it according to the expected path length to obtain an outlier score in the range of 0 to 1. The outlier threshold was set to 0.65; data points with outlier scores exceeding 0.65 were identified as sensor sampling anomalies and removed. The vacant positions were filled by the arithmetic mean of the instantaneous power of the two adjacent normal sampling points. If the vacant position was located at the beginning or end of the data sequence, resulting in the lack of preceding or following sampling points, the instantaneous power of the nearest normal sampling point was used as the filling value to obtain the standard consumption data.

[0017] Next, time window segmentation is performed on the standard consumption data. A fixed time window length of 10 minutes is set, dividing the continuous standard consumption data into non-overlapping data blocks in chronological order. Each data block contains an instantaneous power sequence of 600 sampling points, and all data blocks constitute a data fragment set. The 10-minute window length is based on the data batch processing granularity commonly used in industrial monitoring, balancing the memory overhead of a single encryption operation with the timeliness of data processing.

[0018] Secondly, algebraic encryption transformation is performed on the data fragment set. The BFV scheme, a fully homomorphic encryption algorithm, is selected to encrypt each data fragment. The BFV scheme supports direct addition and multiplication operations on the ciphertext, and the decrypted result is identical to the result of performing the same operations on the plaintext. The encryption process first generates a public-key and private-key pair on the polynomial quotient ring. Then, each sampling point record within the data fragment is organized according to the field structure of the collection timestamp, instantaneous power value, and energy type identifier. Each field value is encoded as a polynomial coefficient, and then encrypted using the public key to obtain the corresponding ciphertext polynomial. Each encrypted data fragment is output as a fragment of ciphertext data.

[0019] Subsequently, if the number of fragmented ciphertext data reaches a preset fragmentation and splicing threshold, time-series splicing processing is performed on the fragmented ciphertext data. The fragmentation and splicing threshold is set to 6 fragments, corresponding to the cumulative data volume of 1 hour. This threshold is set based on the data processing scale and system reporting cycle, ensuring that the size of the data block generated each time is suitable for subsequent encrypted transmission and monthly aggregation processing. Those skilled in the art can adjust this threshold within the range of 0.8 to 1.2 times the baseline value based on actual network bandwidth, computational overhead, and accounting reporting frequency. When the cumulative generated fragmented ciphertext data reaches 6, the 6 fragmented ciphertext data are spliced ​​together end-to-end according to the chronological order of the timestamps corresponding to each fragment to obtain the initial ciphertext data. The initial ciphertext data completely retains all the original power information within 1 hour and remains in ciphertext throughout, without revealing any plaintext energy consumption details.

[0020] In step S12, the step of performing ciphertext multiplication and addition operations based on the initial ciphertext data and pre-established conversion rules to obtain the target ciphertext data includes: According to the conversion rule, a matching retrieval process is performed on the initial ciphertext data to obtain the emission factor ciphertext; Perform a ciphertext multiplication operation on the initial ciphertext data and the emission factor ciphertext to obtain the intermediate product ciphertext; If the intermediate product ciphertext meets the preset settlement period conditions, then the intermediate product ciphertext is subjected to aggregation and combination processing to obtain an aggregated ciphertext set; Perform ciphertext addition on the aggregated ciphertext set to obtain the accumulated carbon emission ciphertext; If the number of accumulated carbon emission ciphertexts reaches a preset output judgment threshold, then the accumulated carbon emission ciphertexts are subjected to message format encapsulation processing to obtain the target ciphertext data.

[0021] It should be noted that, firstly, the initial encrypted data is processed by matching and searching according to the conversion rules to obtain the emission factor encrypted data. The conversion rules are pre-established and stored in the blockchain smart contract, recording the mapping relationship between different energy types and corresponding carbon emission factors in the form of key-value pairs. The carbon emission factors are referenced from the average carbon dioxide emission factors for electricity jointly released by the Ministry of Ecology and Environment and the National Bureau of Statistics (e.g., the national average emission factor of 0.5703 tCO2 / MWh, or the emission factor for North China region of 0.6776 tCO2 / MWh, in tons of carbon dioxide / MWh, i.e., the amount of carbon dioxide emitted for every 1 MWh of electricity generated or consumed, which is a typical emission factor unit in carbon emission accounting). The corresponding values ​​for different regions are stored separately in the smart contract mapping table according to the regional code. Those skilled in the art can select the corresponding officially released emission factors according to the region where the enterprise is located or the accounting requirements. The energy type identifier field attached to the initial encrypted data is parsed. The energy type identifier is synchronously tagged by the edge computing gateway according to the energy type connected to the monitoring loop during data acquisition in step S11. The energy type identifier is used as the retrieval key to query the mapping table of the smart contract and obtain the corresponding plaintext value of the carbon emission factor. In order for the carbon emission factor to directly participate in homomorphic multiplication and addition operations, the plaintext factor needs to be converted to the same ciphertext field as the power ciphertext. Therefore, the plaintext carbon emission factor is encrypted with the same public key generated by the BFV scheme to obtain the emission factor ciphertext.

[0022] Next, ciphertext multiplication is performed on the initial ciphertext data and the emission factor ciphertext to obtain the intermediate product ciphertext. The ciphertext multiplication operation directly calls the homomorphic multiplication operation defined in the BFV scheme, multiplying the power ciphertext and emission factor ciphertext corresponding to each sampling point in the initial ciphertext data element-wise in the ciphertext domain. The physical meaning of the multiplication result is the instantaneous carbon emission ciphertext within a single sampling interval. The product results of all sampling points are arranged in the original timestamp order to form the intermediate product ciphertext. The homomorphic multiplication in the BFV scheme follows the modular arithmetic rules on a polynomial ring. Multiplication operations lead to an increase in ciphertext noise. The degree of noise budget consumption is determined by parameters such as the polynomial order, modulus size, plaintext modulus, and key distribution. Optimizing parameter configuration can ensure that there is still sufficient noise budget to support subsequent addition operations after the required multiplications are completed.

[0023] Secondly, if the intermediate product ciphertext meets the preset settlement period condition, it is aggregated and combined to obtain an aggregated ciphertext set. The settlement period condition is set when the cumulative time span covered by the intermediate product ciphertext reaches 720 hours. This number of hours is calculated based on the monthly reporting period stipulated in the "Guidelines for Verification of Enterprise Greenhouse Gas Emission Reports" issued by the Ministry of Ecology and Environment of China, using a standard conversion relationship of 30 days multiplied by 24 hours. This period length is set with reference to the monthly emission reporting system of China's pilot carbon market, and those skilled in the art can adjust it within the range of 0.8 to 1.2 times the benchmark value according to the actual compliance period. When the cumulative time span meets 720 hours, all intermediate product ciphertexts within the current month are combined into an aggregated ciphertext set by concatenating them in chronological order.

[0024] Subsequently, ciphertext addition is performed on the aggregated ciphertext set to obtain the accumulated carbon emission ciphertext. The ciphertext addition operation calls the homomorphic addition operation defined in the BFV scheme, summing all intermediate product ciphertexts in the aggregated ciphertext set element-wise in the ciphertext field. The physical meaning of the accumulated result is the ciphertext of the total cumulative carbon emissions for that monthly period. Homomorphic addition has a relatively small impact on the noise budget; under typical parameter settings, the noise accumulated from hundreds of additions is still far lower than that from a single multiplication.

[0025] Then, if the number of accumulated carbon emission ciphertexts reaches a preset output threshold, the accumulated carbon emission ciphertexts are encapsulated in a message format to obtain the target ciphertext data. The output threshold is set at 12 accumulated carbon emission ciphertexts, corresponding to 12 months of cumulative emission data. This threshold is set based on industry practice for annual quota settlement in the carbon trading market, ensuring that the target ciphertext data fully covers all monthly calculation results for a calendar year. The message format encapsulation process arranges the 12 accumulated carbon emission ciphertexts in monthly order from January to December, adds a data version number and year identifier field to the header, and adds a ciphertext integrity verification field to the tail before packaging them into a unified message format to obtain the target ciphertext data. The target ciphertext data serves as a ciphertext certificate for the total annual carbon emissions and can be directly submitted to a third-party verification agency or regulatory platform for decryption and calculation.

[0026] In one implementation, performing a decryption operation on the target encrypted data to obtain a carbon emission equivalent value includes: Perform an asymmetric decryption operation on the target ciphertext data to obtain a plaintext data stream; Perform field stripping and parsing processing on the plaintext data stream to obtain greenhouse gas types and baseline emission values; The global warming potential is determined based on the type of greenhouse gas, and a multiplication operation is performed between the baseline emission value and the global warming potential to obtain the equivalent product value. If the equivalent product value meets the preset data verification rules, then all the equivalent product values ​​are summed and accumulated to obtain the carbon emission equivalent value.

[0027] It should be noted that, firstly, an asymmetric decryption operation is performed on the target ciphertext data to obtain the plaintext data stream. The decryption operation uses the private key corresponding to the encryption using the BFV scheme. This private key is generated and stored offline by the enterprise's carbon emission management department through a hardware security module. The decryption process calls the decryption function in the BFV scheme to decrypt each ciphertext polynomial in the target ciphertext data using the private key, extracting the polynomial coefficients. These coefficients are then remapped back to the monthly cumulative carbon emission values. All decrypted values ​​are arranged in monthly order from January to December to form the plaintext data stream.

[0028] Next, field stripping and parsing are performed on the plaintext data stream to obtain the greenhouse gas type and baseline emission value. The plaintext data stream is organized with a fixed field structure during encapsulation. Each monthly emission record includes a greenhouse gas type code field, a baseline emission value field, and a timestamp field. The greenhouse gas type code is tagged by the edge computing gateway according to the energy type connected to the monitoring loop during data acquisition in step S11, and is encrypted along with the power data. After decryption, it is read out through field stripping. The greenhouse gas type code field occupies 2 bytes, the baseline emission value field occupies 4 bytes of single-precision floating-point number, and the timestamp field occupies 8 bytes of Unix timestamp. The greenhouse gas type code and baseline emission value of each emission record are read sequentially according to the field offset, and the greenhouse gas type code and baseline emission value of all records are extracted into two independent sequences.

[0029] Secondly, the global warming potential is determined based on the greenhouse gas type. A multiplication operation is performed between the baseline emission value and the global warming potential to obtain the equivalent product. In this embodiment, the monitored object is electrical energy, corresponding to the greenhouse gas type carbon dioxide, with a global warming potential of 1. When the monitored object involves multiple greenhouse gases, conversion is performed separately for each greenhouse gas type. The global warming potential is referenced from the 100-year timescale global warming potential values ​​published in the Fifth Assessment Report of the Intergovernmental Panel on Climate Change (IPCC). The greenhouse gas type code is used as the retrieval key to find the corresponding global warming potential value in a preset potential value mapping table. This potential value mapping table is deployed on the blockchain using a smart contract storage mapping structure. The key is a 2-byte greenhouse gas type code, and the value is a 4-byte single-precision floating-point number representing the corresponding global warming potential value for that gas. The greenhouse gas type codes and corresponding potential values ​​stored in the table are as follows: code 0x01 corresponds to carbon dioxide potential value 1, code 0x02 corresponds to methane potential value 28, code 0x03 corresponds to nitrous oxide potential value 265, and so on. Code 0x04 corresponds to a hydrofluorocarbon potential value ranging from 12 to 14800, depending on the specific molecular structure; code 0x05 corresponds to a perfluorocarbon potential value ranging from 6630 to 11100, depending on the specific molecular structure; and code 0x06 corresponds to a sulfur hexafluoride potential value of 23500. The contents of the mapping table are permanently written during smart contract deployment, and subsequent updates require multi-signature permission control. Then, using carbon dioxide as a reference, the baseline emission value is multiplied by the obtained global warming potential value, and the product is the equivalent product value after conversion to carbon dioxide.

[0030] Subsequently, if the equivalent product value meets the preset data verification rules, all equivalent product values ​​are aggregated and accumulated to obtain the carbon emission equivalent value. The data verification rules are set so that the deviation between the monthly equivalent product value and the arithmetic mean of the equivalent product values ​​of the past 11 months does not exceed 30%. This deviation threshold is set based on industry statistical experience regarding the annual fluctuation range of carbon emission data. After the monthly equivalent product value passes verification, the equivalent product values ​​of the current month and the past 11 months are accumulated one by one. The accumulated result is the carbon emission equivalent value covering all greenhouse gas types within the accounting year.

[0031] In step S13, the step of performing proof encapsulation processing based on the initial encrypted data, the conversion rule, and the carbon emission equivalent value to obtain a proof certificate for the calculation process includes: According to the conversion rule, the initial encrypted data and the carbon emission equivalent value are converted by arithmetic circuits to obtain polynomial constraints. Based on the polynomial constraints, a common reference string is extracted, and an arithmetic circuit assignment calculation is performed to obtain the witness data set. If the random challenge value of the witness data set satisfies the polynomial constraint, then a hash compression operation is performed to obtain hash digest information; A non-interactive encapsulation process is performed on the hash digest information and the public reference string to generate a proof of the computation process.

[0032] It should be noted that, firstly, an arithmetic circuit conversion is performed on the initial encrypted data and carbon emission equivalent values ​​according to the conversion rules to obtain polynomial constraints. The arithmetic circuit conversion uses the R1CS constraint system in the zero-knowledge proof protocol to expand all calculation steps, including emission factor conversion, encrypted multiplication, and encrypted addition, into a series of multiplication gate constraints. Each multiplication gate corresponds to one encrypted homomorphic operation, and its constraint form is that the dot product of vector L and coefficient matrix A multiplied by the dot product of vector R and coefficient matrix B equals the dot product of vector O and coefficient matrix C, i.e., satisfying the equation (A·L)×(B·R)=(C·O), where vectors L, R, and O represent the left input variable set, right input variable set, and output variable set, respectively, and coefficient matrices A, B, and C are determined by the specific operational relationships of each multiplication gate. The coefficient matrices of each multiplication gate are then connected sequentially according to the input-output relationship to assemble a unified R1CS matrix, and then converted into polynomial constraints over a finite field using Lagrange interpolation. The polynomial constraint fully characterizes the entire encrypted calculation logic from the original power to the final carbon emission equivalent, and the highest degree of the polynomial is linearly related to the number of multiplication gates.

[0033] Next, a common reference string is extracted based on polynomial constraints, and encrypted state algebra operations are performed to obtain the witness data set. The common reference string is generated through a trusted setup process. During this process, a random number is generated as a secret parameter. The secret parameter and the generator of the elliptic curve group are used to calculate the corresponding group elements, which are then published as the common reference string. This secret parameter is immediately destroyed after the setup is completed via a key erasure command from the hardware security module. The erasure operation overwrites all bytes in the secure storage area containing the secret parameter with 0x00 and releases the storage pages, making it unrecoverable. The common reference string contains two parts: a proof key and a verification key. The proof key is used for subsequent witness data generation. The proving party performs arithmetic circuit assignment calculations based on the plaintext inputs it possesses, obtaining a witness data set. The plaintext inputs include the plaintext power values ​​corresponding to the initial ciphertext data, the plaintext emission factor values ​​in the conversion rules, and intermediate plaintext variables generated during the calculation process. The proving party substitutes these plaintext inputs one by one into each multiplication and addition gate corresponding to the polynomial constraints, obtaining complete variable assignments that satisfy the constraints through gate-by-gate calculations. All variable assignments are arranged in gate order to form the witness data set. The R1CS matrix obtained from each round of arithmetic circuit transformation corresponds structurally one-to-one with the emission calculation steps for that accounting year, ensuring that each assignment in the witness data set can be traced back to a specific ciphertext multiplication or addition operation.

[0034] Secondly, if the random challenge value of the witness dataset satisfies the polynomial constraint, a hash compression operation is performed to obtain the hash digest information. The random challenge value is generated through the Fiat-Shamir transformation. All intermediate variables in the witness dataset are assigned to the group elements of the proof key and linearly combined to compress it into a single group element. The SHA-256 hash function is then applied to this group element to obtain a 256-bit random challenge value. The method to verify whether the random challenge value satisfies the polynomial constraint is to substitute the random challenge value into the polynomial constraint and calculate the polynomial value at that point. If the calculation result is a zero vector, it is determined that the constraint is satisfied, indicating that the assignment in the witness dataset is consistent with the polynomial constraint at the random challenge point. After the random challenge value satisfies the condition, a Merkle tree structure is used to perform layered hashing on the witness dataset. In each layer, the hash values ​​of two adjacent child nodes are concatenated and then subjected to SHA-256 operation again to obtain the hash value of the parent node. This process is repeated layer by layer until a single root node is output, providing a 256-bit hash digest.

[0035] Subsequently, non-interactive encapsulation processing is performed on the hash digest information and the public reference string to generate a computation process proof credential. The hash digest information serves as a compressed identifier for the proof content, and the verification key in the public reference string serves as the structured metadata of the credential. Both are encapsulated into a fixed-length computation process proof credential according to a preset proof format specification. The computation process proof credential contains five segments: a proof identifier segment, a 256-bit hash digest information segment, a verification key reference segment, a timestamp segment, and a proof data segment, with a total length of 512 bytes. The proof data segment carries zero-knowledge proof data, which is calculated and generated by the proving party in step S13 based on the witness data set and the proof key in the public reference string. Specifically, it includes proof group elements on the elliptic curve group generated through R1CS constraint transformation and polynomial commitment. This computation process proof credential allows any third party holding the verification key to independently verify the correctness of the calculated carbon emission equivalent value without disclosing the initial ciphertext data and the emission factor ciphertext.

[0036] In one implementation, performing hash extraction processing on the certificate to obtain the certificate hash value includes: The calculation process proves that the voucher is parsed using a syntax tree to obtain the voucher's structured fields; The structured fields of the voucher are concatenated according to the pre-acquired serialization rules to obtain the voucher byte sequence; If the length of the voucher byte sequence does not reach the preset group length threshold, then a bit-filling operation is performed on the voucher byte sequence to obtain a standard data block; A nonlinear compression operation is performed on the standard data block to obtain an intermediate state matrix, and a feature truncation extraction process is performed on the intermediate state matrix to obtain the credential hash value.

[0037] It should be noted that, firstly, the computational process proof certificate is parsed using a syntax tree to obtain the certificate's structured fields. The computational process proof certificate has already been encapsulated into a 512-byte string in a fixed format in previous steps. The syntax tree parsing is performed by segmenting the certificate according to the field offsets and lengths defined in this format specification. The certificate identifier segment is located at offset 0 bytes and has a length of 16 bytes; the hash digest information segment is located at offset 16 bytes and has a length of 32 bytes; the verification key reference segment is located at offset 48 bytes and has a length of 8 bytes; the timestamp segment is located at offset 56 bytes and has a length of 8 bytes; the remaining 448 bytes are the proof data segment. The contents of each segment are read sequentially according to the offset, and the field names and byte arrays of each segment are recorded, outputting five structured certificate fields.

[0038] Next, the structured fields of the voucher are concatenated according to the pre-obtained serialization rules to obtain the voucher byte sequence. The serialization rules are set to concatenate the voucher identifier field, hash digest information field, verification key reference field, and timestamp field in the order of first and last, without inserting separators between the fields. The byte arrays corresponding to the four fields are directly concatenated in this order, and an 8-byte voucher format identifier field is appended to the header of the concatenation result, resulting in a continuous byte array of length 72 bytes. This byte array is the voucher byte sequence. The proof data segment does not participate in the concatenation operation.

[0039] Secondly, if the length of the voucher byte sequence does not reach the preset block length threshold, a bit-padding operation is performed on the voucher byte sequence to obtain a standard data block. The block length threshold is set to 512 bits, or 64 bytes, based on the input block length of the SHA-256 hash algorithm. The current length of the voucher byte sequence is 72 bytes, which exceeds 64 bytes. It needs to be split into two blocks of 64 bytes each. The first block consists of the first 64 bytes, and the remaining 8 bytes are used as the second block. The bit-padding rules defined in the SHA-256 standard are applied to the second block. First, a byte with a value of 0x80 is appended to the end of the remaining 8 bytes as a padding start marker. Then, zero bytes with a value of 0x00 are appended continuously until the total length of the second block reaches 56 bytes. Finally, 8 bytes of the original message length in big-endian representation are appended, making the total length of the second block exactly 64 bytes. The two padded 64-byte blocks together constitute the standard data block.

[0040] Subsequently, a nonlinear compression operation is performed on the standard data block to obtain an intermediate state matrix. Feature truncation and extraction are then performed on the intermediate state matrix to obtain the credential hash value. The nonlinear compression operation uses the SHA-256 algorithm's compression function. The eight 32-bit initial hash values ​​are initialized according to the first 32 bits of the fractional part of the square root of the first eight prime numbers as specified in Section 5.3.3 of the NIST FIPS 180-4 standard: H0 is 0x6a09e667, H1 is 0xbb67ae85, H2 is 0x3c6ef372, H3 is 0xa54ff53a, H4 is 0x510e527f, H5 is 0x9b05688c, H6 is 0x1f83d9ab, and H7 is 0x5be0cd19. The first 64-byte group undergoes 64 rounds of nonlinear transformations, including the Sigma function, selection function, and majority function. After updating the eight 32-bit working variables in each round, a new intermediate hash value is output. The eight 32-bit outputs from the previous round are used as the initial eight 32-bit values ​​for the next round, and 64 rounds of compression transformation are performed on the second 64-byte group. After two rounds of compression, a total of 256 bits of working variables (eight 32-bit) are obtained, which serves as the intermediate state matrix. The feature truncation extraction process directly uses this 256-bit intermediate state matrix as the final output credential hash value without truncation.

[0041] In step S14, the process of constructing a data storage packet based on the credential hash value and the carbon emission equivalent value, and writing the data storage packet into the distributed ledger to obtain the ledger record address if a block construction instruction is received, includes: Perform a field mapping and encapsulation operation based on the credential hash value and the carbon emission equivalent value to obtain the initial credential storage data; Perform digital signature processing on the initial evidence storage data to obtain the evidence storage data packet; Sending the evidence storage data packet to the distributed nodes triggers the consensus verification logic, and the node verification status is obtained; If the node verification status is valid, then the block construction instruction is obtained; The latest block height is extracted according to the block construction instruction, and the evidence storage data packet is combined and mapped according to the latest block height to obtain the data to be packaged. The Merkle root is obtained by iterative hash calculation of the data to be packaged, and the ledger state tree is updated according to the Merkle root to obtain the block header structure; The evidence storage data packet is written into the distributed ledger according to the block header structure to obtain the storage index value, and the storage index value is subjected to encoding conversion processing to obtain the ledger record address.

[0042] It should be noted that, firstly, a field mapping and encapsulation operation is performed based on the credential hash value and the carbon emission equivalent value to obtain the initial evidence storage data. The evidence storage data structure is defined to include four fields: an 8-byte evidence storage identifier field, a 32-byte credential hash value field, an 8-byte double-precision floating-point carbon emission equivalent value field, and an 8-byte Unix timestamp field. The credential hash value is directly filled into the second field, the carbon emission equivalent value into the third field, the evidence storage identifier (generated by adding an auto-incrementing sequence number to the enterprise carbon account code) into the first field, and the evidence storage timestamp (the current time) into the fourth field. These fields are then concatenated in order to form 56 bytes of initial evidence storage data.

[0043] Next, digital signature processing is performed on the initial evidence storage data to obtain the evidence storage data packet. The digital signature uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve parameter. The signing private key is generated and stored by the enterprise's carbon emission account holder through a hardware security module. First, the initial evidence storage data is hashed using SHA-256 to obtain a 256-bit message digest. Then, the message digest is signed using the private key, outputting a 64-byte signature value. The initial evidence storage data is used as the data payload, the signature value as the tail appendix, the signature algorithm identifier (2 bytes), and the signer's public key (33 bytes) as the header metadata. These are assembled into a 155-byte evidence storage data packet body in the order of header metadata, data payload, and tail appendix. An extended data segment is appended to the end of the data payload. The first 2 bytes of the extended data segment indicate the length of the extended data, followed by 512 bytes of serialized data proving the calculation process. The evidence storage data packet body and the extended data segment together constitute the complete evidence storage data packet, totaling 669 bytes.

[0044] Secondly, sending the evidence storage data packet to the distributed nodes triggers the consensus verification logic, obtaining the node verification status. The evidence storage data packet is sent to all distributed nodes in the network via the blockchain network's gossip broadcast protocol. Each node that receives the evidence storage data packet independently executes the verification process. The verification process first extracts the signature algorithm identifier and the signer's public key from the header metadata. After performing SHA-256 hashing on the data payload, it verifies whether the signature value in the appendix is ​​generated by the private key corresponding to the public key. If the verification passes, it further verifies whether the carbon emission equivalent value in the data payload deviates from the value of the previous accounting period already stored on the chain within the allowable range, which is set to 50% to 200% of the value of the previous period. After completing the verification, each node broadcasts its verification voting results to the entire network.

[0045] Subsequently, if the node verification status is valid, a block construction instruction is obtained. The validity status is determined using a practical Byzantine fault tolerance mechanism, where the total number of network nodes N satisfies the relationship N = 3f + 1, where f is the pre-defined Byzantine fault-tolerant node limit in the consensus protocol. The consensus process includes three phases: pre-preparation, preparation, and commit. After the pre-preparation message and block proposal sent by the master node are received by each node, each node enters the preparation phase and broadcasts a preparation message. When a node collects 2f + 1 consistent preparation messages from different nodes, it enters the commit phase and broadcasts a commit message. After collecting 2f + 1 consistent commit messages, the node verification status of the evidence storage data packet is confirmed as valid. At this point, the node with the highest cumulative number of votes passed in the current consensus round is selected as the master node. After receiving confirmation of the valid status, the master node triggers the generation of a block construction instruction, which contains the set of all valid evidence storage data packets to be packaged in this round.

[0046] The latest block height is extracted based on the block construction instructions. A combination mapping process is then performed on the evidence storage data packets based on this latest block height to obtain the data to be packaged. The latest block height is obtained by querying the local ledger status maintained by the master node, returning the largest block number currently stored on the chain. The latest block height is incremented by one to obtain the expected height of the new block, which is written into the block height field (8 bytes). The evidence storage data packets for this round are then sorted in ascending order by evidence storage timestamp and written sequentially into the transaction data body field. Each evidence storage data packet is assigned a transaction sequence number according to the sorting order. The length of the transaction data body field is calculated cumulatively from the actual byte length of each transaction record. Each transaction record consists of a 2-byte length field and a complete evidence storage data packet, with the complete evidence storage data packet including extended data segments totaling 669 bytes. The block height field and the transaction data body field are combined in sequence to form the data to be packaged.

[0047] Next, iterative hash calculations are performed on the data to be packaged to obtain the Merkle root. The ledger state tree is then updated based on the Merkle root to obtain the block header structure. The iterative hash calculation first performs SHA-256 hashing on each data packet in the transaction data body field, obtaining each transaction hash value as a leaf node of the Merkle tree. Then, the hash values ​​of two adjacent leaf nodes are concatenated and SHA-256ed to obtain the parent node. The hashing is iterated upwards layer by layer until it is merged into a single root node, outputting a 32-byte Merkle root. The block header structure is composed of the block header hash of the previous block, the new block height, the current Unix timestamp, the consensus round number, the Merkle root, the number of transactions in the block, and the reserved extension fields, totaling 128 bytes. The block header hash occupies 32 bytes, the new block height occupies 8 bytes, the current Unix timestamp occupies 8 bytes, the consensus round number occupies 8 bytes, the Merkle root occupies 32 bytes, the number of transactions in the block is located at offset 88 bytes and occupies 2 bytes, and the reserved extension fields occupy 38 bytes.

[0048] Finally, the evidence storage data packet is written into the distributed ledger according to the block header structure to obtain the storage index value. The storage index value is then encoded to obtain the ledger record address. The storage index value uses a combination of the new block height and transaction sequence number. The first 8 bytes represent the block height, and the last 12 bytes represent the transaction sequence number. The ledger maps the combination of block height and transaction sequence number to the corresponding block header structure plus the transaction data body in key-value storage. Since blockchain nodes fully synchronize ledger data through the block synchronization protocol, any node can retrieve the corresponding evidence storage data packet from its local ledger based on the block height and transaction sequence number. Therefore, the combination of block height and transaction sequence number is used as the ledger record address. The storage index value is Base58Check encoded, with a 0x00 version prefix byte appended and a 4-byte SHA-256 double hash checksum appended to the end. The encoded result is a Base58 string used as the ledger record address identifier that can be displayed and queried. The ledger record address can be used to initiate a query request to any distributed node via a blockchain explorer or command-line interface, returning the full text of the corresponding evidence storage data packet.

[0049] In step S15, retrieving the corresponding proof of the calculation process based on the verification request includes: The verification request is deserialized and parsed to obtain the request payload data; Extract the ledger record address and target hash value based on the request payload data, and perform routing addressing based on the ledger record address to obtain the target block location information; A set of candidate transaction records is obtained by backtracking and scanning based on the target block location information; The target transaction record is obtained by performing feature matching processing on the candidate transaction record set according to the target hash value, and the calculation process proof certificate is extracted from the target transaction record.

[0050] It should be noted that, firstly, the verification request undergoes deserialization parsing to obtain the request payload data. The verification request is initiated by an external regulatory node or third-party verification agency through the blockchain network's API gateway. The request message body is serialized into a binary byte stream using Protocol Buffers format. The deserialization process is performed according to a predefined proto message structure description file, which defines the request payload data field numbered 1 and whose type is a byte array. The parser reads the binary data of the request message, matches it according to the field number, extracts the corresponding byte segments, and reconstructs the request payload data.

[0051] Next, the ledger record address and target hash value are extracted from the request payload data. Routing is then performed based on the ledger record address to obtain the target block location information. The request payload data uses a fixed-length field arrangement: the first 34 bytes are the Base58Check encoded ledger record address, the following 32 bytes are the target hash value provided by the requester, and the remaining bytes are the requester's signature data. After reading the first 34 bytes and decoding them using Base58, 25 bytes of raw data are obtained. The first byte (version number 0x00) and the last 4 bytes (double SHA-256 checksum) are then removed, leaving 20 bytes, which is a concatenation of the block height and transaction sequence number. The first 8 bytes represent the block height, and the last 12 bytes represent the transaction's index within the block. Routing is performed based on the block height in the block index database maintained by the local node. The local index database is implemented using LevelDB key-value storage, where the key is the block height and the value is a combination of the block file path and offset. If a local match is not found, a query is initiated to the k nearest neighboring nodes to the block height hash value via the Kademlia distributed hash table protocol. The number of neighboring nodes k is set to 20 according to the redundancy factor specified in the Kademlia protocol. This value comes from an empirical parameter designed in the Kademlia standard protocol to ensure that the query success rate is not less than 99.9% when a single node fails. Those skilled in the art can adjust the value of k within the range of 0.5 to 2 times the baseline value according to the total number of network nodes, that is, the value of k is between 10 and 40. The query retrieves the physical storage node IP address and transmission port of the target block, and outputs the target block location information containing the node identifier and storage offset.

[0052] Secondly, a candidate transaction record set is obtained by backscanning based on the target block location information. A block body read request is sent to the node specified by the location information, carrying the block height and offset parameters. The node returns the binary data of the corresponding block. The block body data consists of a 128-byte block header and a variable-length transaction data body. The 2-byte field at offset 88 bytes in the block header stores the number of transactions in the block. After reading this number of transactions, each transaction is parsed one by one from the beginning of the transaction data body. The first 2 bytes of each transaction record are the length of the transaction record. The complete transaction record is truncated according to the length field. This process is repeated until the number of transactions reaches zero. All the truncated transaction records are then added to the candidate transaction record set.

[0053] Subsequently, feature matching is performed on the candidate transaction record set based on the target hash value to obtain the target transaction record, and the computation process proof certificate is extracted from the target transaction record. The feature matching process traverses the candidate transaction record set. Each transaction record is a proof data packet, the structure of which is a 2-byte signature algorithm identifier, a 33-byte signer public key, a 56-byte data payload, and a 64-byte signature value. The 32 bytes starting at an 8-byte offset in the data payload are the certificate hash value field. The target hash value is compared byte by byte with this field. If they match completely, the current transaction record is determined to be the target transaction record. In addition to the encapsulated 56-byte fixed-length part, the data payload of the target transaction record also has an extended data segment at the end. The first 2 bytes of this extended data segment indicate the length of the extended data, followed by 512 bytes of serialized data for the computation process proof certificate. After reading the length of the extended data segment and verifying that it is correct, the 512 bytes of data are extracted according to the offset, thus obtaining the computation process proof certificate.

[0054] In one implementation, if the calculation process proves that the credential satisfies the pre-acquired verification rules, an untampered determination result is generated; if the calculation process proves that the credential does not satisfy the verification rules, an abnormal tampering determination result is generated, including: The computation process is used to perform structured parsing on the proof credentials to extract the proof data segment and the verification key reference segment; The verification key is obtained from the verification key reference segment, and the zero-knowledge proof verification operation is performed on the proof data segment using the verification key to obtain the verification output result. If the verification output result is equal to the preset verification pass benchmark value, then an untampered judgment result is generated; If the verification output result is not equal to the verification pass benchmark value, an abnormal tampering judgment result is generated.

[0055] It should be noted that the computation process proof certificate is first subjected to structured parsing processing. In step S15, the computation process proof certificate is extracted into 512 bytes of serialized data. The first 16 bytes are the proof identifier segment, the next 32 bytes are the hash digest information segment, the next 8 bytes are the verification key reference segment, the next 8 bytes are the timestamp segment, and the remaining 448 bytes are the proof data segment. The structured parsing process deserializes each field according to the preset proof format specification. The zero-knowledge proof data generated in step S13 is extracted from the proof data segment. This proof data contains a finite number of group elements on the elliptic curve group, specifically the proof parameters generated through R1CS constraint transformation and polynomial commitment. The on-chain storage index of the verification key is extracted from the verification key reference segment, and the corresponding verification key is retrieved by querying the public reference string storage contract of the blockchain using this index.

[0056] Next, the verification key is obtained from the verification key reference segment. The verification key is then used to perform a zero-knowledge proof verification operation on the proof data segment to obtain the verification output. The verification operation employs the pairwise verification method in the zero-knowledge proof protocol. The verification key contains several fixed group elements on elliptic curve groups G1 and G2, and the proof data segment contains several proof group elements on G1. The verification operation pairs the fixed group elements in the verification key with the proof group elements in the proof data segment according to a preset bilinear pairwise mapping relationship. The pairwise mapping e: G1×G2→GT is a bilinear mapping, and the verification equation is of the form e(A,B)=e(C,D), where A, B, C, and D are the group elements calculated based on the verification key and the proof data, respectively. If the results of mapping both sides of the equation to the target group GT are equal, the verification output is the preset verification pass benchmark value, i.e., the identity element of the GT group; otherwise, it is a non-identity element.

[0057] The entire verification process relies solely on the computational proof certificate itself and the publicly available verification key on the blockchain. The verifier does not need to obtain the company's original power data, emission factor plaintext, or any intermediate plaintext variables from the calculation process to independently verify the correctness of the calculation. The verification benchmark value is preset as the identity element of the elliptic curve target group GT. This verification benchmark value is determined and published during the initialization phase of the zero-knowledge proof protocol by the trusted setting process of the public reference string.

[0058] If the verification output equals the verification benchmark value, it indicates that the carbon emission equivalent value carried in the certificate is indeed calculated from the correct emission factor and original power data according to the predetermined conversion rules, and the data has not been tampered with during storage and transmission, generating an untampered judgment result. If the verification output does not equal the verification benchmark value, it indicates that the certificate cannot pass mathematical verification, and there is a possibility that the data has been tampered with or the calculation process does not conform to the predetermined rules, generating an abnormal tampering judgment result. The untampered judgment result or the abnormal tampering judgment result will be written to the audit log along with the certificate identification number segment and trigger an on-chain state update, providing an on-chain traceable compliance judgment basis for subsequent carbon emission verification and carbon quota trading.

[0059] like Figure 2As shown in the figure, the distribution of the zero-knowledge proof verification response in the proof parameter space is clearly visible. It can be clearly observed that within the two-dimensional parameter plane formed by proof parameters X and Y, random parameter combinations that do not satisfy the preset polynomial constraints (red and orange scatter points) are initially widely distributed in the low-response region near the value of 0. However, after the zero-knowledge proof verification operation, the valid proof parameter combinations that satisfy the verification rules (green spike distribution) are significantly converged and clustered in a very small neighborhood near the verification pass benchmark value of 1.0, resulting in a significant improvement in the peak response. This result intuitively demonstrates that this scheme can independently complete the cryptographic verification of calculation correctness without exposing the company's original power data, emission factor plaintext, or any intermediate plaintext variables, providing a solid cryptographic basis for the subsequent generation of unaltered and abnormally tampered judgment results.

[0060] In summary, this invention discloses a blockchain-based carbon emission monitoring method. The method involves acquiring raw energy consumption data and encrypting it to obtain initial ciphertext data; performing multiplication, addition, and decryption operations on the ciphertext based on conversion rules to obtain the carbon emission equivalent value; generating a proof of the calculation process and extracting the hash value of the proof; constructing a storage data package using the hash value and the equivalent value and writing it to the blockchain; and retrieving the proof of the process based on a verification request for verification, generating a result indicating whether the process has been tampered with or abnormally tampered with. This method achieves secure and reliable control over the carbon emission accounting process and meets the core requirement of verifiable calculation.

[0061] The second embodiment of the present invention provides a blockchain-based carbon emission monitoring system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method described above.

[0062] It should be noted that the blockchain-based carbon emission monitoring system provided in this embodiment of the invention is used to execute all the process steps of the blockchain-based carbon emission monitoring method in the above embodiment. The working principles and beneficial effects of the two are one-to-one, so they will not be described again.

[0063] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A blockchain-based carbon emission monitoring method, characterized in that, include: Obtain raw power consumption data, and perform encryption processing on the raw power consumption data to obtain initial ciphertext data; The target ciphertext data is obtained by performing ciphertext multiplication and addition operations based on the initial ciphertext data and the pre-established conversion rules. Decryption is performed on the target encrypted data to obtain the carbon emission equivalent value; Based on the initial encrypted data, the conversion rules, and the carbon emission equivalent value, a proof encapsulation process is performed to obtain a proof certificate for the calculation process; a hash extraction process is then performed on the proof certificate to obtain the certificate hash value. A data packet for evidence storage is constructed based on the hash value of the credential and the carbon emission equivalent value; if a block construction instruction is received, the data packet for evidence storage is written into the distributed ledger to obtain the ledger record address; Obtain a verification request based on the ledger record address, extract the corresponding calculation process proof voucher according to the verification request, and if the calculation process proof voucher meets the pre-obtained verification rules, generate an untampered determination result. If the calculation process proves that the credential does not meet the verification rules, an abnormal tampering judgment result is generated.

2. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The encryption process performed on the original power consumption data to obtain initial ciphertext data includes: Outlier removal processing is performed on the original power consumption data to obtain standard consumption data; Perform time window segmentation on the standard consumption data to obtain a data fragment set; Perform algebraic encryption transformation on the data fragment set to obtain fragmented ciphertext data; If the number of fragmented ciphertext data reaches a preset fragmentation and splicing threshold, then the fragmented ciphertext data is subjected to time-series splicing processing to obtain the initial ciphertext data.

3. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The step of performing ciphertext multiplication and addition operations based on the initial ciphertext data and pre-established conversion rules to obtain the target ciphertext data includes: According to the conversion rule, a matching retrieval process is performed on the initial ciphertext data to obtain the emission factor ciphertext; Perform a ciphertext multiplication operation on the initial ciphertext data and the emission factor ciphertext to obtain the intermediate product ciphertext; If the intermediate product ciphertext meets the preset settlement period conditions, then the intermediate product ciphertext is subjected to aggregation and combination processing to obtain an aggregated ciphertext set; Perform ciphertext addition on the aggregated ciphertext set to obtain the accumulated carbon emission ciphertext; If the number of accumulated carbon emission ciphertexts reaches a preset output judgment threshold, then the accumulated carbon emission ciphertexts are subjected to message format encapsulation processing to obtain the target ciphertext data.

4. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The step of performing a decryption operation on the target encrypted data to obtain the carbon emission equivalent value includes: Perform an asymmetric decryption operation on the target ciphertext data to obtain a plaintext data stream; Perform field stripping and parsing processing on the plaintext data stream to obtain greenhouse gas types and baseline emission values; The global warming potential is determined based on the type of greenhouse gas, and a multiplication operation is performed between the baseline emission value and the global warming potential to obtain the equivalent product value. If the equivalent product value meets the preset data verification rules, then all the equivalent product values ​​are summed and accumulated to obtain the carbon emission equivalent value.

5. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The step of performing proof encapsulation processing based on the initial encrypted data, the conversion rules, and the carbon emission equivalent value to obtain a proof certificate for the calculation process includes: According to the conversion rule, the initial encrypted data and the carbon emission equivalent value are converted by arithmetic circuits to obtain polynomial constraints. Based on the polynomial constraints, a common reference string is extracted, and an arithmetic circuit assignment calculation is performed to obtain the witness data set. If the random challenge value of the witness data set satisfies the polynomial constraint, then a hash compression operation is performed to obtain hash digest information; A non-interactive encapsulation process is performed on the hash digest information and the public reference string to generate a proof of the computation process.

6. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The step of performing hash extraction processing on the certificate to obtain the certificate hash value includes: The calculation process proves that the voucher is parsed using a syntax tree to obtain the voucher's structured fields; The structured fields of the voucher are concatenated according to the pre-acquired serialization rules to obtain the voucher byte sequence; If the length of the voucher byte sequence does not reach the preset group length threshold, then a bit-filling operation is performed on the voucher byte sequence to obtain a standard data block; A nonlinear compression operation is performed on the standard data block to obtain an intermediate state matrix, and a feature truncation extraction process is performed on the intermediate state matrix to obtain the credential hash value.

7. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The evidence storage data package is constructed based on the credential hash value and the carbon emission equivalent value; If a block construction instruction is received, the evidence storage data packet is written into the distributed ledger to obtain the ledger record address, including: Perform a field mapping and encapsulation operation based on the credential hash value and the carbon emission equivalent value to obtain the initial credential storage data; Perform digital signature processing on the initial evidence storage data to obtain the evidence storage data packet; Sending the evidence storage data packet to the distributed nodes triggers the consensus verification logic, and the node verification status is obtained; If the node verification status is valid, then the block construction instruction is obtained; The latest block height is extracted according to the block construction instruction, and the evidence storage data packet is combined and mapped according to the latest block height to obtain the data to be packaged. The Merkle root is obtained by iterative hash calculation of the data to be packaged, and the ledger state tree is updated according to the Merkle root to obtain the block header structure; The evidence storage data packet is written into the distributed ledger according to the block header structure to obtain the storage index value, and the storage index value is subjected to encoding conversion processing to obtain the ledger record address.

8. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, The step of extracting the corresponding proof of the calculation process according to the verification request includes: The verification request is deserialized and parsed to obtain the request payload data; Extract the ledger record address and target hash value based on the request payload data, and perform routing addressing based on the ledger record address to obtain the target block location information; A set of candidate transaction records is obtained by backtracking and scanning based on the target block location information; The target transaction record is obtained by performing feature matching processing on the candidate transaction record set according to the target hash value, and the calculation process proof certificate is extracted from the target transaction record.

9. The blockchain-based carbon emission monitoring method according to claim 1, characterized in that, If the calculation process proves that the credential meets the pre-acquired verification rules, then an untampered determination result is generated. If the calculation process proves that the credential does not meet the verification rules, an abnormal tampering determination result is generated, including: The computation process is used to perform structured parsing on the proof credentials to extract the proof data segment and the verification key reference segment; The verification key is obtained from the verification key reference segment, and the zero-knowledge proof verification operation is performed on the proof data segment using the verification key to obtain the verification output result. If the verification output result is equal to the preset verification pass benchmark value, then an untampered judgment result is generated; If the verification output result is not equal to the verification pass benchmark value, an abnormal tampering judgment result is generated.

10. A blockchain-based carbon emission monitoring system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the blockchain-based carbon emission monitoring method according to any one of claims 1 to 9.

Images