A method and system for establishing a zero-carbon cloud library emission reduction ledger and two-way statistical reporting.

Abstract

This invention relates to the technical fields of carbon emission management for public institutions, database ledger management, and reporting interface processing. It discloses a method and system for establishing a zero-carbon cloud library emission reduction ledger and two-way statistical reporting. The method acquires information from public institutions, basic library information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configurations, and evidence storage rules to generate initial ledger data. Based on this, a unique ledger code and a standard electronic ledger are generated, and data from various tables are written to form associated ledger data. After format verification, logical verification, and historical trend verification, a ledger version, version hash value, and evidence storage record are generated. The method also generates a reporting data packet, receives receipt data, updates the two-way statistical reporting status, and outputs historical version comparison results and assessment supporting materials. This invention effectively improves the consistency, traceability, and reliability of emission reduction ledger reporting.

Description

Technical Field

[0001] This invention relates to the fields of carbon emission management, database ledger management, and reporting interface processing for public institutions, and particularly to a method and system for establishing a zero-carbon cloud library emission reduction ledger and bidirectional statistical reporting. Background Technology

[0002] In the areas of carbon emission management, database ledger management, and reporting interface processing for public institutions, existing solutions for zero-carbon cloud library emission reductions typically involve manual data entry or a single ledger system receiving basic library information, emission reduction project registration data, monthly emission reduction data, and third-party verification results. The data is then compiled and submitted separately according to the reporting requirements of local carbon emission statistics platforms or public institution carbon accounting systems. This approach suffers from limitations such as inconsistencies between the ledger version and the source of the submitted data package, difficulty in rewriting the ledger version with receipt data, and separation of evidence storage records from the reporting status. Existing methods largely rely on independent forms, manual aggregation, and one-way interface submissions, which easily lead to issues such as duplicate data entry, inconsistent fields, and version tracking breakpoints.

[0003] In scenarios where public institutions manage emission reductions from zero-carbon cloud libraries and conduct two-way statistical reporting, there are often differences in the interface configurations of local carbon emission statistics platforms and public institutions' carbon accounting systems. When the same emission reduction data is processed through different paths, inconsistencies can easily arise between the sources of the first and second reported data packets, and the inability of the first and second receipt data to jointly update the two-way statistical reporting status. Furthermore, after the ledger data is corrected, the lack of a unified version hash value and evidence record association between the old and new ledger versions makes it difficult to meet the requirement of generating assessment supporting materials based on the ledger version.

[0004] Regarding the joint processing of ledger version, version hash value, evidence storage records, first reporting data packet, second reporting data packet, first receipt data, second receipt data, and two-way statistical status, existing technologies generally lack a continuous process from ledger initialization data, standard electronic ledger, associated ledger data, ledger verification results to ledger version and two-way statistical status. Ledger version generation, reporting data packet generation, receipt data reception, and historical version comparison are often scattered in different processing stages, making it difficult for evidence storage records to serve as a common basis for the first and second reporting data packets, and making it difficult for the two-way statistical status to be consistent with the results of historical version comparisons. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for establishing a zero-carbon cloud library emission reduction ledger and a two-way statistical method, comprising:

[0006] S100: Obtain multi-source information, perform field standardization and encapsulation processing, and generate ledger initialization data;

[0007] The multi-source information includes: public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration and evidence storage rules;

[0008] S200. Based on the ledger initialization data, perform loading processing to generate a unique ledger code and a standard electronic ledger;

[0009] The standard electronic ledger includes a basic information table, an emission reduction project filing table, a monthly emission reduction data collection table, a third-party verification result table, a green reading service implementation ledger, and an annual emission reduction summary table.

[0010] S300. Write data into each table based on the standard electronic ledger, and generate associated ledger data through the unique ledger code, project name, month, verification date and activity type;

[0011] S400. Based on the associated ledger data, perform format verification, logic verification, and historical trend verification to generate ledger verification results.

[0012] S500: Generate a ledger version, version hash value, and evidence record based on the verification pass status in the ledger verification result;

[0013] S600: Based on the ledger version, the version hash value, and the evidence record, perform verification processing, generate the first and second reporting data packets, receive the first and second receipt data, and update the bidirectional statistical status.

[0014] S700. Based on the bidirectional statistical status and the evidence record, perform hash value comparison processing to generate historical version comparison results and assessment supporting materials.

[0015] Furthermore, the interface configuration includes the interface configuration of the local carbon emission statistics platform and the interface configuration of the public institution carbon accounting system, and the unique ledger code consists of the public institution code, the library serial number and the year.

[0016] Furthermore, the basic information table includes the name, address, operating entity, and service scope of the venue; the emission reduction project filing form includes the project name, emission reduction path, and methodological basis; the monthly emission reduction data collection form includes the emission reduction amount, emission factor values, and data source; the third-party verification result form includes the verification agency, verification conclusion, and verification date; the green reading service implementation ledger includes the activity type, number of participants, and paperless ratio; and the annual emission reduction summary table includes the cumulative emission reduction amount and standard coal savings for the year.

[0017] Furthermore, in the associated ledger data, the basic information table is associated with the emission reduction project filing form, the monthly emission reduction data collection form, the third-party verification result form, the green reading service implementation ledger, and the annual emission reduction summary form through the unique ledger code; the emission reduction project filing form is associated with the monthly emission reduction data collection form through the project name; and the third-party verification result form is associated with the monthly emission reduction data collection form and the annual emission reduction summary form through the verification date.

[0018] Furthermore, the format validation includes validation of the completeness of required fields and validation of the correctness of data types; the logical validation includes validation of the consistency of related fields between tables and verification of reasonable ranges for emission reductions; the historical trend validation includes a comparison of the emission reductions for the current month with the emission reductions for the same period in history.

[0019] Furthermore, the ledger verification results include verification passed status, format verification failed status, logic verification failed status, and historical trend verification failed status; when the ledger verification result is format verification failed status, logic verification failed status, or historical trend verification failed status, a correction prompt is generated, and the generation of the ledger version is stopped.

[0020] Furthermore, the key data fields include a unique ledger code, ledger version number, project name, month, emission reduction, emission factor value, data source, verification conclusion, activity type, number of participants, paperless ratio, cumulative emission reduction for the year, and standard coal savings; hash processing is performed on the key data fields to generate the version hash value; the evidence storage record includes the ledger version number, the version hash value, the on-chain timestamp, and the node signature.

[0021] Furthermore, in S600, the first reporting data packet is generated based on the interface configuration of the local carbon emission statistics platform, and the second reporting data packet is generated based on the interface configuration of the public institution carbon accounting system; both the first reporting data packet and the second reporting data packet are written with the unique ledger code, the ledger version number and the version hash value.

[0022] Furthermore, both the first receipt data and the second receipt data include the target system identifier, receiving status, receipt time, and reason for the exception; when the receiving status is empty or the reason for the exception is not empty, a retry record is generated; the historical version comparison result is generated by comparing the version hash value of the current ledger version with the version hash value of the historical ledger version.

[0023] Furthermore, a zero-carbon cloud library emission reduction ledger and two-way statistical system, applied to any of the methods described above, includes: a standardized ledger construction module, a data writing and association module, a data integrity verification module, a blockchain evidence storage module, a two-way reporting engine, and a compliance review module.

[0024] The key innovations of this invention include:

[0025] (1) Generate first and second reporting data packets based on the ledger version, the version hash value and the evidence record, and receive first and second receipt data, update the bidirectional statistical status, so that the first and second reporting data packets both come from the same ledger version.

[0026] (2) Generate a ledger version, version hash value and evidence record based on the verification pass status in the ledger verification result, so that the ledger version is formed by the associated ledger data after format verification, logic verification and historical trend verification.

[0027] (3) Based on the bidirectional statistical status and the evidence record, generate historical version comparison results and assessment supporting materials, so that the first and second receipt data, the evidence record and the historical version comparison results enter the same material generation link.

[0028] The following are its main beneficial effects:

[0029] (1) To address the issue of inconsistent sources of the first and second reporting data packets, the first and second reporting data packets are generated by combining the ledger version, the version hash value, and the evidence record, so that the reporting data under the different interface configurations of the local carbon emission statistics platform and the public institution carbon accounting system are all bound to the same ledger version.

[0030] (2) To address the issue of unclear version origin caused by the direct generation of version after arbitrary data is written, the ledger version, version hash value and evidence record are generated by triggering the verification pass status in the ledger verification result, so that the ledger version corresponds to the associated ledger data that has completed format verification, logic verification and historical trend verification.

[0031] (3) To address the issue of the separation between the historical version comparison results and the bidirectional statistical status, the historical version comparison results and assessment supporting materials are generated through the bidirectional statistical status and the evidence storage records, so that the ledger version, the first receipt data, the second receipt data and the evidence storage records can be called in the same link.

[0032] (4) To address the issue of scattered data in the standard electronic ledger, associated ledger data is generated by using a unique ledger code, project name, month, verification date, and activity type, so that the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, and annual emission reduction summary table are unified and associated.

[0033] (5) To address the problem that the receipt data is difficult to write back to the ledger version, the first and second receipt data are received and the bidirectional statistical status is updated to ensure that the first and second receipt data are in correspondence with the ledger version, the version hash value and the evidence record. Attached Figure Description

[0034] Figure 1 A flowchart illustrating a zero-carbon cloud library emission reduction ledger and two-way statistical inclusion method provided in this application embodiment;

[0035] Figure 2 This is a structural block diagram of a zero-carbon cloud library emission reduction ledger and two-way statistical system provided in an embodiment of this application. Detailed Implementation

[0036] Example 1: Refer to Figure 1 This is a flowchart illustrating a zero-carbon cloud library emission reduction ledger and two-way statistical inclusion method provided by an embodiment of the present invention. The process may include at least steps S100-S700:

[0037] S100: Obtain information from public institutions, basic library information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration and evidence storage rules, and generate ledger initialization data;

[0038] S200. Generate a unique ledger code and a standard electronic ledger based on the ledger initialization data. The standard electronic ledger includes a basic information table, an emission reduction project filing table, a monthly emission reduction data collection table, a third-party verification result table, a green reading service implementation ledger, and an annual emission reduction summary table.

[0039] S300. Write data into each table based on the standard electronic ledger, and generate associated ledger data through the unique ledger code, project name, month, verification date and activity type;

[0040] S400: Perform format verification, logic verification, and historical trend verification based on the associated ledger data, and generate ledger verification results;

[0041] S500: Generate a ledger version, version hash value, and evidence record based on the verification pass status in the ledger verification result;

[0042] S600: Generate first and second reporting data packets based on the ledger version, the version hash value and the evidence record; receive first and second receipt data; and update the bidirectional statistical status.

[0043] S700. Based on the bidirectional statistical status and the evidence record, generate historical version comparison results and assessment supporting materials.

[0044] S100: Obtain information from public institutions, basic library information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration and evidence storage rules, and generate ledger initialization data;

[0045] Specifically, S100 is executed by the standardized ledger construction module. This module receives data from the public institution management terminal, library management terminal, emission reduction project filing terminal, monthly emission reduction data collection terminal, third-party verification result entry terminal, green reading service implementation data entry terminal, local carbon emission statistics platform interface configuration terminal, public institution carbon accounting system interface configuration terminal, and blockchain evidence storage module configuration terminal. The public institution information refers to the public institution code, public institution name, and competent authority fields. The library basic information refers to the library name, address, operating entity, and service scope fields. The emission reduction project filing data refers to the project name, emission reduction path, and methodological basis fields. The monthly emission reduction data refers to the monthly, emission reduction amount, emission factor value, and data source fields. The third-party verification results refer to the verification agency, verification conclusion, and verification date fields. The green reading service implementation data refers to the activity type, number of participants, and paperless ratio fields. The interface configuration refers to the local carbon emission statistics platform interface configuration and the public institution carbon accounting system interface configuration. The evidence preservation rules refer to key data fields, hash processing rules, on-chain timestamp rules, and node signature rules.

[0046] Furthermore, after receiving the aforementioned fields, the standardized ledger construction module first performs source registration processing. This source registration processing writes the sources of public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration data, and evidence storage rules into the same receiving record. The receiving record includes the receiving time, source name, field name, and field status. Field status includes received, missing, and pending correction status. For data with a missing field status, the standardized ledger construction module retains the receiving record and generates a field completion prompt. For data with a pending correction field status, the standardized ledger construction module retains the original field content and writes the field to be corrected into the abnormal record section.

[0047] Furthermore, the standardized ledger construction module performs field standardization processing on the received fields. This field standardization processing includes unifying field names, converting field types, unifying date formats, standardizing monthly fields, standardizing numerical fields, and registering source fields. Unifying field names refers to converting the names of different sources (museum name, project name, month, verification date, and activity type) into the same field names used in this method. Converting field types refers to converting emission reductions, emission factor values, number of participants, paperless ratio, cumulative emission reductions for the year, and standard coal savings into numerical fields. Unifying date formats refers to converting the date fields involved in the verification date, receipt time, and on-chain timestamp rules into the same date format. Standardizing monthly fields refers to converting the monthly fields in the monthly emission reduction data into a combination of year and month fields. Registering source fields refers to writing the data source, verification agency, interface configuration source, and evidence storage rule source into the source registration section.

[0048] Furthermore, the standardized ledger construction module performs initialization encapsulation processing after field standardization. This initialization encapsulation process encapsulates public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration, and evidence storage rules into the ledger initialization data. The ledger initialization data includes fields such as public institution code, library name, address, operating entity, service scope, project name, emission reduction path, methodological basis, month, emission reduction amount, emission factor value, data source, verification agency, verification conclusion, verification date, activity type, number of participants, paperless ratio, local carbon emission statistics platform interface configuration, public institution carbon accounting system interface configuration, and evidence storage rules. The ledger initialization data also includes receiving records and abnormal record sections. The receiving records are used when S200 generates a unique ledger code, and the abnormal record section is used when S400 performs format verification.

[0049] In an engineering implementation, when a public institution manages multiple zero-carbon cloud libraries, the public institution management terminal inputs the public institution code and name; the library management terminal inputs the library name, address, operating entity, and service scope; the emission reduction project filing terminal inputs the project name, emission reduction path, and methodological basis; the monthly emission reduction data collection terminal inputs the monthly emission reduction amount, emission factor values, and data source; the third-party verification result entry terminal inputs the verification agency, verification conclusion, and verification date; and the green reading service data entry terminal inputs the activity type, number of participants, and paperless ratio. The standardized ledger construction module completes source registration, field standardization, and initialization encapsulation within the same receiving window, generates the ledger initialization data, and sends the ledger initialization data to S200.

[0050] In summary, the technical effects of this step are as follows: Step S100 aggregates public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configurations, and evidence storage rules into a single ledger initialization data. Step S100 completes source registration and field standardization before generating the ledger initialization data, reducing field conflicts during subsequent sub-table writing. The output of Step S100 directly enters Step S200, providing a unified input for unique ledger codes and the generation of standard electronic ledgers.

[0051] S200. Generate a unique ledger code and a standard electronic ledger based on the ledger initialization data. The standard electronic ledger includes a basic information table, an emission reduction project filing table, a monthly emission reduction data collection table, a third-party verification result table, a green reading service implementation ledger, and an annual emission reduction summary table.

[0052] Specifically, step S200 is executed by the standardized ledger construction module. Step S200 receives the ledger initialization data output from step S100, and uses the public institution code, library serial number, and year as encoding fields to generate the unique ledger code. The library serial number is generated by the standardized ledger construction module based on the library name and address under the same public institution code. The year is generated from the year to which the month field belongs. The unique ledger code is written into the primary key field of the standard electronic ledger, and maintains the same field name in subsequent basic information tables, emission reduction project filing tables, monthly emission reduction data collection tables, third-party verification result tables, green reading service implementation ledgers, and annual emission reduction summary tables.

[0053] Furthermore, the standardized ledger construction module establishes the standard electronic ledger based on the unique ledger code. The standard electronic ledger has a database table structure. The basic information table records the institution name, address, operating entity, and service scope. The emission reduction project filing table records the project name, emission reduction path, and methodological basis. The monthly emission reduction data collection table records the month, emission reduction amount, emission factor values, and data source. The third-party verification result table records the verification agency, verification conclusion, and verification date. The green reading service implementation ledger records the activity type, number of participants, and paperless ratio. The annual emission reduction summary table records the cumulative emission reduction amount and standard coal savings for the year. When creating each sub-table, the standardized ledger construction module writes the unique ledger code into the common field of that sub-table and writes the creation time, field version, and data source into the sub-table record section.

[0054] Further, in step S200, sub-table template loading is performed when establishing the standard electronic ledger. This sub-table template loading process involves loading the basic information table template, emission reduction project filing table template, monthly emission reduction data collection table template, third-party verification result table template, green reading service implementation ledger template, and annual emission reduction summary table template into the database. Each template includes a field name, field type, field length, whether it is required, and a default status field. The field name comes from the ledger initialization data generated in step S100. The field type is written by the field standardization processing result. The required field is used for format validation in step S400. The default status field is used to mark whether the sub-table has been written. Understandably, in this step, the standard electronic ledger only completes table structure generation and template loading; the actual writing of data for each table is performed in step S300.

[0055] Further, after the table structure is generated, S200 performs the annual summary initial record generation process. This process reads the unique ledger code and year, and generates an annual summary initial record in the annual emission reduction summary table. The cumulative emission reduction and standard coal savings for the year in the annual summary initial record are first written into the initial status field, and then updated by the associated ledger data after S300 writes them into the monthly emission reduction data collection table. After the annual summary initial record is written, the standardized ledger construction module marks the standard electronic ledger status as "archived" and writes the unique ledger code, standard electronic ledger status, and sub-table template number into the ledger archiving record.

[0056] In the engineering implementation, the public institution code is a field input from the management terminal of a public institution, the library serial number is generated by the registration order of the library name and address under that public institution, and the year comes from the annual field in the monthly emission reduction data. The standardized ledger construction module generates the unique ledger code based on the public institution code, library serial number, and year, and generates 6 sub-tables in the database. Each sub-table is written with the unique ledger code. The basic information table first loads the field templates of library name, address, operating entity, and service scope; the emission reduction project filing table first loads the field templates of project name, emission reduction path, and methodology; the monthly emission reduction data collection table first loads the field templates of month, emission reduction amount, emission factor value, and data source; the third-party verification result table first loads the field templates of verification agency, verification conclusion, and verification date; the green reading service implementation ledger first loads the field templates of activity type, number of participants, and paperless ratio; and the annual emission reduction summary table first loads the field templates of cumulative emission reduction and standard coal savings for the year. After the standard electronic ledger is generated, it enters S300.

[0057] In summary, the technical effects of this step are as follows: Step S200 converts the initial ledger data output by S100 into a unique ledger code and a standard electronic ledger. Step S200 incorporates six sub-tables under the same unique ledger code, forming a database structure for a single-library ledger. The standard electronic ledger generated by S200 serves as direct input for Step S300 to write data into each table and generate related ledger data.

[0058] S300. Write data into each table based on the standard electronic ledger, and generate associated ledger data through the unique ledger code, project name, month, verification date and activity type;

[0059] Specifically, step S300 is executed by the data writing unit of the standardized ledger construction module. Step S300 receives the standard electronic ledger output by step S200 and calls upon the public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, and green reading service implementation data from the ledger initialization data output by step S100. The data writing unit first reads the unique ledger code, and then writes each field into the corresponding sub-table according to the sub-table template number. The library basic information is written into the basic information table, the emission reduction project filing data is written into the emission reduction project filing table, the monthly emission reduction data is written into the monthly emission reduction data collection table, the third-party verification results are written into the third-party verification result table, the green reading service implementation data is written into the green reading service implementation ledger, and the annual emission reduction summary table receives the summary field from the monthly emission reduction data collection table.

[0060] Furthermore, the data writing unit performs table-based writing processing. The basic information table writes the venue name, address, operating entity, and service scope, and also writes the unique ledger code into the same record. The emission reduction project filing form writes the project name, emission reduction path, and methodological basis, and also writes the unique ledger code into the same record. The monthly emission reduction data collection form writes the month, emission reduction amount, emission factor values, and data source, and also writes the unique ledger code and project name into the same record. The third-party verification result form writes the verification agency, verification conclusion, and verification date, and also writes the unique ledger code, project name, and month into the same record. The green reading service ledger writes the activity type, number of participants, and paperless ratio, and also writes the unique ledger code, project name, and month into the same record. The annual emission reduction summary table reads the same unique ledger code and monthly emission reduction data for the same year, generates the cumulative emission reduction amount and standard coal savings for the year, and writes it into the annual summary record.

[0061] Further, S300 performs cross-table association processing. This cross-table association processing generates the associated ledger data using the unique ledger code, project name, month, verification date, and activity type. The basic information table is associated with the emission reduction project filing form, the monthly emission reduction data collection form, the third-party verification result form, the green reading service implementation ledger, and the annual emission reduction summary form using the unique ledger code. The emission reduction project filing form is associated with the monthly emission reduction data collection form using the project name. The monthly emission reduction data collection form is associated with the annual emission reduction summary form using the month. The third-party verification result form is associated with the monthly emission reduction data collection form and the annual emission reduction summary form using the verification date. The green reading service implementation ledger is associated with the monthly emission reduction data collection form using the activity type and month. The data writing unit writes the aforementioned association relationships into the association relationship record.

[0062] Furthermore, the associated ledger data includes in-table data and associated relationship records. The in-table data refers to the fields already written in the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, and annual emission reduction summary table. The associated relationship records refer to the connection relationships between the unique ledger code, project name, month, verification date, and activity type in each sub-table. The data writing unit generates a write status field after completing the associated relationship records. The write status field includes write completion status, duplicate write status, and pending correction status. If duplicate monthly emission reduction data appears under the same unique ledger code, project name, and month, the data writing unit writes the duplicate write status to the associated relationship record and leaves the duplicate field for S400 logical verification calls. If the third-party verification results lack corresponding monthly emission reduction data, the data writing unit writes the pending correction status to the associated relationship record and leaves the pending correction field for S400 logical verification calls.

[0063] In an engineering implementation, a zero-carbon cloud library generates multiple emission reduction project registration data within the same year. The data writing unit writes the project name, emission reduction path, and methodological basis into the emission reduction project registration form. Monthly emission reduction amounts, emission factor values, and data sources are collected and written into the monthly emission reduction data collection form, linked to the emission reduction project registration form by project name. After a third-party verification agency completes its verification in a given month, the data writing unit writes the verification agency, verification conclusion, and verification date into the third-party verification result form, linking the verified monthly emission reduction data by verification date, project name, and month. After a green reading service activity is completed, the data writing unit writes the activity type, number of participants, and paperless ratio into the green reading service implementation ledger, linking the monthly emission reduction data by activity type and month. The aforementioned sub-table data and related relationship records are merged to generate the related ledger data and sent to S400.

[0064] In summary, the technical effect of this step is as follows: S300 converts the standard electronic ledger generated by S200 into associated ledger data containing table data and related relationship records. S300 connects six sub-tables using a unique ledger code, project name, month, verification date, and activity type to form the data structure required for subsequent verification. The associated ledger data output by S300 serves as the direct input for S400 to perform format verification, logical verification, and historical trend verification.

[0065] S400: Perform format verification, logic verification, and historical trend verification based on the associated ledger data, and generate ledger verification results;

[0066] Specifically, S400 is executed by the data integrity verification module. This module receives the associated ledger data output by S300 and reads the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, annual emission reduction summary table, and related relationship records. The data integrity verification module has a built-in three-level verification rule engine. This engine includes format verification rules, logical verification rules, and historical trend verification rules. The format verification rules correspond to field integrity and field type. The logical verification rules correspond to the consistency of related fields between tables and the verification of reasonable emission reduction ranges. The historical trend verification rules compare the current month's emission reduction with historical emission reductions for the same period.

[0067] Furthermore, the format verification is performed by a format verification unit. The format verification unit reads the required fields and field types from the associated ledger data. The required fields include a unique ledger code, institution name, address, operating entity, service scope, project name, emission reduction path, methodological basis, month, emission reduction amount, emission factor value, data source, verification agency, verification conclusion, verification date, activity type, number of participants, paperless ratio, cumulative emission reduction amount for the year, and standard coal savings. The field types include character fields, date fields, and numeric fields. The format verification unit performs null value verification and length verification on character fields, date format verification on date fields, and numeric type verification on numeric fields. If any required field is empty, the format verification unit generates a format verification failure status. If all required fields are complete and their field types are correct, the format verification unit generates a format verification successful record.

[0068] Furthermore, the logical verification is performed by a logical verification unit. The logical verification unit reads the association records, checks whether the unique ledger code in the basic information table is consistent with the unique ledger codes in other sub-tables, checks whether the project name in the emission reduction project filing table is consistent with the project name in the monthly emission reduction data collection table, checks whether the verification date in the third-party verification result table corresponds to the month in the monthly emission reduction data collection table, and checks whether the cumulative emission reduction in the annual emission reduction summary table originates from the monthly emission reduction data collection table under the same unique ledger code. The logical verification unit also reads the emission reduction and emission factor values ​​in the monthly emission reduction data collection table and performs a verification of the reasonable range of emission reductions. If the unique ledger code, project name, month, verification date, or activity type between sub-tables is inconsistent, the logical verification unit generates a logical verification failure status. If the verification of the reasonable range of emission reductions fails, the logical verification unit generates a logical verification failure status and a correction prompt.

[0069] Furthermore, the historical trend verification is performed by a historical trend verification unit. This unit reads the historical emission reductions for the same unique ledger code, project name, and month, and also reads the current month's emission reductions from the current month's emission reduction data collection table. The unit compares the current month's emission reductions with the historical emission reductions for the same period, generating a historical trend verification record. The unit also reads the number of participants and the paperless ratio from the green reading service implementation ledger and compares them with historical data from the same period. If there are abnormal fluctuations in the current month's emission reductions, number of participants, or paperless ratio, the historical trend verification unit generates a historical trend verification failure status and a correction prompt. If historical data for the same period is missing, the unit writes the missing status into the historical trend verification record and submits this record for manual review of the field section, without directly generating a verification success status.

[0070] Further, the data integrity verification module summarizes the format verification records, logic verification records, and historical trend verification records to generate the ledger verification result. The ledger verification result includes a verification pass status, a format verification fail status, a logic verification fail status, and a historical trend verification fail status. When all three verifications (format, logic, and historical trend) are pass records, the data integrity verification module generates a verification pass status and transmits the associated ledger data to S500. When the ledger verification result is a format verification fail status, a logic verification fail status, or a historical trend verification fail status, the data integrity verification module generates a correction prompt, stops generating the ledger version, and writes the correction prompt into the verification record. The correction prompt includes the sub-table name, field name, exception type, and processing status.

[0071] In an engineering implementation, after the monthly emission reduction data collection table of a zero-carbon cloud library is filled with the monthly emission reduction amount and emission factor values, the data integrity verification module first checks whether the emission reduction amount field is empty, whether the emission factor value is a numerical field, and whether the monthly field conforms to the date format. After the format verification passes, the logic verification unit checks whether the monthly emission reduction data has a corresponding project name, whether the verification date in the third-party verification result table covers the month, and whether the annual emission reduction summary table comes from the monthly emission reduction data within the year. After the logic verification passes, the historical trend verification unit reads the same library name, the same project name, and the historical monthly emission reduction for the same period, and compares it with the current month's emission reduction. After all verifications pass, the ledger verification result generates a verification pass status and transmits it to S500.

[0072] In summary, the technical effects of this step are as follows: S400 converts the associated ledger data output by S300 into ledger verification results. S400 checks the six sub-tables and cross-table related fields through format verification, logical verification, and historical trend verification, forming a pre-submission status. The verification pass status output by S400 serves as the trigger input for S500 to generate the ledger version, version hash value, and evidence record.

[0073] S500: Generate a ledger version, version hash value, and evidence record based on the verification pass status in the ledger verification result;

[0074] Specifically, S500 is jointly executed by the version management unit of the blockchain evidence storage module and the standardized ledger construction module. S500 receives the ledger verification result output by S400 and reads the verification pass status from the ledger verification result. Only when the ledger verification result is in the verification pass status does the version management unit read the associated ledger data generated by S300 and generate the ledger version. The ledger version refers to a data object encapsulated under the same unique ledger code, after versioning the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, annual emission reduction summary table, and related relationship records. The ledger version includes a unique ledger code, ledger version number, version generation time, sub-table record summary, and related relationship summary.

[0075] Further, the version management unit generates a ledger version number. The ledger version number consists of a unique ledger code, year, month, and version sequence number. The version sequence number increments within the same unique ledger code, year, and month. The version management unit writes the ledger version number into the version fields of the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, and annual emission reduction summary table. Old ledger versions are fully retained, and new ledger versions are written into the current version field. If the same month's data is processed and re-passed through S400 after correction prompts, the version management unit generates a new ledger version number and writes the previous ledger version number into the version source field.

[0076] Furthermore, the blockchain evidence storage module extracts key data fields from the ledger version. These key data fields include a unique ledger code, ledger version number, project name, month, emission reduction amount, emission factor value, data source, verification conclusion, activity type, number of participants, paperless ratio, cumulative emission reduction amount for the year, and standard coal savings. The blockchain evidence storage module reads the key data fields according to a preset field order and generates field summary data. The field summary data refers to a data record composed of the key data field name, field value, and field order. The blockchain evidence storage module performs hash processing on the field summary data to generate the version hash value. The version hash value is written to the ledger version and used as an input field for S600 to generate the first and second reporting data packets.

[0077] Furthermore, the blockchain evidence storage module generates the evidence storage record based on the ledger version number, the version hash value, the on-chain timestamp, and the node signature. The on-chain timestamp refers to the time field generated when the blockchain evidence storage module submits the version hash value. The node signature refers to the field formed by the node to which the blockchain evidence storage module belongs performing signature processing on the version hash value and the on-chain timestamp. The evidence storage record also includes a unique ledger code and evidence storage status. The evidence storage status includes a stored status, a pending storage status, and an evidence storage error status. If the blockchain evidence storage module returns a pending storage status, the version management unit retains the ledger version and the version hash value, and generates an evidence storage retry record. If the blockchain evidence storage module returns an evidence storage error status, the version management unit stops transmitting reporting fields to the S600 and writes the error reason into the evidence storage error record.

[0078] In an engineering implementation, after the monthly associated ledger data of a zero-carbon cloud library is verified by S400, the version management unit generates a ledger version number and writes the corresponding records from the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, and annual emission reduction summary table into the same ledger version. The blockchain evidence storage module reads the unique ledger code, ledger version number, project name, month, emission reduction, emission factor value, data source, verification conclusion, activity type, number of participants, paperless ratio, cumulative emission reduction for the year, and standard coal savings, generates field summary data, and performs hash processing on the field summary data to generate a version hash value. Subsequently, the blockchain evidence storage module generates an evidence storage record containing the ledger version number, version hash value, on-chain timestamp, and node signature, and transmits the evidence storage record to S600 and S700.

[0079] In summary, the technical effects of this step are as follows: S500 converts the verification pass status of S400 into a ledger version, a version hash value, and a certificate record. S500 establishes the correspondence between the ledger version and the certificate record through key data fields and hash processing. The ledger version, version hash value, and certificate record output by S500 serve as inputs for S600 to generate the first and second reporting data packets.

[0080] S600: Generate first and second reporting data packets based on the ledger version, the version hash value and the evidence record; receive first and second receipt data; and update the bidirectional statistical status.

[0081] Specifically, S600 is executed by a bidirectional reporting engine. The bidirectional reporting engine receives the ledger version, the version hash value, and the evidence record output by S500, and calls the interface configuration output by S100. The interface configuration includes the interface configuration for the local carbon emission statistics platform and the interface configuration for the public institution carbon accounting system. The bidirectional reporting engine reads the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, and annual emission reduction summary table from the ledger version, reads the version hash value, and reads the ledger version number, on-chain timestamp, and node signature from the evidence record. The bidirectional reporting engine uses the aforementioned fields as reporting input fields to generate a first reporting data packet and a second reporting data packet, respectively.

[0082] Furthermore, the bidirectional reporting engine incorporates an adapter layer. This adapter layer includes a local carbon emission statistics platform adapter and a public institution carbon accounting system adapter. The local carbon emission statistics platform adapter reads the local carbon emission statistics platform interface configuration and converts the fields in the ledger version into a first reporting data packet. The public institution carbon accounting system adapter reads the public institution carbon accounting system interface configuration and converts the fields in the ledger version into a second reporting data packet. Both the first and second reporting data packets contain a unique ledger code, a ledger version number, and a version hash value. The first reporting data packet also contains the target system identifier from the local carbon emission statistics platform interface configuration. The second reporting data packet also contains the target system identifier from the public institution carbon accounting system interface configuration.

[0083] Furthermore, the bidirectional reporting engine performs a pre-reporting verification process before generating the reporting data packet. This pre-reporting verification process reads the ledger version number and version hash value from the evidence storage record and compares them with the ledger version number and version hash value in the ledger version. If the comparison matches, the bidirectional reporting engine generates a reporting batch number and writes it into the first and second reporting data packets. If the comparison does not match, the bidirectional reporting engine stops generating reporting data packets and writes the reason for the error into the reporting error record. The reporting batch number is generated from a unique ledger code, ledger version number, target system identifier, and reporting time. The reporting batch number is used for subsequent first and second receipt data write-backs.

[0084] Further, the bidirectional reporting engine submits the first reporting data packet to the local carbon emission statistics platform and receives the first receipt data; it also submits the second reporting data packet to the public institution carbon accounting system and receives the second receipt data. Both the first and second receipt data include the target system identifier, reception status, receipt time, and reason for any anomalies. The reception status includes reception completed, reception failed, and pending confirmation. The reasons for any anomalies include missing fields, incorrect field types, incorrect interface configuration, inconsistent version hash values, and an anomaly returned by the target system. The bidirectional reporting engine writes the first and second receipt data into the receipt record section of the ledger version.

[0085] Further, the bidirectional reporting engine updates the bidirectional data collection status based on the first and second receipt data. If both the first and second receipt data are in a received completion state, the bidirectional reporting engine writes the bidirectional data collection status as a bidirectional received completion state. If either receipt data is in a received failure state or a pending confirmation state, the bidirectional reporting engine writes the bidirectional data collection status as a pending processing state and generates a retry record. The retry record includes the target system identifier, reporting batch number, exception reason, retry time, and retry status. When the received status is empty or the exception reason is not empty, the bidirectional reporting engine generates a retry record and retains the reporting data packet digest of the first or second reporting data packet. The bidirectional data collection status, along with the first and second receipt data, is transmitted to S700.

[0086] In an engineering embodiment, after the ledger version of a zero-carbon cloud library generates a storage record via S500, the bidirectional reporting engine reads the interface configuration of the local carbon emission statistics platform to generate a first reporting data packet; it also reads the interface configuration of the public institution carbon accounting system to generate a second reporting data packet. Both reporting data packets contain a unique ledger code, ledger version number, version hash value, and reporting batch number. After the first reporting data packet is submitted to the local carbon emission statistics platform, the target system returns a first receipt data. After the second reporting data packet is submitted to the public institution carbon accounting system, the target system returns a second receipt data. If the first receipt data is in a received state and the second receipt data is in a pending confirmation state, the bidirectional reporting engine sets the bidirectional inclusion status to a pending processing state and generates a retry record for the public institution carbon accounting system. If both receipt data are in a received state, the bidirectional reporting engine sets the bidirectional inclusion status to a bidirectional received state and transmits the data to S700.

[0087] In summary, the technical effects of this step are as follows: S600 converts the ledger version, version hash value, and evidence record output by S500 into a first reporting data packet and a second reporting data packet. S600 receives the first and second receipt data through a bidirectional reporting engine and writes the receipt fields into the ledger version. The bidirectional statistical status and receipt records output by S600 serve as direct inputs for S700 to generate historical version comparison results and assessment supporting materials.

[0088] S700. Based on the bidirectional statistical status and the evidence record, generate historical version comparison results and assessment supporting materials.

[0089] Specifically, S700 is jointly executed by the blockchain evidence storage module, the version management unit, and the intelligent early warning and compliance review module. S700 receives the bidirectional statistical status, first receipt data, and second receipt data output by S600, and reads the evidence storage record generated by S500. The evidence storage record includes the ledger version number, version hash value, on-chain timestamp, and node signature. The version management unit reads the current ledger version and historical ledger versions. The current ledger version refers to the ledger version most recently generated by S500 and whose bidirectional statistical status was updated by S600. The historical ledger version refers to the ledger version generated and retained before the current ledger version under the same unique ledger code.

[0090] Furthermore, the version management unit performs historical version reading processing. This historical version reading processing retrieves historical ledger versions based on a unique ledger code, project name, month, and ledger version number. The historical ledger versions include historical records of basic information tables, emission reduction project filing tables, monthly emission reduction data collection tables, third-party verification result tables, green reading service implementation ledgers, annual emission reduction summary tables, and related relationship records. The version management unit extracts key data fields from the historical ledger versions and generates historical field summary data according to the same preset field order in S500. The blockchain notarization module performs hash processing on the historical field summary data to generate a version hash value for the historical ledger version.

[0091] Furthermore, the blockchain evidence storage module performs hash value comparison processing. This comparison compares the version hash value of the current ledger version with the version hash value in the corresponding evidence storage record, and also compares the version hash value of historical ledger versions with the version hash value in the corresponding evidence storage record. If the version hash value of the current ledger version matches the version hash value in the evidence storage record, and the version hash value of a historical ledger version matches the version hash value in its corresponding evidence storage record, the blockchain evidence storage module generates a matching record. If any version hash value is inconsistent, the blockchain evidence storage module generates a matching exception record and writes the ledger version number, unique ledger code, source of the exception field, discovery time, and node signature into the exception record section.

[0092] Furthermore, the version management unit generates the historical version comparison results based on the consistent comparison records or the abnormal comparison records. The historical version comparison results include the current ledger version number, the historical ledger version number, the version hash value of the current ledger version, the version hash value of the historical ledger version, the version hash value in the evidence storage record, the comparison status, and the abnormal record segment. If the comparison status is abnormal, the intelligent early warning and compliance review module generates tampering alarm information. The tampering alarm information includes a unique ledger code, ledger version number, source of the abnormal field, discovery time, node signature, and processing status. The tampering alarm information is written to the alarm record segment of the ledger version and is associated with and saved in relation to the bidirectional statistical status.

[0093] Further, the intelligent early warning and compliance review module generates the assessment supporting materials based on the bidirectional statistical status, the evidence storage records, the historical version comparison results, the first receipt data, and the second receipt data. The assessment supporting materials include a standard electronic ledger summary, a ledger verification result summary, a first submission data packet summary, a second submission data packet summary, first receipt data, second receipt data, bidirectional statistical status, evidence storage records, historical version comparison results, and tampering alarm information. The standard electronic ledger summary comes from S200 and S300. The ledger verification result summary comes from S400. The evidence storage records come from S500. The submission data packet summary, receipt data, and bidirectional statistical status come from S600. The historical version comparison results come from this step. The intelligent early warning and compliance review module writes the aforementioned content into the same material number and generates the material generation time and material version number.

[0094] Furthermore, after the assessment supporting materials are generated, the intelligent early warning and compliance review module writes the material number, unique ledger code, ledger version number, two-way statistical status, evidence record number, and historical version comparison results into the export record. The export record is used for subsequent queries and verification. If the two-way statistical status is pending, the intelligent early warning and compliance review module writes a pending status field and a retry record summary into the assessment supporting materials. If the historical version comparison results contain comparison anomaly records, the intelligent early warning and compliance review module writes tampering alarm information into the assessment supporting materials. If the two-way statistical status is two-way reception completed, and the historical version comparison results are comparison consistent records, the intelligent early warning and compliance review module sets the assessment supporting materials status to exportable.

[0095] In an engineering embodiment, a public institution invokes S700 before its annual assessment. The version management unit reads the current ledger version and the previous historical ledger version of the zero-carbon cloud library. The blockchain evidence storage module generates the version hash value of the current ledger version and the version hash value of the historical ledger version according to the same key data fields and preset fields as in S500, and compares them with the version hash value in the evidence storage record. If the comparison matches, a historical version comparison result is generated. The intelligent early warning and compliance review module reads the two-way statistical status, the first receipt data, the second receipt data, the evidence storage record, and the historical version comparison result, and generates assessment supporting materials containing a standard electronic ledger summary, a ledger verification result summary, a reporting data packet summary, receipt data, two-way statistical status, evidence storage record, and the historical version comparison result. If the version hash value of the historical ledger version is inconsistent with the version hash value in the evidence storage record, the intelligent early warning and compliance review module generates a tampering alarm message and writes the tampering alarm message into the assessment supporting materials.

[0096] In summary, the technical effects of this step are as follows: S700 connects the bidirectional statistical status output by S600 and the evidence storage record output by S500 to form a historical version comparison result. S700 generates a comparison status by comparing the version hash values ​​of the current ledger version and the historical ledger version, and generates a tampering alarm message when an anomaly occurs. S700 compiles the standard electronic ledger, ledger verification results, receipt data, bidirectional statistical status, evidence storage record, and historical version comparison result into supporting materials for assessment, completing the data loop from S100 to S700.

[0097] Example 2: Figure 2 This diagram illustrates a structural block diagram of a zero-carbon cloud library emission reduction ledger and two-way statistical system according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0098] The standardized ledger construction module 01 is used to acquire information from public institutions, basic library information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configurations, and evidence storage rules. It generates initial ledger data and, based on this initial data, generates a unique ledger code and a standard electronic ledger. Specifically, the standardized ledger construction module receives public institution information from the public institution management terminal, basic library information from the library management terminal, emission reduction project filing data from the emission reduction project filing terminal, monthly emission reduction data from the monthly emission reduction data collection terminal, third-party verification results from the third-party verification result entry terminal, and green reading service implementation data from the green reading service implementation data entry terminal. It also receives interface configurations from the local carbon emission statistics platform, the public institution carbon accounting system, and evidence storage rules. The standardized ledger construction module performs source registration, field name unification, field type conversion, date format unification, and monthly field standardization processing on the aforementioned input objects to form the initial ledger data. The standardized ledger construction module reads the public institution code, library serial number, and year from the ledger initialization data, generates a unique ledger code, and establishes a standard electronic ledger under this unique ledger code. The standard electronic ledger includes a basic information table, an emission reduction project filing table, a monthly emission reduction data collection table, a third-party verification result table, a green reading service implementation ledger, and an annual emission reduction summary table. The standardized ledger construction module sends the standard electronic ledger to the data writing and association module, and retains the interface configuration and evidence storage rules from the ledger initialization data for subsequent calls.

[0099] The data writing and association module 02, connected to the standardized ledger construction module, is used to write data into each table based on the standard electronic ledger, and generate associated ledger data through the unique ledger code, project name, month, verification date, and activity type. Specifically, the data writing and association module receives the standard electronic ledger and the ledger initialization data from the standardized ledger construction module. The data writing and association module writes basic library information into the basic information table, emission reduction project filing data into the emission reduction project filing table, monthly emission reduction data into the monthly emission reduction data collection table, third-party verification results into the third-party verification result table, and green reading service implementation data into the green reading service implementation ledger. It also generates the cumulative emission reduction and standard coal savings for the year in the annual emission reduction summary table based on the monthly emission reduction data collection table. The data writing and association module synchronously writes the unique ledger code when writing data to each table, and establishes associations between the basic information table and other tables through the unique ledger code. It establishes associations between the emission reduction project filing table and the monthly emission reduction data collection table by project name, between the monthly emission reduction data collection table and the annual emission reduction summary table by month, between the third-party verification result table and the monthly emission reduction data collection table and the annual emission reduction summary table by verification date, and between the green reading service implementation ledger and the monthly emission reduction data collection table by activity type. The data writing and association module encapsulates the data and association records of each table into associated ledger data and sends the associated ledger data to the data integrity verification module.

[0100] The data integrity verification module 03, connected to the data writing and association module, is used to perform format verification, logical verification, and historical trend verification based on the associated ledger data, and generate ledger verification results. Specifically, the data integrity verification module receives the associated ledger data from the data writing and association module and reads the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, annual emission reduction summary table, and relationship records. The data integrity verification module performs format verification on the associated ledger data, verifying the integrity of required fields, the correctness of data types, and the date format. The data integrity verification module performs logical verification on the associated ledger data, verifying the consistency of associated fields between tables, and performing reasonable range verification on the emission reduction in the monthly emission reduction data collection table. The data integrity verification module performs historical trend verification on the associated ledger data, comparing the current month's emission reduction with the historical emission reduction for the same period, and comparing the green reading service implementation data with historical data for the same period. The data integrity verification module summarizes the format verification records, logical verification records, and historical trend verification records to generate ledger verification results. The ledger verification results include verification passed, format verification failed, logic verification failed, and historical trend verification failed. The data integrity verification module sends the ledger verification results containing the verification passed status to the blockchain notarization module, and writes the correction prompts corresponding to the failed status into the verification record.

[0101] The blockchain evidence storage module 04, connected to the data integrity verification module, is used to generate a ledger version, a version hash value, and an evidence storage record based on the verification pass status in the ledger verification result. Specifically, the blockchain evidence storage module receives the ledger verification result from the data integrity verification module and reads the verification pass status in the ledger verification result. When the ledger verification result is in the verification pass status, the blockchain evidence storage module reads the associated ledger data and encapsulates the basic information table, emission reduction project filing table, monthly emission reduction data collection table, third-party verification result table, green reading service implementation ledger, annual emission reduction summary table, and related relationship records into a ledger version. The blockchain evidence storage module extracts a unique ledger code, ledger version number, project name, month, emission reduction, emission factor value, data source, verification conclusion, activity type, number of participants, paperless ratio, cumulative emission reduction for the year, and standard coal savings from the ledger version, and performs hash processing on the aforementioned key data fields to generate a version hash value. The blockchain evidence storage module generates evidence storage records based on the ledger version number, version hash value, on-chain timestamp, and node signature. The blockchain evidence storage module sends the ledger version, the version hash value, and the evidence storage record to the bidirectional reporting engine, and retains historical ledger versions for the compliance review module to use.

[0102] The bidirectional reporting engine 05, connected to the blockchain evidence storage module, is used to generate first and second reporting data packets based on the ledger version, the version hash value, and the evidence storage record, receive first and second receipt data, and update the bidirectional reporting status. Specifically, the bidirectional reporting engine receives the ledger version, the version hash value, and the evidence storage record from the blockchain evidence storage module, and calls the interface configuration reserved by the standardized ledger construction module. The bidirectional reporting engine reads the interface configuration of the local carbon emission statistics platform and generates the first reporting data packet according to the ledger version. The bidirectional reporting engine reads the interface configuration of the public institution carbon accounting system and generates the second reporting data packet according to the ledger version. Both the first and second reporting data packets are written with a unique ledger code, ledger version number, version hash value, and reporting batch number. The bidirectional reporting engine submits the first reporting data packet to the local carbon emission statistics platform and receives the first receipt data. The bidirectional reporting engine submits the second reporting data packet to the public institution carbon accounting system and receives the second receipt data. Both the first and second receipt data include the target system identifier, reception status, receipt time, and reason for the exception. The bidirectional reporting engine writes the first and second receipt data into the receipt record section of the ledger version and updates the bidirectional statistical status based on the reception status and the reason for the exception. The bidirectional reporting engine sends the bidirectional statistical status, the first and second receipt data to the compliance review module and retains the retry record corresponding to the reporting exception in the receipt record section.

[0103] The compliance review module 06, connected to the two-way reporting engine and the blockchain evidence storage module, is used to generate historical version comparison results and assessment supporting materials based on the two-way statistical status and the evidence storage records. Specifically, the compliance review module receives the two-way statistical status, the first receipt data, and the second receipt data from the two-way reporting engine, and receives the evidence storage records, the current ledger version, and the historical ledger version from the blockchain evidence storage module. The compliance review module reads the key data fields in the current ledger version and generates a hash value for the current version according to the hash processing method of the blockchain evidence storage module. The compliance review module reads the key data fields in the historical ledger version and generates a hash value for the historical version according to the same processing method. The compliance review module compares the current version hash value with the version hash value in the evidence storage record, and compares the historical version hash value with the version hash value in the corresponding evidence storage record to generate historical version comparison results. The compliance review module reads the standard electronic ledger, the ledger verification result, the first reporting data packet, the second reporting data packet, the first receipt data, the second receipt data, the two-way statistical status, the evidence storage record, and the historical version comparison result to generate assessment supporting materials. The compliance review module writes the material number, unique ledger code, ledger version number, two-way statistical status, and historical version comparison result of the assessment supporting materials into an export record, and associates and saves the export record with the unique ledger code in the standardized ledger construction module.

Claims

1. A method for establishing a zero-carbon cloud library emission reduction ledger and two-way statistical reporting, characterized in that... include: S100: Obtain multi-source information, perform field standardization and encapsulation processing, and generate ledger initialization data; The multi-source information includes: public institution information, library basic information, emission reduction project filing data, monthly emission reduction data, third-party verification results, green reading service implementation data, interface configuration and evidence storage rules; S200. Based on the ledger initialization data, perform loading processing to generate a unique ledger code and a standard electronic ledger; The standard electronic ledger includes a basic information table, an emission reduction project filing table, a monthly emission reduction data collection table, a third-party verification result table, a green reading service implementation ledger, and an annual emission reduction summary table. S300. Write data into each table based on the standard electronic ledger, and generate associated ledger data through the unique ledger code, project name, month, verification date and activity type; S400. Based on the associated ledger data, perform format verification, logic verification, and historical trend verification to generate ledger verification results. S500: Generate a ledger version, version hash value, and evidence record based on the verification pass status in the ledger verification result; S600: Based on the ledger version, the version hash value, and the evidence record, perform verification processing, generate the first and second reporting data packets, receive the first and second receipt data, and update the bidirectional statistical status. S700. Based on the bidirectional statistical status and the evidence record, perform hash value comparison processing to generate historical version comparison results and assessment supporting materials.

2. The method according to claim 1, characterized in that, The interface configuration includes the interface configuration of the local carbon emission statistics platform and the interface configuration of the public institution carbon accounting system. The unique ledger code consists of the public institution code, the library serial number and the year.

3. The method according to claim 1, characterized in that, The basic information table includes the name, address, operating entity, and service scope of the venue; the emission reduction project filing form includes the project name, emission reduction path, and methodological basis; the monthly emission reduction data collection form includes the emission reduction amount, emission factor values, and data source; the third-party verification result form includes the verification agency, verification conclusion, and verification date; the green reading service implementation ledger includes the activity type, number of participants, and paperless ratio; and the annual emission reduction summary table includes the cumulative emission reduction amount and standard coal savings for the year.

4. The method according to claim 1, characterized in that, In the associated ledger data, the basic information table is associated with the emission reduction project filing form, the monthly emission reduction data collection form, the third-party verification result form, the green reading service implementation ledger, and the annual emission reduction summary form through the unique ledger code; the emission reduction project filing form is associated with the monthly emission reduction data collection form through the project name; and the third-party verification result form is associated with the monthly emission reduction data collection form and the annual emission reduction summary form through the verification date.

5. The method according to claim 1, characterized in that, The format validation includes validation of the integrity of required fields and validation of the correctness of data types; the logical validation includes validation of the consistency of related fields between tables and verification of reasonable ranges for emission reductions; the historical trend validation includes a comparison of the emission reductions for the current month with the emission reductions for the same period in history.

6. The method according to claim 1, characterized in that, The ledger verification results include verification passed, format verification failed, logic verification failed, and historical trend verification failed. When the ledger verification result is format verification failed, logic verification failed, or historical trend verification failed, a correction prompt is generated, and the generation of the ledger version is stopped.

7. The method according to claim 1, characterized in that, The key data fields include a unique ledger code, ledger version number, project name, month, emission reduction, emission factor value, data source, verification conclusion, activity type, number of participants, paperless ratio, cumulative emission reduction for the year, and standard coal savings; the key data fields are hashed to generate the version hash value; the evidence record includes the ledger version number, the version hash value, the on-chain timestamp, and the node signature.

8. The method according to claim 2, characterized in that, In S600, the first reporting data packet is generated based on the interface configuration of the local carbon emission statistics platform, and the second reporting data packet is generated based on the interface configuration of the public institution carbon accounting system; both the first reporting data packet and the second reporting data packet are written with the unique ledger code, the ledger version number and the version hash value.

9. The method according to claim 1, characterized in that, Both the first receipt data and the second receipt data include the target system identifier, receiving status, receipt time, and reason for the exception; when the receiving status is empty or the reason for the exception is not empty, a retry record is generated; the historical version comparison result is generated by comparing the version hash value of the current ledger version with the version hash value of the historical ledger version.

10. A zero-carbon cloud library emission reduction ledger and two-way statistical system, applied to the method of any one of claims 1 to 9, characterized in that, include: The system includes a standardized ledger construction module, a data writing and association module, a data integrity verification module, a blockchain evidence storage module, a two-way reporting engine, and a compliance review module.

Images