A blockchain-based carbon emission factor calculation verification method

Abstract

This invention discloses a blockchain-based carbon emission factor calculation and verification method, specifically relating to the fields of carbon emission accounting and blockchain-based trusted measurement technology. It addresses the problems of existing carbon emission factor calculation processes relying on decentralized systems and manual aggregation, inconsistent public disclosure standards, and a lack of traceable evidence chains, making it difficult for regulatory agencies and third parties to independently recalculate and reliably verify the factor results submitted by enterprises. By using a carbon emission factor calculation template as the core at the enterprise node side, and uniformly configuring device scope, statistical periods, and data preprocessing rules, a summary identifier is generated level by level from dimensional data summaries and calculation evidence chain fingerprints. The calculation voucher is written into the consortium blockchain, and the verification node recalculates the verification fingerprint based on the same template fingerprint and data slices, registering the verification results. This forms an integrated evidence closed loop of factor calculation, recalculation verification, and factor selection, solving the problems of opaque factor sources, difficulty in cross-entity recalculation, and lack of credible evidence.

Description

Technical Field

[0001] This invention relates to the field of carbon emission accounting and blockchain-based trusted measurement technology, specifically a blockchain-based method for calculating and verifying carbon emission factors. Background Technology

[0002] Currently, carbon emission accounting at coal-fired power plants is largely based on IPCC guidelines and national or industry standards. These systems, including on-site energy consumption monitoring platforms, production management systems, belt scale metering systems, electricity metering devices, and laboratory management systems, are used by the companies themselves to build emission factor calculation models. In practice, factor calculations often rely on Excel spreadsheets or scripts embedded in the carbon accounting system. Data sources, preprocessing rules, and calculation formulas are scattered across different files or system configurations. Information such as template versions, applicable equipment scope, and fuel categories lacks unified management and explicit labeling, leading to inconsistencies in the same unit's calculations across different statistical periods and under different personnel operations. For critical preprocessing steps such as filling in missing data, outlier removal, and operating condition screening, procedures are typically performed based on empirical rules or unwritten agreements, lacking standardized and traceable records.

[0003] With increasing demands for carbon trading and environmental regulations, regulatory agencies and third-party institutions need to conduct random checks and verifications of the results reported by enterprises regarding coal combustion factors and plant power consumption factors. Current practices largely rely on reports, screenshots, or partial raw data provided by enterprises. Regulators attempt recalculations based on written explanations and limited samples, making it difficult to fully reconstruct the calculation templates, data filtering rules, and step-by-step consolidation processes actually used by enterprises within their systems. Some carbon asset management or blockchain applications have attempted to write emissions, quotas, and trading records to a consortium blockchain to improve data immutability. However, these typically only record the final emissions or trading results on the blockchain, lacking a systematic design for the template configuration, dimensional data summaries, calculation step records, and their correspondence with on-chain vouchers during the emission factor formation process. This makes it difficult for on-chain records to support fine-grained recalculation and verification.

[0004] In summary, existing technologies generally suffer from the following core problem: a lack of unified template management and a recalculated, verifiable, and traceable chain of evidence mechanism for calculating carbon emission factors for coal-fired power units. This makes it impossible to ensure that, throughout the entire process of "template configuration—data processing—factor calculation—result upload—slicing verification—factor selection," enterprise nodes, verification nodes, and regulatory agencies can form a consistent calculation path and verifiable results for the same set of activity data under the same statistical period, the same device scope, and the same template version. Even if the regulatory side obtains the factor values ​​and some original data reported by enterprises, it is difficult to objectively and consistently reconstruct and compare the formation process of emission factors across systems, time periods, and entities. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a blockchain-based method for calculating and verifying carbon emission factors, thereby resolving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based method for calculating and verifying carbon emission factors, comprising:

[0007] S1. Configure the carbon emission factor calculation template, limit the input dimensions, preprocessing rules and model calling order, calculate the template fingerprint and register the template identifier and template fingerprint on the blockchain;

[0008] S2. Extract raw data from energy consumption and production data sources according to template identifiers, calculate statistical features according to input dimensions, and generate summary identifiers based on summary operation methods to form a dimensional data summary;

[0009] S3. Start the computing session in the runtime environment corresponding to the template fingerprint, complete the data processing and model reasoning in the order of the template, record the step information and result summary in the key steps, and generate the computing evidence chain fingerprint by chain hashing.

[0010] S4. Based on the calculation results, assemble a calculation certificate containing template identifier, dimensional data summary, calculation evidence chain fingerprint and factor values, submit it through the verification contract and write it to the blockchain;

[0011] S5. The verification node reads the computation certificate from the blockchain, requests the enterprise node to return a data slice with path proof according to the dimensional data digest, and calculates the data slice locally according to the template order and generates a verification fingerprint.

[0012] S6. Compare the verification fingerprint with the computational evidence chain fingerprint, and write the verification conclusion into the on-chain record associated with the computational certificate through the verification contract, so that the subsequent carbon accounting system can select factors based on the verification status.

[0013] Furthermore, S1 includes:

[0014] The carbon accounting system establishes a carbon emission factor calculation template, limiting the scope of equipment, the range of statistical periods, and the range of fuel categories;

[0015] Pre-configure rules for filling missing measurement segments, tolerance ranges, and rules for eliminating periods of unstable processes;

[0016] The template fields and rule parameters are encoded according to a preset field order to generate a template fingerprint.

[0017] Furthermore, the enterprise node generates a template identifier based on the device code, factor category, and template version number, and uses the template identifier as the idempotent key for the template registration request;

[0018] By interacting with the consortium blockchain rules component, template identifiers, template fingerprints, and applicable scope information are written into the consortium blockchain ledger state, and historical template records are retained in read-only mode to achieve template version locking.

[0019] Furthermore, S2 includes:

[0020] Enterprise nodes retrieve raw records from the energy consumption monitoring platform, metering devices, and management system based on template identifiers;

[0021] Unify the units of measurement according to the device range and statistical period and align the time labels; set the tolerance range according to the verification results and eliminate records that exceed the limits; fill the measurement gaps according to the missing measurement segment filling rules and replace the missing test results according to the substitution rules.

[0022] Statistical entities are obtained by grouping them according to time range and input dimension, statistical features are calculated, summary identifiers are generated under fixed sorting rules, and dimensionalized data summaries of each input dimension are stored in the evidence library in read-only mode.

[0023] Furthermore, S3 includes:

[0024] In the operating environment, the enterprise node constructs an idempotent key based on the statistical period identifier, template identifier, and device range. When no existing session record is found, it generates a session serial number and reads the dimensional data summary corresponding to the idempotent key from the evidence library.

[0025] According to the template merging rules, statistical features are merged sequentially in the work group dimension, date dimension, and fuel batch dimension to calculate the boiler fuel combustion factor;

[0026] When each key action is completed, step information containing a set of step sequence numbers and rule version numbers is generated. The link summary identifier is updated based on the step information to obtain the computational evidence chain fingerprint. The computational evidence chain fingerprint, template fingerprint, summary identifier of dimensional data summary, and factor values ​​are written into the evidence chain storage area.

[0027] Furthermore, S4 includes:

[0028] After the computation session ends, the enterprise node assembles the computation certificate using the template identifier, template fingerprint, statistical period identifier, device range description, factor category identifier, factor value, dimensional data summary of each input dimension, and computation evidence chain fingerprint.

[0029] Generate a calculation voucher identifier based on the session serial number and statistical period identifier;

[0030] Submit the computation credential and its identifier to the consortium blockchain;

[0031] After verifying the consistency of template registration records, template fingerprints, and the correspondence between statistical period identifiers and device range descriptions, the consortium blockchain rules component writes the calculation voucher into the on-chain ledger and generates an on-chain voucher number.

[0032] Furthermore, S5 includes:

[0033] The verification node reads the on-chain certificate record corresponding to the on-chain certificate number from the consortium chain based on the on-chain certificate number, and reads the template identifier, template fingerprint, statistical period identifier, device range description, dimensional data summary of each input dimension, and monthly factor value recorded in the on-chain certificate record;

[0034] The verification node generates a data slice request that includes an on-chain credential number, template identifier, statistical period identifier, dimension filtering conditions, and sample quantity requirements. It assigns a request serial number to the data slice request and binds it to the on-chain credential number as an idempotent key, and sends it to the enterprise node through an encrypted communication channel.

[0035] Furthermore, after receiving the data slicing request, the enterprise node retrieves detailed records in the evidence database based on the template identifier and statistical period identifier, and divides and sorts the sampling layers according to time period, work group identifier and working condition label.

[0036] Enterprise nodes use the request serial number as a seed to call a pseudo-random number generation function to select samples in each sampling layer to form a sample set, and construct a path proof that includes the sample time range, work group identifier, working condition label, total coal input, total power generation, and global sequence number;

[0037] A path digest is generated based on the path proof, and the sample set, path proof, and path digest are encapsulated into a data slice response message and sent to the verification node.

[0038] Furthermore, S6 includes:

[0039] After obtaining the verification fingerprint, the verification node reads the full-month factor value based on the on-chain certificate number, and generates a conclusion type label based on the relative error between the slice factor value and the full-month factor value and the verification fingerprint.

[0040] The verification results, including the on-chain credential number, data slice range description, verification fingerprint, and conclusion type marker, are written into the consortium blockchain. The carbon accounting system then determines the selection status of the on-chain factor based on the verification results of qualified regulatory nodes within the factor's applicable period.

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

[0042] 1. By using a carbon emission factor calculation template as the core on the enterprise node side, uniformly configuring the device scope, statistical period, and data preprocessing rules, and generating summary identifiers for dimensional data summaries, calculation session step information, and calculation evidence chain fingerprints at each level, the summary identifiers are written into the consortium blockchain jointly maintained by multiple parties in the form of calculation vouchers. Then, the verification node recalculates the verification fingerprint based on the same template fingerprint and data slices, and associates the verification results with the calculation vouchers for evidence storage. This achieves the goal of connecting the carbon emission factor calculation process, recalculation verification process, and factor selection decision into a traceable, verifiable, and replayable evidence closed loop, effectively solving the problems of opaque carbon emission factor sources, difficulty in independent cross-entity recalculation verification, and lack of credible evidence in existing technologies.

[0043] 2. By pre-fixing data quality control rules such as missing measurement filling, tolerance verification, working condition elimination, and test result substitution in the calculation template, dimensional data summaries are generated according to the input dimensions at the enterprise node side. Data slices with path proofs are constructed based on stratified sampling and deterministic pseudo-random selection. At the verification node side, the data slices are merged and calculated according to the same template order to generate verification fingerprints. Combined with quality level and error threshold, a positive, reserved, or negative conclusion is automatically given. This achieves the effect of balancing sample representativeness and computational load under the constraint of limited verification resources, systematically improving the data reliability and anomaly visibility of factor results, and significantly reducing the workload of manual line-by-line verification. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the process of a blockchain-based carbon emission factor calculation and verification method according to the present invention. Detailed Implementation

[0045] 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.

[0046] Example: Figure 1 A flowchart illustrating a blockchain-based carbon emission factor calculation and verification method according to the present invention is provided. The blockchain-based carbon emission factor calculation and verification method includes:

[0047] S1. Configure the carbon emission factor calculation template, limit the input dimensions, preprocessing rules and model calling order, calculate the template fingerprint and register the template identifier and template fingerprint on the blockchain. The specific implementation is as follows:

[0048] In a power plant primarily composed of coal-fired units, the personnel responsible for emissions management first establish carbon emission factor calculation templates within the plant's carbon accounting system. These templates are a set of fixed configurations that define the calculation rules for a specific type of carbon emission factor. They are used to define how to obtain emission-related quantities from on-site metering and production records within a statistical period, how to organize these quantities, and how to convert the organized quantities into factor values. Carbon emission factors are coefficients used to characterize the emissions corresponding to a unit of activity, such as the emissions corresponding to a unit of electricity generation or the emissions corresponding to a unit of fuel combustion.

[0049] In this embodiment, the carbon emission factor calculation templates are preferably established for boiler fuel combustion factors and plant power factors respectively. When creating each template, it is necessary to specify the applicable device range, statistical period range, and fuel category range. The device range is used to indicate which units, boilers, or production lines the template is applied to. The statistical period range is used to indicate whether a day, ten-day period, or natural month is a calculation window. In this embodiment, in order to adapt to the regular production and electricity meter reading arrangements, the natural month is preferred as the statistical period, and the period from the first day of the month to the last day of the month is a continuous observation period. The fuel category range is used to constrain which fuel types the template is applicable to, such as bituminous coal, lean coal, or blended coal, so as to ensure that the differences in the physical properties of different fuels are not mixed under the same template.

[0050] During the configuration process, the carbon accounting system lists the names, units, and recording rhythms of the quantities needed for each template. For example, the unit of fuel consumption is unified as tons, the unit of power generation and plant power consumption is unified as kilowatt-hours, and the test results are expressed as mass percentages. At the same time, it stipulates how these quantities should be aligned in chronological order within the same calendar month. The system maps team records, daily reports, and online metering records to the observation window of the calendar month. It can be set to use timestamps as the basis, classify all records by hour or team shift into the corresponding date, and then use the calendar month label as the summary key.

[0051] To avoid the unreasonable impact of gaps or anomalies in on-site data on factor calculations, the template needs to pre-define rules for filling missing measurement segments, tolerance ranges, and removing unstable process periods. The missing measurement segment filling rule specifies whether to substitute the average value of preceding and following periods when no record is generated at a certain measurement point for a short period. The upper limit of the allowed discontinuous time for substitution can be set to several minutes or several hours, with specific values ​​provided during template configuration. The tolerance range is used to provide the allowable upper and lower deviation intervals based on the calibration results of the metering device. When a record significantly exceeds this interval, it is considered an anomaly and is removed. The unstable process period removal rule identifies whether records during maintenance, start-up, shutdown, or trial operation are included in the current statistical scope. In this embodiment, the unit's grid connection status and operating mode commands are preferably used as the operating condition boundary. When the unit is in trial operation or maintenance status, the corresponding records are not included in the factor calculation.

[0052] After clarifying the data sources and processing rules, the carbon accounting system also needs to stipulate a fixed order of merging before calculation in the template. Merging here means first aggregating scattered records into a set of values ​​within the statistical period by work group, day, or fuel batch, and then obtaining the final factor value based on these sets. This approach of summarizing activity before calculating coefficients is a conventional method in the field, which can reduce the impact of single-point fluctuations on the results and facilitate manual verification and automatic comparison of each intermediate step.

[0053] After the template is configured, the carbon accounting system arranges and combines the template field content and rule parameters in a preset order according to unified rules locally, generating a summary value to uniquely identify the template content. In this embodiment, the summary value is called the template fingerprint. The template fingerprint has the characteristic of one-to-one correspondence with the template content. When the template content is modified, its fingerprint also changes, so that subsequent nodes can quickly determine whether the template has been modified. Preferably, the content of each field of the template can be concatenated into a text according to a fixed field order and separation method, and then a collision-resistant summary operation method is used to generate the template fingerprint, so that the template fingerprint formed according to the same rules at different nodes and at different times is consistent, thereby ensuring the determinism of template comparison.

[0054] At the same time, the system also forms a template identifier by combining the device code, factor category and template version number. The template identifier is used to reference the template within the enterprise and on the consortium blockchain. It is a unique code within the system. In order to ensure that duplicate registrations will not generate multiple logically equivalent template records on the chain, the template identifier acts as an idempotent key in this embodiment. That is, when the same template identifier corresponds to the same template version and registration requests are submitted multiple times, only one valid registration record is ultimately retained on the chain.

[0055] After generating the template fingerprint and template identifier, the enterprise node initiates a template registration interaction through a pre-configured blockchain interface. The enterprise node is a server or service process deployed in the plant's computer room or cloud virtual private network, capable of accessing the plant's carbon accounting system and consortium blockchain nodes. The template registration interaction content includes at least the template identifier, template fingerprint, a description of the applicable device range and statistical period range, and the template version number. The enterprise node encapsulates this content into a registration request and sends it to the rule component in the consortium blockchain. The consortium blockchain is a distributed ledger system maintained jointly by multiple parties. In this embodiment, the consortium blockchain is jointly operated by regulatory agencies, power generation companies, and third-party verification agencies. The rule component in the consortium blockchain is responsible for verifying the format of business requests. The program, which consists of a set of fields and logic, first checks whether the template identifier already exists based on the existing template records on the chain after receiving a template registration request. If it does not exist, it checks whether the template fingerprint format conforms to the pre-agreed encoding rules. Only when the template identifier is not duplicated and the template fingerprint format is correct will a new template registration record be created on the chain. The template identifier, template fingerprint, and applicable scope information are written into the immutable ledger state and marked as available. Registered template records are saved in read-only mode and do not support direct modification of template content. Any subsequent content adjustments are achieved by increasing the template version number and registering a new template identifier, thereby forming a clear version locking relationship. The original version template records are still retained on the chain for tracing the historical factor calculation process.

[0056] When a template identifier already exists and the template fingerprint recorded on the chain matches the template fingerprint in the request, the rules component treats the request as a duplicate registration attempt for the same template. In this case, no new record is created; only the registration time or registration source information is updated to reflect the fact that the template has been repeatedly confirmed at different times. When a template identifier already exists but the template fingerprint does not match the on-chain record, the rules component determines that a template conflict has occurred and returns a prompt containing the reason for the conflict. Carbon management personnel manually check whether the template content and version number match. If necessary, the template content is adjusted in the carbon accounting system and the template version number is increased before regenerating the template fingerprint and template identifier. Then, the registration is repeated according to the above process.

[0057] The entire template registration interaction process is protected by a communication protocol with handshake authentication and encrypted transmission capabilities to prevent template content from being stolen or tampered with during transmission. Preferably, enterprise nodes and consortium blockchain nodes can be configured to interact through a communication channel based on transport layer encryption and two-way certificate authentication. Without limiting the specific implementation method, it is ensured that both parties complete identity verification and encrypt subsequent transmitted content when establishing a connection. At the same time, enterprise nodes adhere to preset time limits and retry counts when initiating requests. For example, if a single registration request is not confirmed within a certain number of seconds, it can be configured to retry a certain number of times at fixed intervals. After the retry count is exceeded, the registration request is marked as failed and the operation and maintenance personnel are prompted to check the network and consortium blockchain status to avoid prolonged system blockage due to communication failures.

[0058] The carbon accounting system and enterprise nodes are preferably deployed in the factory's data center, but can also be deployed in a cloud platform virtual machine or container environment that meets security requirements. As long as they can access the consortium blockchain nodes through a secure network connection, they can achieve the same template registration capability and scope of application as described in this embodiment. The underlying consortium blockchain can use an existing consortium ledger platform, as long as it can provide the ability for multiple parties to jointly maintain the ledger, save template registration records, and query by template identifier and template version number. There are no restrictions on its internal consensus method and data storage structure. From an engineering implementation perspective, those skilled in the art can implement the rule component function on the basis of existing consortium blockchain software through configuration and secondary development.

[0059] For example, among multiple coal-fired power plants in the same group, the carbon emission factor calculation templates of different plants can be uniformly registered and referenced across plants by setting up their own enterprise nodes and a shared consortium blockchain network in each plant. This allows for centralized supervision of template versions and scope of application while maintaining the flexibility of configuration based on the process differences of each plant.

[0060] Preferably, in a typical coal-fired power plant, the boiler fuel combustion factor template for the main generating units can be set to cover two main generating units, with a statistical period of calendar months and a fuel category of bituminous coal and blended coal. The initial template version number is set to No. 1. After the template fingerprint is generated for the first time, it is written into the consortium blockchain through the enterprise node. If it is necessary to adjust the statistical period or change the testing method according to the updated emission guidelines, the carbon management personnel will update the template content, generate a new fingerprint, and upgrade the template version number to No. 2 in the carbon accounting system. The registration of the new version template is completed through the aforementioned template registration interaction. The old version template continues to be retained on the blockchain for tracing the historical factor calculation process. This allows those skilled in the art to reproduce the same template configuration and registration mechanism in any coal-fired power plant with similar measurement conditions and information foundation after referring to the template configuration, on-site measurement standards, and registration process.

[0061] S2. Extract raw data from energy consumption and production data sources according to template identifiers, calculate statistical features according to input dimensions, and generate summary identifiers based on summary operation methods to form dimensional data summaries. The specific implementation is as follows:

[0062] At the end of each calendar month, the aforementioned enterprise nodes initiate a processing action for that calendar month in the carbon accounting system. The calendar month statistical period refers to the continuous time period from 00:00 on the first day of the month to 24:00 on the last day of the month, corresponding to a completed production settlement cycle. Enterprise nodes retrieve consumption and output records from the plant-level energy consumption monitoring platform, belt scale system, electricity metering device, production management system, and laboratory management system according to the template identifiers already registered in the consortium blockchain. The plant-level energy consumption monitoring platform is an information system that centrally stores the energy consumption and operating status of each metering point on the boiler, steam turbine, electric auxiliary equipment, and public system at fixed time intervals. The belt scale system is a metering system used to record the instantaneous flow and cumulative weight of coal on the conveyor belt entering the furnace. The electricity metering device is an electricity meter or online metering facility installed on the unit's outgoing line and the plant's power circuit. The production management system is used to record the unit's power generation, plant power consumption, load plan, and operating mode. The laboratory management system is used to record the test results of representative samples of coal entering the furnace, such as carbon content, moisture content, and ash content. Each system assigns a time tag to each record.

[0063] Enterprise nodes filter records related to the current template based on the device scope, statistical period range, and fuel category range agreed in the template. Records of coal input into the furnace are set in tons, records of power generation and plant power consumption are set in kilowatt-hours, and test results are set in mass percentage. By aligning the time tags of different systems, records from different systems within the same natural month can be associated through time tags and device identifiers. The time tag alignment can preferably be set to hour or shift as the alignment granularity, and multiple detailed records within the same alignment granularity can be grouped into the same time period.

[0064] In the aligned record set, for the range boundary of each measuring device, the enterprise node determines the tolerance range based on the maximum and minimum allowable values ​​given in the calibration certificate and equipment technical specifications. When the reading of a record exceeds the tolerance range, it is identified as an obviously abnormal record and is removed, and the reason and quantity of removal are recorded locally.

[0065] For time gaps caused by short-term lack of recording by the metering device, the enterprise node determines whether to allow filling based on the maximum continuous gap duration pre-agreed in the template. When the duration of a gap does not exceed the maximum continuous gap duration, the average value of the same metering point in the preceding and following time periods is preferably used as a substitute value to fill the gap, and a mark is saved in the evidence database to indicate that the time period is the filling time period. When the gap duration exceeds the upper limit, it is not filled and is regarded as missing data by subsequent links.

[0066] For missing coal sample test results in the test management system, the enterprise node selects a replacement value from the most recent valid sample results of the same fuel type and the same supply channel according to the replacement rules agreed upon in the template, or adopts the default reference value given in the regulatory guidelines. The replacement rules are locked when the template is configured. When performing the replacement, the enterprise node must record whether the replacement uses the "most recent valid sample" or the "guideline default value" so that the replacement source can be identified during subsequent recalculation and verification.

[0067] Based on the records after anomaly removal, missing test filling, and test result substitution, the enterprise node aggregates the records according to the input dimensions agreed in the template, based on fuel batch, meter number, production line code, work group, or other process-related dimensions. The aggregation process follows the order of grouping by time range first and then by dimension. That is, records belonging to the same unit within the same calendar month are first grouped by day or work group, and then further subdivided within each group by fuel batch, meter number, or production line code, so that each group of records corresponds to a clear statistical entity.

[0068] For each statistical entity, the enterprise node calculates statistical characteristics such as the number of records, the sum of values, the average, the minimum, and the maximum. It also calculates more detailed statistics such as weighted averages or quantiles as needed. These statistical characteristics constitute the entity's statistical characteristic set. Simultaneously, to maintain the ability to constrain subsequent verification without disclosing all detailed records, the enterprise node arranges the records of the statistical entity throughout the entire calendar month in a fixed sorting method. This sorting method is preferably set to first sort by statistical period identifier, then by device identifier, then by time tag, and finally by record source system. After obtaining the ordered record sequence, the key fields of the records are concatenated into text in an agreed-upon order and fed into a set of deterministic summary calculation methods to form a summary identifier. The length of this summary identifier is set to a fixed length during the template configuration stage to ensure that different nodes generate identical summary identifiers when applying the same rules to the same record set.

[0069] For a given input dimension, the set of statistical features of all statistical entities within the dimension and their corresponding summary identifiers together constitute the dimension's dimensional data summary. The dimensional data summary reflects the magnitude of the dimension within the statistical period and provides a consistency credential that can be checked by subsequent verification nodes through the summary identifier. The enterprise node stores the dimensional data summary of each dimension, along with the corresponding statistical period identifier, template identifier, and device scope description, in a read-only manner in the evidence repository within the enterprise node. The evidence repository is a persistent storage area set up by the enterprise node to support factor calculation verification. Once a record is written, it cannot be modified by ordinary business operations; records can only be appended when a new version is added or a mark is revoked.

[0070] If, at the end of a calendar month, records corresponding to a certain statistical period and template identifier need to be reorganized due to late records or data corrections, the enterprise node does not directly overwrite the original dimensional data summary. Instead, it re-executes the alignment, elimination, filling, and aggregation processes based on the latest complete records to generate a new set of dimensional data summaries. This new set of summaries is assigned a version number higher than the original summary, while the old version summary is retained in the evidence library and marked as a historical version. This ensures that the dimensional data summaries under the same calendar month and template identifier have clear version boundaries on the timeline, allowing for accurate matching to the summary version used at the time of subsequent factor calculation.

[0071] Under typical operating conditions at this plant, the number of records generated for the coal input dimension within a single calendar month can reach hundreds or even more, with a cumulative consumption of hundreds of thousands of tons. Enterprise nodes group, aggregate, and generate statistical features and summary identifiers for these records according to the aforementioned rules, resulting in a fixed-length summary identifier for a dimensional data summary. This summary identifier is uniquely determined when enterprise nodes and verification nodes use consistent sorting methods and summary operation rules, facilitating rapid determination of record set consistency during subsequent cross-node comparisons and recalculations. Based on the aforementioned configuration range, data source, alignment, and organization rules, those skilled in the art can achieve the same data extraction and dimensional data summary generation process in coal-fired power plants with similar metering conditions, ensuring consistency in the dimensional data summaries obtained multiple times under the same statistical period and template identifier conditions. This provides a stable data foundation for subsequent carbon emission factor calculations and on-chain verification.

[0072] Preferably, in a typical coal-fired power plant with a relatively large installed capacity and production load, the statistical cycle can be set to 30 or 31 days per month. After aligning the coal input records by hour, a very small number of abnormal records exceeding the maximum range of the belt scale are removed. For metering gaps with a cumulative duration of no more than one hour, the average value of the hour before and after is used to fill in the gaps. For two weekly inspection records with missing test results, the valid test results of adjacent weeks are used to replace them. Finally, at the fuel batch dimension, the statistical characteristics of each batch are calculated, with about ten records, a total amount of several thousand tons, and an average single batch mass of several hundred tons. A summary identifier of fixed length is generated. When the verification node checks in the future, as long as it confirms that the summary identifier is consistent with the summary identifier registered on the chain, it can confirm that both parties are based on the same set of coal input data without obtaining all detailed records.

[0073] S3. Start the computation session in the runtime environment corresponding to the template fingerprint, complete data processing and model inference according to the template sequence, record step information and result summaries at key steps, and generate a computational evidence chain fingerprint using chain hashing. The specific implementation is as follows:

[0074] After the dimensional data summary is stabilized, the aforementioned enterprise node initiates a calculation session for the boiler fuel combustion factor for the current month in the operating environment corresponding to the template fingerprint. The operating environment is a set of programs and parameters configured to execute a certain template, including the formula parameters required for fuel combustion factor calculation, the set of rule version numbers, and the summary operation module used to generate the evidence chain. These contents are locked into a fixed combination through the template fingerprint and template version number to avoid misunderstandings between different sessions or different nodes.

[0075] A computational session refers to the process of calculating boiler fuel combustion factors and forming a chain of evidence within a single natural month statistical period, targeting a specific boiler unit and template identifier, starting from dimensional data summaries and their associated detailed records. When an enterprise node initiates a computational session, it uses the combination of the statistical period identifier, template identifier, and unit range as an idempotent key. It then searches the session management module within the enterprise node to see if a session record with the same combination already exists. If it does not exist, a new session serial number is generated and the combination is bound to the session serial number. If it already exists and its status is incomplete, the session serial number is used to continue subsequent steps. This ensures that no two different computational chains exist in parallel within the same natural month, the same template, and the same unit range.

[0076] After obtaining the session serial number, the runtime environment references the dimensional data summary corresponding to the current session from the evidence base based on the idempotent key, as well as the associated detailed records that can be accessed if necessary. The summary records and detailed records in the evidence base are both open to the runtime environment in read-only mode and are not allowed to be modified or overwritten during session execution, so as to ensure that the same results can be obtained with the same input conditions during subsequent replays.

[0077] In the specific process of factor calculation, the operating environment first merges the statistical features of each dimension recorded in the dimensional data summary according to the merging rules in the template. Preferably, it first merges by work group within the natural month, summarizing the amount of coal fed into the furnace and the amount of electricity generated by the same work group in that month to obtain the work group-level activity volume. Then, it merges by date within the work group, merging the activity volume of each shift or each operating segment within the same date. Subsequently, it merges by fuel batch within the date range, aggregating the amount of coal fed into the furnace, the amount of electricity generated, and their corresponding test results and operating condition labels belonging to the same fuel batch into a group. The operating condition label here is a discrete identifier used to mark the operating status of the batch of coal. It can at least distinguish the operating condition types such as stable load operation, rising and falling load operation, and start-up and shutdown process, which are used to identify and process unstable operating conditions in subsequent calculations.

[0078] After each fuel batch aggregation group is formed, the operating environment calculates intermediate quantities according to the preset calculation rules in the template. For intermediate quantities related to emissions, it can be set to obtain the estimated emission value of the batch by multiplying the coal feed amount, effective calorific value, carbon content and oxidation rate of the fuel batch. Then, the emission factor contribution of the batch to the unit power generation is calculated according to the power generation of the batch. For example, for a certain batch, the mass of carbon contained in the combustible components of the coal in the batch can be calculated first based on the carbon content, ash content and moisture content provided by the analysis management system. Then, the theoretical emission amount is obtained based on the recognized carbon conversion coefficient and oxidation rate. Finally, the combustion factor contribution of the batch is obtained by dividing by the power generation of the batch.

[0079] After the calculations for the operating environment at the three levels of work group, date, and fuel batch are completed, the factor contributions of all batches are weighted and summarized according to the power generation. Preferably, the weight of the factor contributions of each batch is the proportion of the power generation of each batch to the total power generation of the natural month, and the weighted average of the factor contributions of each batch is used to obtain the boiler fuel combustion factor for that natural month. This logic of "weighting the emissions according to the activity amount and then dividing by the total activity amount" is consistent with the common method used in the field for calculating emissions factors. However, in this embodiment, each step is merged and the calculation process is fixed through template configuration and evidence chain recording, which is convenient for recalculation and verification.

[0080] To create a replayable process record for each of the above steps, the operating environment generates a step information record when completing key actions such as shift merging, date merging, fuel batch aggregation, batch emission estimation, batch factor contribution calculation, and monthly factor weighted summarization. The step information record includes at least the sequence number of the action predefined in the template, the dimension labels involved in the action (e.g., shift level, date level, or fuel batch level), the set of rule version numbers involved in the action (including template version number, missing data filling rule version number, operating condition classification rule version number, and emission estimation rule version number used, etc.), and a numerical description of the current intermediate quantity status. The numerical description of the intermediate quantity status may include the number of records at the current merging level, the total amount of coal fed into the furnace, the total amount of power generation, the total amount of emission estimation, and the preliminary calculated factor contribution range or mean, etc., which are used to determine whether the intermediate results are within a reasonable range without expanding all the original data.

[0081] After generating each step's information, the runtime environment uses pre-defined encoding rules to concatenate the step sequence number, dimension label, rule version number set, and intermediate state numerical description into a text segment in a fixed field order. Then, it generates a step summary identifier for that step using a deterministic summarization method. The summarization method is preferably set to a summarization method with deterministic, collision-resistant, and fixed output length characteristics. For example, the above text can be encoded into a byte sequence according to a unified character set and then input into the summarization function. Without limiting the specific algorithm name, it can ensure that the same text receives the same summary output at different times and different nodes.

[0082] To construct the evidence chain for the entire session, the runtime environment concatenates the encoded representation of the session sequence number, the previous link digest identifier, and the current step digest identifier in a fixed order each time a new step digest identifier is obtained. Then, it sends the concatenation to the same digest operation method to generate a new link digest identifier. At the start of the session, the previous link digest identifier can be initialized as an initial digest generated separately based on the session sequence number. In this way, starting from the first step information, each step information will participate in the update of the link digest once. After all the predetermined key actions are executed, the link digest identifier obtained by the last digest operation is the computational evidence chain fingerprint of this computation session.

[0083] After obtaining the boiler fuel combustion factor value for the current natural month and calculating the corresponding computational evidence chain fingerprint, the operating environment writes this fingerprint, along with the template fingerprint used in this session, the summary identifiers of the dimensionalized data summaries of each major input dimension, and the final factor value, into the evidence chain storage area within the enterprise node. The evidence chain storage area saves these summary information using the session serial number as the index key. The record format is read-only and cannot be modified. If it is necessary to correct errors or update, it is appended through a new session or new version record, while retaining the original record for traceability. At the same time, all step information is stored as detailed process records in the enterprise node log area, indexed by the session serial number and step sequence number. The log area is also read-only and can be queried as needed during subsequent verification.

[0084] When the runtime environment fails to complete a critical action due to incomplete data (e.g., missing necessary test results and the template substitution rule does not allow continuation) or inconsistent rule versions (e.g., the template version number does not match the evidence library record), a step information explaining the reason for the failure to complete the action can be appended to the log area. The session status is recorded as incomplete, and the final evidence chain fingerprint is not calculated temporarily. After the data or configuration issues are resolved, the enterprise node restarts the session in the same runtime environment, using the original session serial number and re-executing the aforementioned merging and calculation steps until all critical actions are successfully completed. Only then is the final calculated evidence chain fingerprint generated and the evidence chain storage area record updated, thus ensuring that for the same statistical period, the same template identifier, and the same device range, only one valid evidence chain fingerprint exists in the final completed state.

[0085] In a typical coal-fired unit with a relatively high installed capacity and load level, the monthly coal input after consolidation can reach hundreds of thousands of tons, and the power generation can reach hundreds of millions of kilowatt-hours. The operating environment calculates the emissions and factor contributions of each shift, date, and fuel batch according to the consolidation and calculation rules configured in the template. Then, the monthly boiler fuel combustion factor value is obtained by weighting and summarizing according to the power generation. This factor value can preferably be within the range of several kilograms of carbon dioxide equivalent per kilowatt-hour. When the entire calculation session is re-executed under the same template fingerprint, the same dimensional data summary, the same set of rule version numbers, and the same session serial number, the same calculation evidence chain fingerprint will be obtained according to the aforementioned coding and summary operation rules. This allows those skilled in the art, with the template configuration, dimensional data summary, and original detailed records, to reproduce the entire calculation process of the boiler fuel combustion factor on the same or other enterprise nodes by implementing the same operating environment and summary generation logic and obtain results consistent with the original session. This achieves verifiability and replayability of the carbon emission factor calculation process.

[0086] S4. Based on the calculation results, assemble a calculation certificate containing template identifiers, dimensional data summaries, calculation evidence chain fingerprints, and factor values. Submit the certificate through a verification contract and write it to the blockchain. The specific implementation is as follows:

[0087] Once the calculation session ends and the boiler fuel combustion factor value for a given natural month is obtained within the enterprise node, the enterprise node retrieves the record stored in the aforementioned evidence chain storage area, indexed by the session serial number. It then reads the template identifier, template fingerprint, statistical period identifier, device scope description, summary identifier of the dimensionalized data summary for each major input dimension, calculation evidence chain fingerprint, and monthly factor value corresponding to the session. Combined with the internal evaluation results generated during this calculation process, a quality level is determined.

[0088] The quality level reflects the reliability of the factor calculation in terms of data integrity, the proportion of substitute data, the coverage of operating conditions, and the consistency of rule configuration. Preferably, several quality level tiers can be defined during the template configuration stage, and specific judgment rules can be set for each tier. For example, the proportion of the number of original records used for calculation in the current month to the total number of records that should exist, the proportion of the number of batches using substitute test results to the total number of batches, the proportion of stable load operating conditions to the effective operating conditions within the statistical period, and whether there are any inconsistencies in rule versions or session interruptions and restarts during the calculation process. At the end of the calculation session, the operating environment compares the above indicators with preset thresholds. If the data integrity is greater than the preset first threshold, the substitution ratio is lower than the preset second threshold, the stable operating condition coverage ratio is higher than the preset third threshold, and no rule version conflict occurs, it is marked as a higher quality level. If some indicators do not meet the requirements of a higher level but are still within the allowable range, it is marked as a general quality level and recorded as an enumeration value in the field corresponding to the quality level.

[0089] After obtaining the above fields, the enterprise node organizes the template identifier, template fingerprint, statistical period identifier, device scope description, factor category identifier, factor value, calculation evidence chain fingerprint, summary identifier set of dimensional data summaries for each dimension, and quality level mark into a structured record according to the pre-designed field order. In this embodiment, the record is called the calculation voucher. Logically, the calculation voucher is a summary description of a factor calculation completed under a certain natural month, a certain template, and a certain device scope. It contains the key index information, calculation result information, and quality information necessary for subsequent verification.

[0090] To uniquely identify this computation credential within the consortium blockchain, enterprise nodes generate a computation credential identifier using a combination of session serial number and statistical period identifier. This identifier is maintained as a unique code within the enterprise node. In this embodiment, the identifier is used as an idempotent key at the credential level. That is, within the same enterprise node, the same combination of statistical period identifier and session serial number can only correspond to one computation credential record that can be submitted to the consortium blockchain. When multiple submissions are made, subsequent submissions should be identified as duplicate confirmations of the same computation credential rather than new credentials. In terms of encoding, the computation credential can preferably be represented by a structured message of key-value pairs. For example, each field can be represented as a pair of "field name + field value" and arranged in a predetermined order to form a text or binary sequence. This sequence can be compressed or encrypted as needed before being transmitted through the interface.

[0091] After the enterprise node completes the computation credential assembly, it submits the computation credential to the consortium blockchain through a pre-configured business interface with the consortium blockchain node. This interface can be implemented in a request-response mode, and preferably can use a communication channel based on transport layer encryption and supporting two-way certificate authentication. When establishing a connection, the enterprise node and the consortium blockchain node verify the validity of each other's certificates and the issuing authority to confirm the other party's identity. After completing the handshake, the computation credential message is transmitted through the encrypted channel.

[0092] To further ensure that the message has not been tampered with, enterprise nodes can also use their own key materials to generate a signature for the computation credential message locally and attach it to the message. When receiving the message, the consortium blockchain rules component verifies the validity of the signature based on the enterprise node's public key. If the signature verification fails, the computation credential will be rejected. At the business field level, the interface message must carry at least the following information: computation credential identifier, template identifier, template fingerprint, statistical period identifier, device range description, factor category identifier, factor value, computation evidence chain fingerprint, set of digest identifiers for dimensional data digests of each dimension, and quality level mark. It also carries the enterprise node identifier and message timestamp for the consortium blockchain to use for authentication and replay protection.

[0093] After receiving the computation credential message submitted by the enterprise node, the rules component on the consortium blockchain first determines whether the enterprise node is authorized to participate in writing the computation credential based on the node identifier and signature verification result. If the authentication fails, the message is directly rejected. After successful authentication, the message content is parsed and the corresponding template entry is retrieved from the template records registered on the chain according to the template identifier. If no template is found, it is considered that the template is not registered, and a prompt message containing the reason "template not registered" is constructed and returned to the enterprise node.

[0094] If a template record is found, the template fingerprint carried in the message is then strictly compared with the template fingerprint stored in the on-chain template record. Only when the two are completely identical is it considered that the template version used by the node is consistent with the on-chain registered version; otherwise, a "template version mismatch" message is returned, allowing enterprise nodes to adjust the template version or re-register the template based on the message.

[0095] If both the template identifier and the template fingerprint match, the rule component verifies the statistical period identifier and device scope description in the calculation voucher based on the applicable statistical period and device scope recorded in the template registration record. For example, if the template registration declares that the applicable statistical unit is a natural month and it is only applicable to two boilers, the corresponding calculation voucher's statistical period identifier must be a natural month and the device scope description can only include these two boilers. Otherwise, the rule component returns the prompt message "The statistical period or device scope is not within the applicable scope".

[0096] Once the above verifications are passed, the rule component queries the current on-chain state to see if a record with the same identifier already exists. The query can be performed by using the computational certificate identifier as the key to find the corresponding entry in the on-chain state database. If no corresponding entry is found, the rule component writes the computational certificate along with the generated on-chain certificate number into the consortium blockchain ledger. During the writing process, the computational certificate identifier is used as the primary key field, and the template identifier, template fingerprint, statistical period identifier, device range description, factor category identifier, factor value, computational evidence chain fingerprint, summary identifier set of dimensional data summaries for each dimension, quality level mark, enterprise node identifier, and receiving time are also stored. An on-chain certificate number is generated for this record. The on-chain certificate number can preferably adopt a format similar to the on-chain transaction number and is automatically assigned by the consortium blockchain underlying layer based on the current block height and transaction order.

[0097] If a query finds that a record with the same calculation credential identifier already exists, the rules component will compare the key fields carried in the message, such as template identifier, statistical period identifier, device range description, factor category identifier, and factor value, with the corresponding fields in the existing record on the chain. If all are the same, the submission will be regarded as a duplicate confirmation of the same credential. No new credential record will be added. Only the most recent receipt time in the record on the chain will be updated or a confirmation source mark will be added to reflect that the credential has been confirmed by the enterprise node again.

[0098] If any inconsistency exists in the key fields, the rules component will consider it a conflict of calculation credential identifier, will not write it to the on-chain ledger, and will return a prompt message to the enterprise node containing the reason for "conflict of calculation credential identifier and inconsistency of key fields", requiring the enterprise node to stop using the credential and check the differences between the local evidence chain and the previous submission.

[0099] After receiving the processing result returned by the consortium blockchain, if the enterprise node successfully obtains the on-chain credential number, it binds and records the on-chain credential number with the session serial number, statistical period identifier, and template identifier in the local credential management module, forming a mapping table. This allows the on-chain credential number to be located through the session serial number in subsequent regulatory verification or third-party recalculation requests. Alternatively, the on-chain credential number can be used to trace back to the computational evidence chain fingerprint and dimensional data digest in the local evidence chain storage area, enabling bidirectional comparison between on-chain records and local computation processes.

[0100] Regarding resource usage, when submitting computation credentials, enterprise nodes limit the pressure on consortium blockchain nodes by setting the maximum number of concurrent submissions and the maximum response time for a single request locally. For example, the number of credential submissions in the waiting confirmation state at any given time can be set to not exceed a preset number. When a submission does not receive confirmation within a preset time, it is retried several times using a fixed interval or exponential rollback. After the number of retryes is exceeded, the submission is marked as a failure and the reason for failure and time are recorded in the local log so that maintenance personnel can subsequently investigate the network or consortium blockchain node status.

[0101] In terms of security control, the transmission of all calculation credentials between enterprise nodes and consortium blockchain nodes is preferably carried through a communication channel with handshake authentication and encrypted transmission capabilities. Combined with node identity authentication and access control rules, only enterprise nodes running carbon emission factor business are allowed to submit and query calculation credentials related to their responsibilities. Unauthorized nodes are not allowed to arbitrarily read or write the content of the credentials. This ensures that the evidence chain is verifiable and queryable among multiple parties while taking into account the confidentiality of enterprise data and business isolation. In a typical scenario of a coal-fired power plant, after the end of each calendar month, enterprise nodes can assemble several calculation credentials for the main boiler and multiple factor categories, and send them to the consortium blockchain item by item according to the above concurrency control and retry strategy to obtain the corresponding on-chain credential number and complete local binding. Under the premise of having an existing consortium blockchain platform and enterprise information infrastructure, those skilled in the art can reproduce the assembly, transmission and on-chain registration process of calculation credentials based on the above field definitions, interface interaction order, verification rules and resource security constraints, thereby realizing the on-chain solidification of carbon emission factor calculation results and subsequent traceability verification.

[0102] S5. The verification node reads the computation credential from the blockchain, requests the enterprise node to return a data slice with path proof according to the dimensional data digest, and calculates the data slice locally according to the template order to generate a verification fingerprint. The specific implementation is as follows:

[0103] When regulatory agencies or third-party institutions need to review the boiler fuel combustion factors for a given calendar month, their management platform initiates a verification process on the verification nodes deployed on the regulatory side. Verification nodes are servers or service instances controlled by regulatory agencies or third-party institutions, possessing access to the consortium blockchain and local computing capabilities, used to independently reconstruct and verify the factor calculation process of enterprise nodes.

[0104] The verification node first queries the target on-chain certificate record in the consortium blockchain using the aforementioned on-chain certificate number. It then reads the template identifier, template fingerprint, statistical period identifier, device scope description, summary identifier of dimensionalized data summaries for each dimension, calculation evidence chain fingerprint, and monthly factor values ​​recorded in the certificate. Based on the template identifier and template fingerprint, the verification node locates the template version consistent with the enterprise node in the local template library, ensuring that the rule set used for subsequent recalculation is the same as that of the enterprise node.

[0105] Based on the current verification plan and the unit's operation schedule within the statistical period, the management platform sets the time period, shifts, and operating condition combinations to be covered for this review, as well as the desired minimum sample size. The time period can be divided into several time windows according to calendar time (e.g., morning shift, afternoon shift, evening shift, weekend daytime, etc.). Shifts are identified by the shift codes agreed upon by the company. Operating condition combinations must at least distinguish between stable load operation, load increase / decrease operation, and start-up / shutdown processes. The minimum sample size is used to constrain the number of records selected as data slices within the statistical period to not be less than a certain percentage of the total number of valid records or activity volume for the entire month. These verification requirements are compiled into a single data slice request.

[0106] The data slice request includes the target on-chain voucher number, template identifier, statistical period identifier, dimension filtering conditions, and sample quantity requirements. The dimension filtering conditions clearly list the desired time period set, work group set, and work condition type set. The sample quantity requirements clearly specify the minimum number of samples or the corresponding minimum activity level. The verification node generates a unique request serial number for this data slice request, which serves as the request identifier for this verification. The request serial number is bound to the target on-chain voucher number as an idempotent key, so that when the same verification task repeatedly initiates a request, it can be identified as the same request.

[0107] The verification node encodes the data slice request into a structured message of key-value pairs. In addition to the aforementioned business fields, the message also includes the verification node identifier and timestamp. Preferably, the verification node uses the key held by the verification node to generate a digital signature for the message content. The message is sent to the enterprise node along with the signature through a pre-configured encrypted communication channel. When the enterprise node receives the message, it determines whether the request source is legitimate and whether the message has been tampered with based on the verification node identifier and the signature verification result.

[0108] After receiving a data slice request, the enterprise node first checks whether the request serial number already exists in the local request management module. If it exists and the status is "processed", it directly retrieves the data slice result generated for the previous request from the local cache and returns it to maintain idempotency. If the record does not exist or the status is "unprocessed", it enters the sampling logic.

[0109] Enterprise nodes retrieve the corresponding dimensional data summary and original detailed record set in the local evidence library according to the template identifier and statistical period identifier. The original detailed record set refers to the time series records that belong to the applicable device range of the template within the natural month and have passed the aforementioned anomaly removal, missing measurement filling and operating condition labeling. Each record contains at least the following fields: time tag, device identifier, shift identifier, operating condition tag, coal input, power generation, and the test result index corresponding to the time period.

[0110] Enterprise nodes first filter the original record set according to the dimension filtering conditions in the data slice request, based on three dimensions: time period, work group, and working condition. Only records whose time tags fall within the target time period set, whose work group identifiers belong to the target work group set, and whose working condition tags belong to the target working condition type set are retained. Records that do not meet any of the filtering conditions are removed. After obtaining the candidate record set that meets the dimension filtering conditions, enterprise nodes need to select specific samples from it, ensuring that they cover all time periods, work groups, and working condition types while also meeting the sample quantity requirements.

[0111] To address this, this embodiment employs a combination of stratified sampling and deterministic pseudo-random selection. First, the candidate record set is divided into several sampling strata based on a combination of three dimensions: time period, work group, and work condition type. Each stratum corresponds to the intersection of a specific time period, work group, and work condition type. The enterprise node sorts the records within each stratum from earliest to latest according to the time tag and assigns each record a sequential number from one to the total number of records in that stratum. Then, using the character sequence of the requested serial number as a seed, a pre-implemented pseudo-random number generation function sequentially generates a set of integer indices between one and the total number of records in that stratum for each stratum. The pseudo-random number generation function outputs identical sequences under the same seed input, ensuring determinism in the sampling process under the same requested serial number. To avoid selecting duplicate records in the same stratum, the enterprise node deduplicates and sorts the generated index sequence, and selects the corresponding entry from the ordered records of that stratum according to the sorted index position. Further sampling stops when the cumulative number of samples across all strata reaches or exceeds the lower limit of the sample quantity given in the data slice request, or reaches the upper limit of the sample quantity set by the enterprise node according to its resource usage strategy. The underlying logic of the above sampling process is as follows: dimensional division ensures coverage of target time periods, work groups, and work conditions; deterministic pseudo-random functions ensure that the sample set selected under the same request serial number remains unchanged; and lower and upper limits of the sample quantity control the balance between computational load and verification accuracy.

[0112] After selecting a sample set, the enterprise node constructs path proofs for the selected records to support the verification node in confirming that these samples are genuine segments in the original record sequence without obtaining the full data. The path proof includes at least the following: the start and end times covered by the sample set, the set of work group identifiers and work condition types involved, the number of sample records, the total amount of coal fed into the furnace and the total amount of electricity generated in the sample set, and the total number of all records in the corresponding statistical period, along with their total amount of coal fed into the furnace and total amount of electricity generated, to calculate the proportion of the sample set in the total activity volume of the entire period. Furthermore, when maintaining the original record set, the enterprise node globally sorts all records for the entire month by time label and assigns them a global sequence number from one to the total number of records for the entire month. When constructing the path proof, it records the global sequence number of the earliest and latest records in the sample set, as well as a list of global sequence numbers for each record in the sample set, to clarify the positional relationship of these samples in the entire monthly record sequence.

[0113] To prevent the sample content from being tampered with during transmission, the enterprise node concatenates the aforementioned path proof fields and the key fields of each record in the sample set (such as time tag, team identifier, working condition tag, coal input and power generation) into a text segment according to a fixed field order. Then, it generates a path summary using a deterministic summarization method. The summarization method can be a summarization function with collision resistance and fixed output length, as long as the output is completely consistent when the same text input is used. The path summary and path proof are saved together and returned to the verification node in the data slice response.

[0114] Enterprise nodes encapsulate the selected detailed records, corresponding path proofs, and path summaries into a data slice response message, which is then sent to the verification node through the same encrypted communication channel as the data slice request. The request serial number is bound to the global sequence number list and path summary corresponding to this sampling in the local request management module, so that consistent slice content can be quickly returned under the same request serial number in the future.

[0115] Upon receiving the data slice response message, the verification node first verifies the message signature using its public key and checks data integrity based on the path proof and path digest. Specifically, the verification node reassembles the key field texts of the path proof and sample record according to the field order agreed upon by the enterprise node, calculates a local path digest using the same digest operation method, and compares the local path digest with the path digest provided in the enterprise node message. Only when the two are completely identical is it considered that the sample record and path proof have not been tampered with. Simultaneously, the verification node obtains the digest identifier of the dimensional data digest corresponding to the statistical period in the target on-chain credential record through the consortium link interface. Based on the full-cycle statistical characteristics recorded in the dimensional data digest (such as the total number of records, the total amount of coal fed into the furnace, and the total amount of electricity generated), it compares them with the full-cycle statistical characteristics given in the path proof to ensure that the activity volume ratio and positional relationship claimed by the sample set are consistent with the on-chain records.

[0116] Once the path summary comparison and full-cycle statistical feature comparison both pass, the verification node treats the sample set as a reliable slice. Next, based on the template identifier and template fingerprint, the verification node loads the same version of template configuration and runtime environment as the enterprise node from the local template library. The runtime environment includes the same merging order (three-level merging by shift, date, and fuel batch) and factor calculation rules as the enterprise node.

[0117] The verification node treats a data slice as a constrained statistical period. Within this constrained period, it strictly follows the steps specified in the template to perform merging and factor calculation. Specifically, within the sample set, it merges coal input and power generation by work group, then by date, and then by fuel batch. Combining the corresponding test results and operating condition labels, it calculates the emissions and factor contribution of each sample batch. Then, it uses the power generation of each batch within the sample as a weight to perform a weighted average of the batch factor contributions to obtain the slice factor value. In this process, the verification node also generates step information and step summary after each key action, and updates the link summary sequentially using the same summary calculation method as the enterprise node to obtain a verification fingerprint, which is used to summarize the process of executing the template within the data slice.

[0118] The difference between the slice factor value and the full-month factor value recorded in the on-chain voucher is quantified using a weighted error assessment method. Preferably, a relative error calculation method weighted by activity volume can be adopted, that is, the absolute value of the difference between the slice factor value and the full-month factor value is divided by the full-month factor value and multiplied by a percentage to obtain a relative error percentage. Combining the proportion of the sample set recorded in the path proof in the total activity volume of the entire cycle, the regulatory agency can set one or more error acceptance thresholds, such as considering the review passed when the sample proportion reaches a certain percentage of the total activity volume and the relative error is less than one-thousandth.

[0119] In practice, under typical operating conditions of a coal-fired unit, regulatory agencies can require enterprise nodes to provide records representing approximately one to ten percent of the total effective coal input and power generation for the entire month as data slices. With correct template configuration and high data quality, the relative error between the slice factor value obtained by the verification node and the full-month factor value registered on the chain can usually be controlled within the order of one-thousandth. When the error is within the preset acceptable range and the path proof passes the verification with the on-chain dimensionalized data summary, regulatory agencies can determine that the coal combustion factor registered on the chain has high reliability.

[0120] With the aforementioned enterprise node evidence library, consortium blockchain credential records, and template configuration, those skilled in the art can reproduce the verification process in different system environments by following the steps of generating data slice requests, stratified sampling and deterministic pseudo-random selection, constructing path proofs and verifying digests, and recalculating verification nodes and evaluating errors. Under given resource and time constraints, they can independently verify the carbon emission factor calculation results and reproduce the technical effects.

[0121] S6. Compare the verification fingerprint with the computational evidence chain fingerprint, and write the verification conclusion into the on-chain record associated with the computational certificate through the verification contract, so that the subsequent carbon accounting system can select factors based on the verification status. The specific implementation is as follows:

[0122] After obtaining the verification fingerprint, the verification node first reads the current computational evidence chain fingerprint of the target on-chain certificate from the consortium chain, as well as metadata such as the template identifier, template fingerprint, and statistical period identifier. By comparing the template fingerprint of the template used for this recalculation in the local template library with the template fingerprint in the on-chain certificate byte by byte, it confirms that the two are completely consistent. This is the premise that the comparison is valid at the template version level. Under the premise that the template versions are consistent and the aforementioned path proof and path digest verification have passed, that is, the data slice source can be identified as reliable, the verification node enters the fingerprint and step digest comparison stage.

[0123] The computational evidence chain fingerprint is the final link digest obtained by sequentially rolling the digests of key steps throughout the entire lifecycle in the original session of the enterprise node, while the verification fingerprint is the link digest obtained by using the same digest operation method and step order in the data slice or the whole lifecycle recalculation process in the verification node. The digest operation methods and encoding rules of the two have been locked to be consistent in the template configuration.

[0124] To facilitate fine-grained comparison, in addition to generating the final computational evidence chain fingerprint in the original computation session, the enterprise node also saves a full-cycle step summary sequence arranged by the template step sequence number in the local log area. Each step summary corresponds to a unique step sequence number. When the verification node recalculates the data slice, it also records a verification step summary sequence arranged by the step sequence number. When designing the template, it is agreed that the same sequence number corresponds to only one step type, so that alignment can be completed between different nodes based solely on the sequence number.

[0125] The verification node determines the set of step sequence numbers directly related to these dimensions in the template definition based on the time range, work group set, and work condition type set corresponding to the data slice. For example, the step sequence numbers related to work group merging, batch emission estimation, and sample internal weighted summarization are used. These sequence number sets are defined as the local comparison range. During the comparison, only the step summaries within this range are compared one by one. Specifically, the verification node uses the step sequence number as the key to extract the corresponding summary value from the original step summary sequence of the enterprise node, and then extracts the summary value of the same sequence number from the local verification step summary sequence. The two are then checked for equality one by one. Only when the summary values ​​corresponding to all sequence numbers within the local comparison range are completely consistent is it considered that "the step summaries within the local range are consistent".

[0126] Simultaneously, the verification node calculates the relative error based on the aforementioned slice factor calculation results and the full-month factor value in the on-chain certificate. The relative error is preferably defined as the absolute value of the difference between the slice factor value and the full-month factor value divided by the full-month factor value and then multiplied by a percentage. Under the conditions of consistent template version, matching path digest, and consistent local step digest, if the relative error is less than the pre-configured first error threshold, the verification node marks this verification as a "positive conclusion". If the template version is consistent and the path digest matches, but there are inconsistencies in the local step digest, or the relative error is between the first error threshold and the second error threshold (the second error threshold is greater than the first error threshold), the verification is marked as a "reserved conclusion", and the "whether to recommend further manual verification" flag is set to true to prompt regulatory personnel or third-party assessment personnel to conduct manual review based on the on-site situation. If the template fingerprint is inconsistent, the path digest verification fails, or the relative error is greater than the second error threshold, or an anomaly in the step digest that does not match the slice range occurs outside the local comparison range, the verification node marks this verification as a "negative conclusion" and forces the "whether to recommend further manual verification" flag to true.

[0127] After forming a verification conclusion, the verification node uses the on-chain credential number as the index key and submits a verification result record to the consortium blockchain through the verification result writing interface provided by the consortium blockchain rules component. The verification result record includes at least the on-chain credential number, template identifier, statistical period identifier, description of the data slice range used (including the time period set, work group set, work condition type set, and the proportion of sample activity to the total activity of the whole period covered by the slice), verification fingerprint, relative error value, comparison conclusion type enumeration value (positive, reserved, or negative), boolean flag indicating whether further manual verification is recommended, and verification node identity identifier.

[0128] When receiving verification result records, the consortium blockchain rules component first verifies whether the node is a pre-registered regulatory node or a third-party verification node authorized by a regulatory agency, based on the verification node's identity identifier and message signature. Only nodes that pass authentication are allowed to write verification results. After authentication, the rules component queries the on-chain state database using a combination of "on-chain credential number + verification node identity identifier + data slice range description" as the verification result identifier. If no record with the same identifier exists, a verification result number is generated for that result, and all fields are written to the consortium blockchain ledger. The result number is associated with the corresponding calculation voucher record to achieve a one-to-many connection. If the same verification result identifier already exists and the comparison conclusion type and relative error value are completely consistent with the current submission, the rule component will regard the current submission as a duplicate confirmation of the same verification result, and will not add a new record, but only update the most recent receipt time field in the record. If the same verification result identifier exists but the comparison conclusion type or relative error value is different, the rule component can refuse to write to the current record according to the preset conflict handling strategy, and generate a conflict marker event for the verification result identifier on the chain, which can be manually intervened by the regulatory agency when necessary.

[0129] During the factor selection phase, when the carbon accounting system compiles emission reports, issues external statements, or provides factor values ​​to the carbon trading platform, it uses a query interface connected to the consortium blockchain to read the calculation voucher information corresponding to the target on-chain voucher number as the query key, as well as all registered verification result records.

[0130] The carbon accounting system is configured locally with a set of factor selection decision rules. The definition of "qualified regulatory nodes" is usually a set of whitelist nodes maintained by regulatory agencies. Only the affirmative or negative conclusions of these nodes are considered to have a decisive impact on factor selection. The definition of the applicable period of a factor can be set as a number of natural months from the end of the statistical period. If no new negative conclusions appear during this period and the operating mode of the key equipment does not change substantially, the factor is considered to be within the applicable period.

[0131] After reading the verification records, the system first filters out verification results from qualified regulatory nodes that are within the factor's applicable period. Then, it checks if there is at least one verification result with a "positive" conclusion, and confirms that there are no records from qualified regulatory nodes with a "negative" conclusion among all verification results. If all the above conditions are met, the carbon accounting system marks the factor corresponding to the on-chain voucher as "directly usable" and writes the on-chain voucher number as supporting evidence of the factor's source into the report text or appendix when generating the emissions report. This allows third-party reviewers to trace back to the consortium through the voucher number. The calculation vouchers and verification records on the chain; if there is a negative conclusion from a qualified regulatory node, or if there is no verification record from a qualified regulatory node within the applicable period of the factor, the carbon accounting system marks the factor as "requires manual review" or "requires the use of a backup factor", and triggers subsequent processing according to the preset strategy. One strategy is to issue a review reminder to the carbon management personnel, requiring them to recalculate the factor based on the company's internal data and backup templates. Another strategy is to automatically select a backup factor that has passed historical verification from the backup template set for use in the current period's statistics, and at the same time, explicitly mark the factor as a backup factor in the report with a field.

[0132] Regardless of whether the final choice is to directly adopt the on-chain factor, adopt a new factor after manual review, or adopt a backup factor, the carbon accounting system records the time of factor selection, the reason for selection, the verification record number involved in the judgment, the corresponding on-chain voucher number, and the factor value adopted in the local log, so as to form a traceable chain of decision evidence.

[0133] With the aforementioned enterprise nodes, verification nodes, and consortium blockchain infrastructure, those skilled in the art can replicate the complete closed loop from factor calculation, credential on-chaining, slice verification to factor selection in engineering practice by following the above-described verification fingerprint comparison, verification result registration and idempotent processing, and factor selection decision rules, and obtain the same technical effect as this embodiment.

[0134] In the operational scenario shown in this embodiment: In a power plant with two coal-fired units as the main generating units, the carbon accounting system is interconnected with enterprise nodes and consortium blockchain nodes through a secure private network. The regulatory agency deploys verification nodes in an external data center and connects to the same consortium blockchain. In this embodiment, for the boiler fuel combustion factor of the main boilers, the carbon management personnel first establish a carbon emission factor calculation template in the carbon accounting system according to the aforementioned step S1. The device scope is limited to the two main boilers, the statistical period is within the calendar month, the fuel type is limited to bituminous coal and blended coal, and rules for filling missing measurement segments, tolerance range, and rules for eliminating periods of process instability are configured. The system generates a template identifier and template fingerprint, and the enterprise node completes the template registration through the consortium blockchain rule component, forming a template registration record subject to version locking constraints.

[0135] On the settlement date at the end of each calendar month, the enterprise node, following step S2 and using the registered template identifier as an index, extracts the original records belonging to the template device range and fuel category range for the current month from the energy consumption monitoring platform, belt scale system, electricity metering device, production management system, and laboratory management system. It unifies the units and aligns them according to the time label, performs tolerance elimination, missing measurement segment filling, and laboratory result substitution processing, groups them according to the calendar month statistical cycle and input dimension, calculates the statistical characteristics of each statistical entity, and generates a summary identifier based on fixed sorting rules and summary operation methods. It organizes the statistical characteristic set and summary identifier corresponding to each input dimension into a dimensional data summary, and writes it, along with the statistical cycle identifier, template identifier, and device range description, into the evidence library inside the enterprise node in read-only mode.

[0136] After confirming the stability of the monthly dimensional data summary version, the enterprise node initiates the boiler fuel combustion factor calculation session in the operating environment corresponding to the template fingerprint according to step S3. An idempotent key is constructed using the statistical period identifier, template identifier, and device range. A session serial number is generated, and the corresponding dimensional data summary is retrieved from the evidence library. Following the template merging rules, the coal input and power generation are merged sequentially in the shift, date, and fuel batch dimensions. Batch emissions and batch factor contributions are calculated based on test results and operating condition labels. Weighted summaries are then performed using the power generation of each batch as the weight to obtain the monthly boiler fuel combustion factor value. When key actions such as shift merging, date merging, fuel batch aggregation, batch emission estimation, batch factor contribution calculation, and monthly factor weighted summaries are completed, step information containing step sequence numbers, dimension labels, rule version number sets, and intermediate quantity status numbers is generated. Based on the step information, the link summary identifier is updated in a chain-like manner, ultimately obtaining the computational evidence chain fingerprint for this calculation session. This fingerprint, along with the template fingerprint, the summary identifiers of the dimensional data summaries for each input dimension, and the factor values, is written into the evidence chain storage area.

[0137] Subsequently, following step S4, the enterprise node retrieves the template identifier, template fingerprint, statistical period identifier, device scope description, summary identifier of dimensional data summaries for each input dimension, computed evidence chain fingerprint, and monthly factor value from the evidence chain storage area corresponding to the session serial number. Based on data integrity, the proportion of substitute data, operational condition coverage, and rule configuration consistency, the node calculates the quality level and assembles the aforementioned fields into a computational credential in a preset order. It then generates a computational credential identifier by combining the session serial number and statistical period identifier, encapsulates it into a computational credential message using a key-value pair structure, and submits it to the network through a business interface with two-way certificate authentication and transport layer encryption capabilities. The consortium blockchain rules component verifies the existence of template registration records, the consistency of template fingerprints, and the correspondence between statistical period identifiers, device scope descriptions, and the scope of application of registration. Using the computational credential identifier as the key, it writes the template identifier, template fingerprint, statistical period identifier, device scope description, factor category identifier, factor value, set of summary identifiers for dimensionalized data summaries of each input dimension, computational evidence chain fingerprint, and quality level marker fields into the on-chain ledger. It generates an on-chain credential number and returns it to the enterprise node. The enterprise node establishes a mapping relationship between the on-chain credential number and the session serial number, statistical period identifier, and template identifier in its local credential management module.

[0138] When the regulatory side needs to review the boiler fuel combustion factors for a certain natural month, the verification node reads the target on-chain credential record from the consortium blockchain according to step S5, using the on-chain credential number as the key. It obtains the template identifier, template fingerprint, statistical period identifier, device scope description, summary identifier of the dimensional data summary of each input dimension, calculates the evidence chain fingerprint, and the full-month factor values. It also loads the template configuration consistent with the template fingerprint into the local template library. The regulatory agency sets the set of time periods, shifts, and operating conditions to be covered, as well as the minimum sample quantity, in the management platform according to the unit operation plan for that month. The verification node generates a data slice request containing the on-chain credential number, template identifier, statistical period identifier, dimension filtering conditions, and sample quantity requirements. It assigns a request serial number to the request and binds it to the on-chain credential number as an idempotent key. The request is then sent to the enterprise node through an encrypted communication channel. After receiving the request, the enterprise node retrieves the original detailed record set from the evidence library by template identifier and statistical period identifier. It divides and sorts the sampling layers by time period, work group identifier, and working condition label. Using the request serial number as a seed, it calls the pseudo-random number generation function to select samples in each sampling layer to form a sample set. It constructs a path proof that includes the sample time range, work group identifier, working condition label, summary value of coal input to the furnace, summary value of power generation, and global sequence number. Based on the path proof and key fields of the samples, it generates a path digest. The sample set, path proof, and path digest are encapsulated into a data slice response message and returned to the verification node through an encrypted communication channel.

[0139] Upon receiving the data slice response message, the verification node first verifies the message signature using a pre-set public key. It then generates a local path digest by reassembling the path proof and key sample fields, comparing it byte-by-byte with the path digest provided by the enterprise node to confirm that the sample content has not been tampered with. Simultaneously, it searches for full-cycle statistical features based on the digest identifier of the dimensional data digest corresponding to the statistical period in the on-chain certificate record. This is compared with the number of full-cycle records, the total amount of coal fed into the furnace, and the total amount of electricity generated, as given in the path proof. Once the proportion and positional relationship of the sample set in the full-cycle activity volume are confirmed to be consistent with the on-chain registration information, the sample set is considered a trusted slice. Based on this, the verification node loads the runtime environment corresponding to the template fingerprint, treats the data slice as a restricted statistical period, and performs merging and intermediate quantity calculations on the sample set according to the merge order and factor calculation rules agreed upon in the template for team, date, and fuel batch dimensions. After each key action, verification step information and a step digest are generated, and the link digest identifier is updated sequentially to finally obtain the verification fingerprint. The slice factor value is then calculated, and the relative error between the slice factor value and the full-month factor value in the on-chain certificate is calculated.

[0140] Finally, the verification node generates a conclusion type marker according to step S6 based on the consistency of the template fingerprint, the path digest matching result, the consistency of the local step digest, and the relationship between the relative error and the preset error threshold. The verification result record, which includes the on-chain certificate number, template identifier, statistical period identifier, data slice range description, verification fingerprint, relative error value, conclusion type marker, whether manual further verification is recommended, and verification node identity identifier, is written into the consortium blockchain ledger through the consortium blockchain rules component, and is associated with the corresponding computation certificate record by the verification result number. During the factor selection phase, the carbon accounting system reads the calculation voucher corresponding to the target on-chain voucher number and all verification result records through a query interface. Based on the locally configured whitelist of qualified regulatory nodes and factor applicability period rules, it filters verification results from qualified regulatory nodes within the applicability period. If at least one conclusion is affirmative and there are no negative conclusions from qualified regulatory nodes, the boiler fuel combustion factor corresponding to the on-chain voucher is marked as directly usable, and the on-chain voucher number is written into the emission report as the factor source identifier. If there are negative conclusions or no verification results from qualified regulatory nodes are obtained within the applicability period, the factor is marked as requiring manual review or a backup factor according to a preset strategy, triggering an internal recalculation or backup factor selection process. The system records the factor selection time, selection reason, verification record number involved in the judgment, and corresponding on-chain voucher number, forming a traceable chain of decision evidence. This embodiment demonstrates that this method can achieve on-chain solidification of carbon emission factor calculation results, cross-node slice review, and a closed-loop decision-making process based on verification conclusions in a typical coal-fired power plant scenario.

[0141] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

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

[0143] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are 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; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0144] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0145] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

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

[0147] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0148] If the aforementioned functions are implemented as software functional 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 this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0149] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0150] In conclusion, 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 within the protection scope of the present invention.

Claims

1. A blockchain-based method for calculating and verifying carbon emission factors, characterized in that, include: S1. Configure the carbon emission factor calculation template, limit the input dimensions, preprocessing rules and model calling order, calculate the template fingerprint and register the template identifier and template fingerprint on the blockchain; S2. Extract raw data from energy consumption and production data sources according to template identifiers, calculate statistical features according to input dimensions, and generate summary identifiers based on summary operation methods to form a dimensional data summary; S3. Initiate a computational session in the operating environment corresponding to the template fingerprint, complete data processing and model inference according to the template sequence, record step information and result summaries at key steps, and generate a computational evidence chain fingerprint using chain hashing; in the operating environment, the enterprise node constructs an idempotent key based on the statistical period identifier, template identifier, and device range, generates a session serial number when no existing session record is found, and reads the dimensional data summary corresponding to the idempotent key from the evidence library; according to the template merging rules, merge statistical features sequentially in the team dimension, date dimension, and fuel batch dimension, and calculate the boiler fuel combustion factor; when each key action is completed, generate step information containing a set of step sequence numbers and rule version numbers, update the link summary identifier based on the step information to obtain the computational evidence chain fingerprint, and write the computational evidence chain fingerprint, template fingerprint, dimensional data summary summary identifier, and factor value into the evidence chain storage area; S4. Based on the calculation results, assemble a calculation certificate containing template identifier, dimensional data summary, calculation evidence chain fingerprint and factor values, submit it through the verification contract and write it to the blockchain; S5. The verification node reads the computation certificate from the blockchain, requests the enterprise node to return a data slice with path proof according to the dimensional data digest, and calculates the data slice locally according to the template order and generates a verification fingerprint. After receiving a data slice request, the enterprise node retrieves detailed records from the evidence database based on the template identifier and statistical period identifier. It then divides and sorts the sampling layers by time period, work group identifier, and working condition label. Using the request serial number as a seed, the enterprise node calls a pseudo-random number generation function to select samples from each sampling layer to form a sample set. It then constructs a path proof that includes the sample time range, work group identifier, working condition label, summary value of coal input to the furnace, summary value of power generation, and global sequence number. Based on the path proof, it generates a path digest and encapsulates the sample set, path proof, and path digest into a data slice response message, which is then sent to the verification node. S6. Compare the verification fingerprint with the computational evidence chain fingerprint, and write the verification conclusion into the on-chain record associated with the computational certificate through the verification contract, so that the subsequent carbon accounting system can select factors based on the verification status.

2. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that, S1 includes: The carbon accounting system establishes a carbon emission factor calculation template, limiting the scope of equipment, the range of statistical periods, and the range of fuel categories; Pre-configure rules for filling missing measurement segments, tolerance ranges, and rules for eliminating periods of unstable processes; The template fields and rule parameters are encoded according to a preset field order to generate a template fingerprint.

3. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that: Enterprise nodes generate template identifiers based on device code, factor category, and template version number, and use the template identifiers as idempotent keys for template registration requests; By interacting with the consortium blockchain rules component, template identifiers, template fingerprints, and applicable scope information are written into the consortium blockchain ledger state, and historical template records are retained in read-only mode to achieve template version locking.

4. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that, S2 include: Enterprise nodes retrieve raw records from the energy consumption monitoring platform, metering devices, and management system based on template identifiers; Unify the units of measurement according to the device range and statistical period and align the time labels; set the tolerance range according to the verification results and eliminate records that exceed the limits; fill the measurement gaps according to the missing measurement segment filling rules and replace the missing test results according to the substitution rules. Statistical entities are obtained by grouping them according to time range and input dimension, statistical features are calculated, summary identifiers are generated under fixed sorting rules, and dimensionalized data summaries of each input dimension are stored in the evidence library in read-only mode.

5. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that, S4 includes: After the computation session ends, the enterprise node assembles the computation certificate using the template identifier, template fingerprint, statistical period identifier, device range description, factor category identifier, factor value, dimensional data summary of each input dimension, and computation evidence chain fingerprint. Generate a calculation voucher identifier based on the session serial number and statistical period identifier; Submit the computation credential and its identifier to the consortium blockchain; After verifying the consistency of template registration records, template fingerprints, and the correspondence between statistical period identifiers and device range descriptions, the consortium blockchain rules component writes the calculation voucher into the on-chain ledger and generates an on-chain voucher number.

6. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that, S5 include: The verification node reads the on-chain certificate record corresponding to the on-chain certificate number from the consortium chain based on the on-chain certificate number, and reads the template identifier, template fingerprint, statistical period identifier, device range description, dimensional data summary of each input dimension, and monthly factor value recorded in the on-chain certificate record; The verification node generates a data slice request that includes an on-chain credential number, template identifier, statistical period identifier, dimension filtering conditions, and sample quantity requirements. It assigns a request serial number to the data slice request and binds it to the on-chain credential number as an idempotent key, and sends it to the enterprise node through an encrypted communication channel.

7. The method for calculating and verifying carbon emission factors based on blockchain according to claim 1, characterized in that, S6 include: After obtaining the verification fingerprint, the verification node reads the full-month factor value based on the on-chain certificate number, and generates a conclusion type label based on the relative error between the slice factor value and the full-month factor value and the verification fingerprint. The verification results, including the on-chain credential number, data slice range description, verification fingerprint, and conclusion type marker, are written into the consortium blockchain. The carbon accounting system then determines the selection status of the on-chain factor based on the verification results of qualified regulatory nodes within the factor's applicable period.

Images