Building carbon emission credible authentication method and system fusing Internet of Things and alliance chain

Abstract

The invention discloses a building carbon emission credible authentication method and system fusing the Internet of Things and an alliance chain, and belongs to the technical field of block chains, the Internet of Things and carbon emission management, and the method comprises the following steps: S1, introducing a multi-channel mechanism, and constructing an alliance chain network; s2, building energy consumption original data and basic building information are collected to form uplink data, and signature authentication is carried out; s3, each energy supply enterprise submits the data subjected to signature authentication to an alliance chain network through an on-chain API interface for integrity verification, and after verification is passed, the data subjected to signature authentication form a solidified storage evidence through a multi-node consensus mechanism; s4, on the basis of an intelligent contract authentication rule, performing authentication on the solidified and stored uplink building data; and S5, the building carbon emission intensity of the energy supply enterprise is calculated, and a calculation result and corresponding original data are bound and written into the alliance chain. According to the invention, the whole-process credible acquisition, authentication and supervision of the building carbon emission data are realized, and the carbon management efficiency and the data transparency are improved.

Description

Technical Field

[0001] This invention relates to the fields of blockchain, Internet of Things (IoT) and carbon emission management technology, and in particular to a trusted authentication method and system for building carbon emissions that integrates IoT and consortium blockchain. Background Technology

[0002] Buildings consume enormous amounts of energy during their operation and are a major source of urban carbon emissions. Currently, the collection of building carbon emission information mainly relies on manual reporting by energy-consuming units or third-party organizations, lacking a unified technical platform and data source control mechanism. This results in opaque information sources and difficulty in ensuring data authenticity. Traditional building carbon emission data management depends on centralized platforms, which are easily tampered with and falsified. Once the database is attacked or human intervention occurs, it could cause significant disruption to government regulation and the carbon trading system.

[0003] The building carbon emission verification process involves multiple stakeholders, including water, electricity, and gas suppliers, as well as third-party verification agencies. Inconsistent data collection methods and format standards among these agencies lead to inconsistent data formats and incompatible interfaces, severely impacting data integration and utilization, and hindering the systematic analysis and monitoring capabilities of carbon emission information. In the absence of a unified collaborative management platform, data fragmentation among participants results in low information transmission efficiency, long verification cycles, and high management costs.

[0004] Therefore, there is an urgent need for a solution to address core issues such as unreliable information sources, easily tampered data, low efficiency of multi-party collaboration, inconsistent standards, non-standard management of carbon emission factors, and insufficient intelligence in verification methods, in order to improve the credibility, security, and regulatory effectiveness of building carbon emission data management. Summary of the Invention

[0005] The purpose of this invention is to provide a trusted authentication method and system for building carbon emissions that integrates the Internet of Things and consortium blockchain, so as to realize the trusted collection, authentication and supervision of building carbon emission data throughout the entire process, and improve carbon management efficiency and data transparency.

[0006] To achieve the above objectives, this invention provides a method and system for trusted authentication of building carbon emissions that integrates the Internet of Things and consortium blockchain, comprising:

[0007] A trusted authentication method for building carbon emissions that integrates the Internet of Things and consortium blockchain includes the following steps:

[0008] S1 introduces a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes.

[0009] S2 collects raw building energy consumption data from energy supply companies and basic building information of the buildings being supplied with energy, forming unified standard on-chain data and performing signature authentication.

[0010] S3, each energy supply company submits the signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency performs integrity verification on all the building data that has been uploaded to the blockchain. After the verification is passed, the signed and authenticated data is used to form an immutable solidified evidence through a multi-node consensus mechanism.

[0011] S4, based on the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network, authenticates the solidified and stored on-chain building data;

[0012] Once certified, the contract writes a certified identifier, triggering the S5 carbon intensity calculation;

[0013] If authentication fails, the reason for the failure will be recorded and fed back to the corresponding energy supplier through the on-chain notification mechanism for correction.

[0014] S5 calculates the building carbon emission intensity of energy supply companies, binds the calculation results with the corresponding original data and writes them onto the consortium blockchain for real-time verification by verification agencies or government regulatory platforms.

[0015] Preferably, S2 specifically includes:

[0016] S21, IoT devices deployed inside the building collect raw building energy consumption data from energy supply companies and generate the following structure:

[0017]

[0018] In the formula, This is the raw energy consumption data packet for energy type x at time point t; MeterID is the unique identifier of the metering device, used to identify the data source device; Reading t The energy consumption reading is at time point t; Δt is the reading period; Sign device Signing for smart devices;

[0019] S22, Perform source node identity signature and hash encryption processing on the collected data:

[0020] H data =Hash(B i ‖M j ||V i,j ||T l ||Sign node );

[0021] In the formula, H data The final generated data hash digest is used for on-chain identification, authentication, and traceability; Hash is the hash function; B i M is the unique identifier for the i-th building; j Number the j-th meter; Vi,j The periodic usage data corresponding to instrument number j for building i, including raw energy consumption data packages for various energy sources at each point in time. T l The l-th time series identifier; Sign node A digital signature generated by the uploading node using its private key;

[0022] S23 combines the source node's identity signature with the hash-encrypted data according to four dimensions: building identity, metering equipment, energy supply unit, and time, to form standardized on-chain data.

[0023] D i,j,k,l ={B i M j C k ,T l};

[0024] In the formula, D i,j,k,l B is the only logical location path for carbon emission data; i M is the unique identifier for the i-th building; j Number the j-th meter; C k Code the kth energy supplier; T l This is the identifier for the l-th time series.

[0025] S24, perform initial reading verification and table number binding authentication on the standardized on-chain data, confirming the following logic:

[0026]

[0027] In the formula, Verify(M j B i ) represents the j-th metering device M j With the i-th building B i Verify the binding relationship between them; M j Number the j-th meter; B i The unique number of the i-th building;

[0028] S25, Verify (M) j B i If ) = 0, authentication fails. The failed authentication data is recorded in the off-chain abnormal data buffer and an abnormal identifier is attached. Such data must not be directly entered into the main chain ledger. At the same time, an audit record is generated, and the energy supply company that uploaded the data is automatically notified to bind and review or correct the data.

[0029] Verify(M j B i If ) = 1, authentication is successful, a digital signature is generated, and the data is marked as authenticated.

[0030] Preferably, S3 specifically includes:

[0031] S31, the verification agency adds a timestamp to all signed and authenticated on-chain building data to form a complete on-chain record of building carbon emission data:

[0032] TX n ={ID building ID meter ,T,V,EF,H data wSign node};

[0033] In the formula, TX n Record a complete building carbon emission data on the blockchain; ID building ID is the basic unit identifier for carbon emission attribution. meter The energy type is identified by: T for timestamp; V for energy consumption reading; EF for carbon emission factor; H for energy type. data For the final generated data hash digest; Sign node Sign the uploader's identity;

[0034] S32, based on the complete on-chain record of building carbon emission data, performs integrity verification on the final generated data hash digest and uploader identity signature to ensure that there is no on-chain pollution or forged data;

[0035] S33. After the data integrity verification is completed, the multi-node consensus mechanism process is automatically triggered. Data that successfully passes the consensus will be written into the consortium blockchain ledger to form an immutable solidified evidence.

[0036] Preferably, in S4, the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network include:

[0037] Meter number matching: Verify meter number M j Is it bound to the building ID?

[0038] Numerical rationality assessment: Is the monthly emission intensity of the building data too high or too low?

[0039] Time continuity assessment: Whether the data upload period is a continuous time period;

[0040] Signature validity verification: Verify the digital signature using the node's public key.

[0041] Preferably, in S5, the building carbon emission intensity of energy supply enterprises is calculated using the following formula:

[0042]

[0043] EF x,n={ID x Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer};

[0044] T effective =T publish +ΔT;

[0045] In the formula, EI i Let be the carbon emission intensity per unit area of ​​the i-th building; Let A be the total carbon emissions of the i-th building; i Q represents the building area of ​​the i-th building; i,x Value represents the amount of energy of type x used in the i-th building; layest This is the current effective version of carbon emission accounting; EF x,n-1 For energy category x, record the (n-1)th carbon emission factor; EF x,n This is the record for the nth carbon emission factor of energy type x; t is the current time; T publish For the release time of carbon emission factors; T effective For the actual effective time of carbon emission factors; ID x For identifying energy type x; Value x Let T be the carbon emission factor value for energy type x; expire H(T) is the carbon emission factor failure time. x ) is the hash check value of the carbon emission factor content for energy type x; N issuer The authoritative node number for publishing carbon emission factors; ΔT is the transition period set by the system.

[0046] A trusted building carbon emission authentication system integrating the Internet of Things and consortium blockchain includes the following modules:

[0047] Consortium blockchain network construction module: Introduces a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes;

[0048] Signature authentication module: Collects raw building energy consumption data from energy supply companies and basic building information of the buildings being supplied with energy, forms unified standard on-chain data, and performs signature authentication;

[0049] Verification and Evidence Preservation Module: Each energy supply company submits the signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency performs integrity verification on all the building data that has been uploaded to the blockchain. After the verification is passed, the signed and authenticated data is used to form an immutable solidified evidence through a multi-node consensus mechanism.

[0050] Smart contract authentication module: Based on the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network, it authenticates the solidified and stored on-chain building data;

[0051] Once authentication is successful, the contract will write the authentication identifier, triggering the carbon emission intensity calculation module to calculate the carbon emission intensity.

[0052] If authentication fails, the reason for the failure will be recorded and fed back to the corresponding energy supplier through the on-chain notification mechanism for correction.

[0053] Carbon emission intensity calculation module: Calculates the building carbon emission intensity of energy supply enterprises, binds the calculation results with the corresponding original data and writes them to the consortium blockchain for real-time verification by verification agencies or government regulatory platforms.

[0054] Preferably, the signature authentication module includes a data structure generation unit, a data processing unit, an on-chain data formation unit, an authentication logic confirmation unit, and an authentication result judgment unit;

[0055] Data Structure Generation Unit: IoT devices deployed inside the building collect raw building energy consumption data from energy supply companies and generate the following structure:

[0056]

[0057] Data processing unit: Performs source node identity signature and hash encryption processing on all collected data.

[0058] H data =Hash(B i ‖M j ||V i,j ||T l ||Sign node );

[0059] On-chain data formation unit: The source node identity signature and hash-encrypted data are combined according to four dimensions: building identity, metering equipment, energy supply unit, and time, to form standardized on-chain data.

[0060] D i,j,k,l ={B i M j C k ,T l};

[0061] Authentication logic confirmation unit: Performs initial reading verification and table number binding authentication on the unified standard on-chain data, confirming the following logic:

[0062]

[0063] Authentication result judgment unit: Verify(M) j B i If ) = 0, authentication fails. The system records this data in the off-chain abnormal data buffer and adds an abnormal identifier. This type of data must not be directly entered into the main chain ledger. At the same time, an audit record is generated, and the energy supply company that uploaded this data is automatically notified to bind and review or correct the data.

[0064] Verify(M j B i If ) = 1, authentication is successful, a digital signature is generated, and the data is marked as authenticated.

[0065] Preferably, the verification and evidence storage module includes an on-chain record formation unit, an integrity verification unit, and a multi-node consensus unit;

[0066] On-chain record formation unit: The verification agency adds a timestamp to all signed and authenticated on-chain building data to form a complete on-chain record of building carbon emission data.

[0067] TX n ={ID building ID meter ,T,V,EF,H data Sign node};

[0068] Integrity verification unit: Based on the complete on-chain record of building carbon emission data, it performs integrity verification on the final generated data hash digest and uploader identity signature to ensure that there is no on-chain contamination or forged data;

[0069] Multi-node consensus unit: After the data integrity verification is completed, the system automatically triggers the multi-node consensus mechanism process. Data that successfully passes the consensus will be written into the consortium blockchain ledger to form an immutable solidified evidence.

[0070] Preferably, in the smart contract authentication module, the smart contract authentication rules pre-deployed by the government management department in the consortium blockchain network include:

[0071] Meter number matching: Verify meter number M j Is it bound to the building ID?

[0072] Numerical rationality assessment: Is the monthly emission intensity of the building data too high or too low?

[0073] Time continuity assessment: Whether the data upload period is a continuous time period;

[0074] Signature validity verification: Verify the digital signature using the node's public key.

[0075] Preferably, in the carbon emission intensity calculation module, the building carbon emission intensity of energy supply enterprises is calculated using the following formula:

[0076]

[0077] EF x,n ={ID x Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer};

[0078] T effective =T publish +ΔT.

[0079] Therefore, the present invention employs the above-mentioned trusted authentication method and system for building carbon emissions that integrates the Internet of Things and consortium blockchain, achieving the following beneficial effects compared to existing technologies:

[0080] 1. This invention introduces a multi-channel mechanism to construct a consortium blockchain network with government management departments as super nodes, qualified verification agencies, and energy supply companies as ordinary nodes. This invention leverages the multi-channel mechanism to ensure business isolation and privacy security. Targeting building operation scenarios, it achieves multi-entity collaboration, starting from data source governance, and constructs a consortium blockchain trust system covering supervision, verification, energy supply, operation, and public participation. Through a unified technical platform and data source control mechanism, it achieves reliable collection, authentication, and supervision of building carbon emission data throughout the entire process, improving carbon management efficiency and data transparency, ensuring data authenticity, and is applicable to scenarios such as carbon quota management, green building verification, and carbon trading support.

[0081] 2. When collecting raw building energy consumption data from energy-supplying enterprises and basic building information of the buildings being supplied with energy, this invention, on the one hand, introduces a "four-dimensional structure" data organization model to index and track carbon emission-related data for any time period, any building, and any energy source by establishing unified data collection methods and format standards, thereby achieving dimensional uniformity and data traceability; on the other hand, through data signature authentication, it ensures that the entire process of carbon emission data from collection, authentication, on-chain processing to querying is authentic, complete, and traceable, promoting data integration and utilization, achieving standardization, real-time performance, and traceability of factor calls, and improving the systematic analysis and supervision capabilities of carbon emission information systems.

[0082] 3. On the one hand, this invention enables verification agencies to perform integrity verification and solidify evidence for all on-chain building data, supports version retrospection and comparison of differences before and after, provides verification agencies with verifiable chain certificates, and realizes data access control and automatic verification through smart contracts. Through the integrated application of blockchain and the Internet of Things, a trusted data chain for building carbon emissions is constructed, achieving trusted support throughout the entire process from data source to regulatory application. On the other hand, this invention supports carbon factor transition cycle management, avoiding data gaps or accounting errors caused by changes in carbon emission factors, giving the alliance system high reliability, flexible configuration, and closed-loop management throughout the entire process. This enhances the credibility, security, and regulatory effectiveness of building carbon emission data management.

[0083] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0084] Figure 1 This is an overall flowchart of the method of the present invention;

[0085] Figure 2 This is an architecture diagram of the consortium blockchain network in Example 1;

[0086] Figure 3 This is a schematic diagram of the node responsibilities in the consortium blockchain network of Example 1;

[0087] Figure 4 This is a flowchart of data acquisition and authentication in Example 1;

[0088] Figure 5 Here is a logic diagram for smart contract authentication in Example 1;

[0089] Figure 6 This is a flowchart of carbon emission calculation and verification for Example 1;

[0090] Figure 7 This is a structural diagram of the system of the present invention. Detailed Implementation

[0091] To make the objectives, technical solutions, and advantages disclosed in the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of the present invention and are not intended to limit the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort are within the scope of protection of this application. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout.

[0092] It should be noted that the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion, such that a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such processes, methods, products, or devices.

[0093] Similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0094] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship in which the product of this invention is usually placed when in use. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting this invention.

[0095] In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," and "connect" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0096] Example 1

[0097] like Figure 1 As shown, this embodiment provides a trusted authentication method for building carbon emissions that integrates the Internet of Things and consortium blockchain, including the following steps:

[0098] S1 introduces a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes.

[0099] A consortium blockchain network architecture with multi-party participation, such as Figure 2As shown, the network comprises nodes from government management departments, qualified verification agencies, and energy supply companies such as water, electricity, and gas companies, forming a multi-party collaborative node network. This architecture is built on consortium blockchain platforms such as Hyperledger Fabric, providing strong access control, identity authentication, and channel isolation capabilities, making it adaptable to complex government-enterprise collaboration scenarios. In the consortium blockchain design, node identities are identified using the MSP mechanism, and a registration center and certificate center are used for permission configuration and trusted communication assurance.

[0100] The consortium blockchain network system, based on the principles of hierarchical access control and data trustworthiness, clearly defines the responsibilities of different nodes. Each node assumes its corresponding responsibilities according to its functional role in the building carbon emission management system. The responsibilities of various nodes in the consortium blockchain network are as follows: Figure 3 As shown, government management departments are designated as super nodes, possessing core functions such as on-chain network access control, node identity registration and revocation management, smart contract deployment and version updates, and the release and supervision of building carbon emission factors. Super nodes have high access control capabilities and are the governance core of the consortium blockchain's trusted system.

[0101] Energy suppliers such as water, electricity, and gas companies, as well as third-party verification agencies, are designated as ordinary nodes. They are responsible for collecting raw building energy consumption data and basic building information within their respective areas, and for initially signing and submitting the data. Ordinary nodes are the primary producers and primary responsible parties for carbon emission data, and their actions are subject to the automatic verification of smart contracts and the verification mechanism of regulatory nodes.

[0102] Building operators and authorized public access terminals are designated as client nodes. These client nodes have read-only or controlled access permissions, primarily used for non-write operations such as information browsing, viewing authentication results, and downloading reports. This multi-role structure achieves logical division of labor and audit collaboration through smart contracts, significantly reducing cross-organizational collaboration costs and fulfilling the system's management requirements of being "governable, supervised, and accountable."

[0103] To ensure the security, specificity, and principle of least privilege in information exchange between different entities within the system, a multi-channel mechanism is introduced within the consortium blockchain structure. Data from each type of participant is isolated and processed in a dedicated channel. These channels are logically independent but physically managed by the consortium blockchain, thereby enhancing the controllability and isolation of data flow. This mechanism not only reduces the risk of data leakage but also strengthens the audit and traceability capabilities of data usage. The channels are divided according to their business functions as follows:

[0104] Channel A (Government – ​​Verification Agency – Operator): Used for the carbon emission certification process, including the submission of carbon data by building units, verification signatures by third-party agencies, compliance confirmation and block recording by government regulatory nodes. This channel focuses on data authenticity and compliance status management.

[0105] Channel B (Government – ​​Energy Supplier): Used for uploading periodic energy consumption data, including the collection and synchronization of data on electricity, water, and gas consumption. This channel supports integration with building energy consumption monitoring systems and metering platforms to ensure the quality of the data source for carbon emission factor calculation.

[0106] Channel C (Government-Public): Provides transparent disclosure and query services for statistical information, carbon intensity indicators, and compliance status results. Data within this channel is generated from contract-extracted summaries, retaining only information relevant to public transparency to ensure confidentiality. To guarantee the authenticity and compliance of data queried by the public, data used for public disclosure in Channel C, such as carbon emission intensity per unit area, compliance status, and rating results, is broken down into several data items. Each item undergoes necessary anonymization processing, removing sensitive fields and retaining only the summary value used for statistics or result display. Specifically, a cryptographic hash function is applied to each anonymized data item to generate underlying hash nodes. All underlying hash nodes are paired and hashed again to generate parent nodes, and this process continues until a unique root hash is constructed. This Merkle root hash serves as the identifier for the Channel C summary block and is written into the consortium blockchain, becoming a verifiable public summary released by the regulatory portal. The public or third-party institutions can apply for an audit path for a specific item. The system verifies that the item is indeed included in the root hash and that the data has not been tampered with by returning the relevant hash path, thus enhancing system transparency and public trust.

[0107] S2 collects raw building energy consumption data from energy supply companies and basic building information of the buildings being supplied with energy, forming standardized on-chain data and performing signature authentication.

[0108] Data collection and authentication process as follows Figure 4 As shown, building carbon emission data is mainly divided into two categories: real-time collection of dynamic energy consumption data through IoT devices such as smart meters, water meters, and gas meters installed within the building, or periodic provision of actual water, electricity, and gas consumption data from energy supply companies, along with the collection of static attribute data. All raw data and their sources are collected and signed by the corresponding verification agency nodes during the project documentation phase, forming a data authentication record.

[0109] Dynamic energy consumption data includes monthly or daily electricity consumption (E), water consumption (W), and gas consumption (G), uploaded by IoT devices or energy suppliers. It is categorized according to a "four-dimensional structure" to achieve precise binding and full traceability of each energy consumption data point. Static attribute data constitutes the basic descriptive information of the building itself. Essentially, it is metadata bound to the building's unique ID, independently uploaded to the blockchain as one-dimensional metadata directly associated with the building ID, and its authenticity is confirmed by a verification agency. This includes building ID, latitude and longitude coordinates, total building area (S), number of floors (including above-ground and underground floors), parking area, operating hours (H), and number of office workers (N), etc.

[0110] IoT devices deployed inside buildings collect raw building energy consumption data from energy suppliers, transmit the data back via LoRa, NB-IoT, or 4G networks, and generate the following structure:

[0111]

[0112] In the formula, This is the raw energy consumption data packet for energy type x at time point t, such as electricity, water, gas, etc.; MeterID is the unique identifier of the metering device, used to identify the data source device, such as the third electricity meter in a building; Reading t The energy consumption reading is at time point t; Δt is the reading period, such as 30 days; Sign device Sign up smart devices.

[0113] The system supports differentiated reading period settings, such as setting daily data readings for key energy-consuming buildings and monthly data collection for ordinary buildings, to achieve a balance between data accuracy and system load. Device signatures can be protected by hardware-level keys through the built-in TPM (Trusted Platform Module), ensuring the security and reliability of data sources. If IoT devices cannot cover the area, energy supply companies can also directly upload billing data.

[0114] All data undergoes hash encryption and digital signature processing before being uploaded to the blockchain to ensure the integrity of the data content, the verifiability of its source, and its non-repudiation. This provides a fundamental architectural guarantee for the authenticity, compliance, and regulatory support of building carbon emission data. All collected data undergoes source node identity signature and hash encryption processing.

[0115] H data =Hash(B i ‖M j ||V i,j ||T l ||Sign node );

[0116] In the formula, H dataThe final generated data hash digest is used for on-chain identification, authentication, and traceability; Hash is a hash function used to compress input data of arbitrary length into a fixed-length output; B i M is the unique identifier for the i-th building; j Number the j-th meter; V i,j The periodic usage data corresponding to instrument number j for building i, including raw energy consumption data packages for various energy sources at each point in time. Such as electricity consumption (kWh), water consumption (tons), gas consumption (m³) 3 In actual operation, the system will process V. i,j The data packets undergo format standardization and are bound to table numbers and building codes to form anti-collision data pairs; T l The l-th time series identifier; Sign node The upload node generates a digital signature using its private key. The signature employs an asymmetric encryption algorithm to ensure that the data cannot be tampered with even if it is subjected to a man-in-the-middle attack.

[0117] To ensure a unified format and rigorous binding logic for the on-chain data, building carbon emission information collection and authentication employs a four-dimensional data structure for organization and indexing. A "four-dimensional structure" data index model is established, combining data after source node identity signatures and hash encryption according to four dimensions: building identity, metering equipment, energy supplier, and time. This forms a highly unique and scalable index relationship, achieving unified data binding and traceable recording. i,j,k,l ={B i M j C k ,T l}

[0118] The four-dimensional data index structure achieves consistency in data organization, parsing, and traceability at the logical level, providing a foundational interface for functions such as data visualization, compliance tracking, and AI modeling. The system supports building dynamic data cubes based on this structure, representing "building-energy-source-time," to meet higher-level data analysis tasks such as regional analysis, energy efficiency ranking, and carbon performance attribution. The on-chain data of the "four-dimensional structure" can be used to index and track carbon emission-related data for any time period, any building, and any energy source, achieving dimensional uniformity and data traceability. The system also supports compressed encoding of the index data structure, utilizing algorithms such as time series merging and primary key redundancy removal to improve on-chain storage efficiency. As the scale of incoming data grows, horizontal query optimization can be performed using the Fabric off-chain state database to improve cross-time period tracking performance. Based on this structure, the system can flexibly locate the carbon emission data of electricity, water, and gas within a building for a specific time period according to conditional combinations, thereby constructing a dynamic view of the building's carbon footprint and providing consistent data support for compliance evaluation, baseline calculation, and carbon asset verification.

[0119] Initial reading verification and table number binding authentication are performed on the standardized on-chain data to confirm the following logic:

[0120]

[0121] If Verify(M) j B i If Verify(M) = 0, authentication fails. The system records this data in the off-chain abnormal data buffer with an abnormal identifier. This type of data must not be directly entered into the main chain ledger. An audit record is generated simultaneously, automatically notifying the energy supplier that uploaded the data for binding review or data correction. If Verify(M) = 0, authentication fails. j B i If ) = 1, then authentication is successful, a digital signature is generated, and the data is marked as "authenticated".

[0122] For example, after the electricity consumption data uploaded by an office building passes device binding verification, reading range verification, and meter number matching, the system records its status as "authentication successful" and marks the authentication time, authentication smart contract version number, and signature public key number in the on-chain ledger for subsequent comparison and auditing. To prevent meter number forgery or mismatch, the system introduces a triple binding mechanism of "device authentication code + location GPS coordinates + building ID," using a hash method to solidify the binding relationship. Each time the system collects data, it will perform integrity verification of the binding status. Data packets that fail verification will be rejected by the smart contract, and the error reason will be returned to the node.

[0123] S3: Each energy supplier submits the signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency then performs integrity verification on all the building data that has been uploaded to the blockchain. After the verification is passed, the signed and authenticated data is solidified and stored in an immutable manner through a multi-node consensus mechanism.

[0124] Signed data is packaged and uploaded to the consortium blockchain, with all data accompanied by timestamps and source identification. The consortium blockchain completes data uploading through a multi-node consensus mechanism and stores the data in an immutable manner for the long term, ensuring data authenticity and traceability. Before uploading, the data format must meet the structured requirements defined in the chaincode. The system can embed an automatic conversion module to convert common structures such as XML / JSON into on-chain contract field formats, improving the ability to integrate with heterogeneous systems. The API interface supports call frequency limits, node whitelists, and retry mechanisms to prevent system congestion caused by short-term high-frequency calls.

[0125] The verification agency adds a timestamp to all signed and authenticated building data on the blockchain, forming a complete on-chain record of building carbon emission data:

[0126] TX n ={IDbuilding ID meter ,T,V,EF,H data Sign node};

[0127] In the formula, YX n Record a complete building carbon emission data on the blockchain; ID building The basic unit identifier for carbon emission attribution, identifying the building object to which this data belongs; ID meter The energy type identifier distinguishes which specific device the uploaded data came from, such as an electricity meter, water meter, or gas meter; T is the timestamp; V is the energy consumption reading, such as electricity consumption (kWh), water consumption (tons), or gas consumption (m³). 3 (e.g., EF represents the raw energy consumption data for that cycle; H represents the carbon emission factor; EF represents the carbon emission factor.) data For the final generated data hash digest; Sign node Sign the uploader's identity.

[0128] Based on the complete on-chain record of building carbon emission data, the regulatory node initiates an automatic call at the end of each month to summarize all building data that has been uploaded to the chain within that month, and performs integrity verification on the final generated data hash digest and uploader identity signature to ensure that there is no on-chain contamination or forged data.

[0129] After the data integrity verification is completed, the consortium blockchain system automatically triggers the multi-node consensus mechanism process. It prioritizes the use of the RAFT mechanism in the distributed ledger platform of the Hyperledger Fabric modular architecture to realize the consensus confirmation and sorting of data blocks among consortium nodes. Data that successfully passes the consensus will be written into the consortium blockchain ledger and synchronized to the Hyperledger Fabric state database to form an immutable solidified evidence.

[0130] While writing blocks, the consortium blockchain system dynamically generates multi-field composite indexes based on fields such as building number, timestamp, and device number in the transaction, enabling fast retrieval, aggregation, and verification of on-chain data across time periods, device numbers, and table structures.

[0131] Based on the periodic data uploading and state management functions of consortium blockchain networks, a "carbon emission on-chain snapshot" mechanism is proposed. This mechanism can be used to compare changes in carbon emissions between any two points in time and can be submitted as traceability evidence to verification agencies after significant events such as changes in building use or energy-saving renovations. This provides verification agencies with verifiable blockchain evidence, balancing regulatory needs with compliant data sharing. The mechanism generates an on-chain snapshot through the following steps:

[0132] The consortium blockchain network system uses the carbon emission data of all buildings at that point in time, including carbon intensity per unit area, energy composition ratio, and total energy consumption, as the state vector S. t Store, and attach a timestamp T t With Merkle root hash To create a complete snapshot, that is:

[0133]

[0134] In the above formula, Sanpshot t This is a snapshot data structure for the carbon emission chain generated by the system at time point t; S t This is a set of carbon emission status indicators for a building complex at time point t, encompassing multi-dimensional indicators such as carbon intensity per unit area, energy consumption composition, and operational characteristics; T t The timestamp generated for the snapshot is used to mark the data version and change node; The Merkle tree root hash value corresponding to the snapshot data is multiple H data The aggregate hash is used to ensure that the snapshot data source is authentic, the process is verifiable, and the content is tamper-proof.

[0135] S4, based on the smart contract authentication rules pre-deployed by the government management department in the consortium blockchain network, authenticates the solidified and stored on-chain building data. If the authentication is successful, the contract will write the "authenticated" mark and trigger the carbon emission intensity calculation in step 5; otherwise, the reason for the authentication failure will be recorded and fed back to the corresponding energy supply company for correction through the on-chain notification mechanism.

[0136] Smart contract authentication logic as follows Figure 5 As shown, smart contracts are deployed in a consortium blockchain network to automate authentication. These smart contracts set authentication rules such as table number verification, data range verification, and data logic consistency checks. Uploading data triggers the execution of the smart contract, automatically completing the authentication process and generating authentication results recorded on the blockchain, thus improving verification efficiency and fairness.

[0137] The smart contract authentication rules pre-deployed by government regulatory departments in the consortium blockchain network include:

[0138] Meter number matching: Verify meter number M j Whether it is bound to the building ID.

[0139] Numerical reasonableness judgment: Whether the monthly emission intensity of building data is too high or too low. For example, if the monthly carbon emission intensity is less than 0.1 times the historical average for the same month, it is considered too low. The numerical reasonableness judgment rules support setting differentiated upper and lower limits based on building type and usage function. For example, the upper limit of monthly gas consumption for medical buildings is significantly higher than that for office buildings. The system can set classification threshold logic to avoid misjudgment.

[0140] Time continuity assessment: Whether the data upload cycle is a continuous time period, such as once every 30 days.

[0141] Signature validity verification: Verify the digital signature using the node's public key.

[0142] In the consortium blockchain, pre-deployed smart contracts automatically complete the judgment and generation according to the rules. If the table number matches: Metering Table Number M j The data is bound to the building ID, and the values ​​are reasonable: the monthly emission intensity of the building data is neither too high nor too low; the time period is continuous: the data upload cycle is a continuous time period; and the signature is valid: if the node's public key verifies the digital signature, the contract authentication is deemed successful, an "authenticated" flag will be written, and the downstream carbon emission calculation logic will be triggered. After the data is uploaded, it is locked through a smart contract, allowing only the competent authority to update it; otherwise, the reason for authentication failure is recorded and the node is notified to correct it. The authentication failure record includes five pieces of information: the failing node number, failure type, failure time, input data summary, and contract version. The on-chain trace can be used for subsequent review, regulatory tracing, and behavior statistics.

[0143] The smart contract module can be deployed to participating nodes as needed, or it can be hosted and run by a super node, supporting hot rule updates and version compatibility control. When a large-scale building cluster is simultaneously uploaded to the blockchain, the contract will execute multi-task authentication logic in parallel and output batch status results, significantly improving system throughput.

[0144] S5, based on the IPCC recommended formula and the latest carbon emission factor, calculates the building carbon emission intensity of energy supply companies and binds the calculation results with the corresponding original data to the consortium blockchain for real-time verification by verification agencies or government regulatory platforms.

[0145] The carbon emission calculation and verification process is as follows: Figure 6 As shown, government management departments or their authorized third-party institutions regularly release standard carbon emission factors to the consortium blockchain and record versions and update history to ensure the accuracy, consistency, and timeliness of carbon emission accounting. Based on certified energy consumption data and corresponding carbon emission factors, the consortium blockchain network system automatically calculates the total carbon emissions of each building according to standard carbon emission accounting. The calculation results are recorded in the consortium blockchain ledger and can be accessed, reviewed, and compared by the government and verification agencies.

[0146] To ensure data real-time performance, the consortium blockchain system supports setting a "transition period" before carbon emission factors take effect, avoiding calculation errors caused by sudden changes in factors. Furthermore, to prevent human error in updating, the system can be set up with an automatic reminder mechanism to periodically notify authoritative institutions to complete the review of carbon emission factors.

[0147] Carbon emission factor management adopts an on-chain registration mechanism, with an authoritative agency designated by the government department releasing emission factors at the following timeframe. Once released, the data is locked via a smart contract, allowing only the competent authority to update it:

[0148] EF x ={EnergyType x Value x ,Unit,Version,T};

[0149] In the above formula, EF x Carbon emission factor for energy type x; EnergyType x Energy type for energy category x, such as electricity, natural gas, etc.; Value x The value of the carbon emission factor is assigned to energy type x; Unit is the unit of the carbon emission factor; Version is the release status of the carbon emission factor; T is the effective time of the version; each carbon emission factor record is attached to the publisher node number and hash verification value on the chain, which can realize the function of factor version comparison and invalidation query.

[0150] Design a carbon emission factor registration structure, where each carbon emission factor includes the following fields:

[0151] EF x,n ={ID x Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer}

[0152] In carbon emission factor EF x,n After being published, the system automatically calculates its effective date as follows:

[0153] T effective =T publish +ΔT.

[0154] The transition period ΔT data is processed according to the following rules:

[0155] In T publish ≤t≤T effective During the time period, the old factor EF will still be used. x,n-1 Calculate carbon emission intensity when t>T effective When the time comes, it will automatically switch to the new carbon emission factor EF. x,n Calculate carbon emission intensity, i.e.:

[0156]

[0157] All historical records retain factor version numbers to support backtracking and comparison, and all carbon emission calculations automatically reference the current valid version, Value. layestTo prevent the use of expired factors, during large-scale concurrent building calculations, the system caches the latest version of emission factors in the node's memory area and references them directly before contract execution, significantly reducing the number of on-chain calls and improving computational efficiency and consistency. Simultaneously, the system retains a historical factor comparison function, facilitating source analysis and sensitivity assessment of the impact of version changes on total carbon emissions.

[0158] In summary, based on the certified energy consumption data and corresponding carbon emission factors, the system automatically calculates the total carbon emissions of each building according to the standard carbon emission accounting formula. The carbon emission intensity of the consortium blockchain network is calculated using the following formula:

[0159]

[0160] In the formula, EI i This represents the carbon emission intensity per unit area of ​​the i-th building, commonly expressed in kgCO2 / m². 2 ; Let A be the total carbon emissions of the i-th building; i Q represents the building area of ​​the i-th building; i,x Let x be the amount of energy used in the i-th building, such as kWh, m 3 , tons; Value layest This is the current effective version of carbon emission accounting; EF x,n-1 For energy category x, record the (n-1)th carbon emission factor; EF x,n This is the record for the nth carbon emission factor of energy type x; t is the current time; T publish For the release time of carbon emission factors; T effective For the actual effective time of carbon emission factors; ID x For identifying energy type x; Value x Let T be the carbon emission factor value for energy type x; expire For carbon emission factor failure time; H(F) x ) is the hash check value of the carbon emission factor content for energy type x; N issuer The authoritative node number for publishing carbon emission factors; ΔT is the transition period set by the system.

[0161] The authority to adjust transition parameters is controlled by the government management department or its authorized third-party institution. When the government management department or its authorized third-party institution initiates an RT adjustment request, it must attach a digital signature and verify whether the initiator has the authority to adjust the parameters through the identity authentication module of the consortium blockchain, such as Hyperledger Fabric's MSP.

[0162] S6 employs a role-based access control mechanism to set access ranges for different nodes.

[0163] Sensitive information such as building occupants and specific energy-consuming structures is protected using encryption or zero-knowledge proof technology to ensure both compliant data sharing and privacy security, i.e., without exposing El... i Given the true value, it is proven that its strength is less than a certain benchmark, which is then submitted for third-party verification. All sensitive data is encrypted off-chain, with only the hash digest and verification logic stored on-chain, ensuring both user privacy and government oversight.

[0164] Access control and privacy protection are implemented based on Hyperledger Fabric's chaincode access control model and zero-knowledge proof mechanism, specifically including:

[0165] The consortium blockchain system supports a flexible access control list (ACL) configuration model, allowing for the setting of query scopes and field masks for different node types, such as regulators, verification agencies, research institutions, and public users. Through a dual strategy of "on-chain structured access policy + off-chain encrypted data distribution," the system ensures that it meets or exceeds the Level 3 or higher data security protection standard.

[0166] Each participant is assigned an independent MSP identity and has access policies set; different channel access permissions are set through ACLs.

[0167] The sensitive field is constructed using the ZKP mechanism as follows:

[0168] Prove(El i <El baseline → True;

[0169] In the above formula, Prove(El i <El baseline ) used to determine El i Check if it is below the baseline and derive the logical result. baseline The carbon emission intensity benchmark value set for the corresponding building category or region. →True indicates that the building's carbon emission intensity meets the benchmark requirements.

[0170] Role-based access control mechanisms can be widely applied in scenarios such as "green building certification," "energy efficiency performance assessment," and "carbon reduction project evaluation," enabling third-party verification while protecting privacy. Off-chain data storage can be distributed and hosted using IPFS (InterPlanetary File System), and combined with symmetric encryption and access control key distribution strategies to ensure controllable, secure, and manageable privacy data sharing. Regulatory agencies, with user authorization or policy authorization, can temporarily access decrypted data for judicial investigations or risk warnings.

[0171] Example 2

[0172] like Figure 7As shown, a trusted authentication system for building carbon emissions that integrates the Internet of Things and consortium blockchain includes a consortium blockchain network construction module, a signature authentication module, an inspection and evidence storage module, a smart contract authentication module, and a carbon emission intensity calculation module.

[0173] The consortium blockchain network building module is used to introduce a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes.

[0174] The signature authentication module is used to collect the original building energy consumption data of energy supply companies and the basic building information of the buildings being supplied with energy, form unified standard on-chain data, and perform signature authentication.

[0175] The verification and evidence storage module is used by each energy supply company to submit signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency then performs integrity verification on all on-chain building data. After the verification is passed, the signed and authenticated data is solidified into an immutable evidence through a multi-node consensus mechanism.

[0176] The smart contract authentication module is used to authenticate the on-chain building data that has been solidified and stored based on the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network. If the authentication is successful, the contract will write the "authenticated" mark and trigger the carbon emission intensity calculation module to calculate the carbon emission intensity; otherwise, the reason for the authentication failure will be recorded and fed back to the corresponding energy supply company for correction through the on-chain notification mechanism.

[0177] The carbon emission intensity calculation module is used to calculate the building carbon emission intensity of energy supply companies and bind the calculation results with the corresponding original data to the consortium blockchain for real-time authentication by verification agencies or government regulatory platforms.

[0178] The signature authentication module includes a data structure generation unit, a data processing unit, an on-chain data formation unit, an authentication logic confirmation unit, and an authentication result judgment unit.

[0179] The data structure generation unit is used by IoT devices deployed inside buildings to collect raw building energy consumption data from energy supply companies and generate the following structure:

[0180]

[0181] The data processing unit is used to perform source node identity signing and hash encryption on all collected data.

[0182] H data =Hash(B i ‖M j ||V i,j ||T l ||Sign node ).

[0183] The on-chain data forming unit is used to combine the source node's identity signature and hash-encrypted data according to four dimensions: building identity, metering equipment, energy supply unit, and time, to form standardized on-chain data.

[0184] D i,j,k,l ={B i M j C k ,T l}

[0185] The authentication logic verification unit is used to perform initial reading verification and table number binding authentication on the unified standard on-chain data, verifying the following logic:

[0186]

[0187] If Verify(M) j B i If Verify(M) = 0, authentication fails. The system records this data in the off-chain abnormal data buffer with an abnormal identifier. This type of data must not be directly entered into the main chain ledger. An audit record is generated simultaneously, automatically notifying the energy supplier that uploaded the data for binding review or data correction. If Verify(M) = 0, authentication fails. j B i If ) = 1, then authentication is successful, a digital signature is generated, and the data is marked as "authenticated".

[0188] The verification and evidence storage module includes an on-chain record formation unit, an integrity verification unit, and a multi-node consensus unit.

[0189] The on-chain record forming unit is used by verification agencies to add timestamps to all signed and authenticated on-chain building data, forming a complete on-chain record of building carbon emission data:

[0190] TX n ={ID building ID meter ,T,V,EF,H data Sign node}

[0191] The integrity verification unit is used to perform integrity verification on the final generated data hash digest and uploader identity signature based on the complete on-chain record of building carbon emission data, ensuring that there is no on-chain contamination or forged data.

[0192] After the data integrity verification is completed, the multi-node consensus unit is used to automatically trigger the multi-node consensus mechanism process. Data that successfully passes the consensus will be written into the consortium blockchain ledger to form an immutable solidified evidence.

[0193] In the smart contract authentication module, the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network include:

[0194] Meter number matching: Verify meter number M j Whether it is bound to the building ID.

[0195] Numerical rationality assessment: Whether the monthly emission intensity of building data is too high or too low.

[0196] Time continuity assessment: Whether the data upload period is a continuous time period.

[0197] Signature validity verification: Verify the digital signature using the node's public key.

[0198] In the carbon emission intensity calculation module, the building carbon emission intensity of energy supply companies is calculated using the following formula:

[0199]

[0200] EF x,n ={ID x Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer};

[0201] T effective =T publish +ΔT.

[0202] Therefore, the present invention employs the above-mentioned trusted authentication method and system for building carbon emissions that integrates the Internet of Things and consortium blockchain, which can realize the trusted collection, authentication and supervision of building carbon emission data throughout the entire process, thereby improving carbon management efficiency and data transparency.

[0203] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A trusted authentication method for building carbon emissions that integrates the Internet of Things and consortium blockchain, characterized in that: Includes the following steps: S1 introduces a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes. S2 collects raw building energy consumption data from energy supply companies and basic building information of the buildings being supplied with energy, forms on-chain data, and performs signature authentication. S3, each energy supply company submits the signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency performs integrity verification on all the building data that has been uploaded to the blockchain. After the verification is passed, the signed and authenticated data is used to form an immutable solidified evidence through a multi-node consensus mechanism. S4, based on the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network, authenticates the solidified and stored on-chain building data; Once certified, the contract writes a certified identifier, triggering the S5 carbon intensity calculation; If authentication fails, the reason for the failure will be recorded and fed back to the corresponding energy supplier through the on-chain notification mechanism for correction. S5 calculates the building carbon emission intensity of energy supply companies, binds the calculation results with the corresponding original data and writes them onto the consortium blockchain for real-time verification by verification agencies or government regulatory platforms.

2. The building carbon emission trusted authentication method integrating IoT and consortium blockchain as described in claim 1, characterized in that: S2 specifically includes: S21, IoT devices deployed inside the building collect raw building energy consumption data from energy supply companies and generate the following structure: In the formula, This is the raw energy consumption data packet for energy type x at time point t; MeterID is the unique identifier of the metering device; Reading t The energy consumption reading is at time point t; Δt is the reading period; Sign device Signing for smart devices; S22, Perform source node identity signature and hash encryption processing on the collected data: H data =Hash(B i ‖M j ‖V i,j ‖T l ‖Sign node ); In the formula, H data This is the final generated data hash digest; Hash is the hash function; B i M is the unique identifier for the i-th building; j Number the j-th meter; V i,j The periodic usage data corresponding to instrument number j for building i, including raw energy consumption data packages for various energy sources at each point in time. T l The l-th time series identifier; Sign node A digital signature generated by the uploading node using its private key; S23 combines the source node's identity signature with the hash-encrypted data according to four dimensions: building identity, metering equipment, energy supply unit, and time, to form standardized on-chain data. D i,j,k,l ={B i ,M j ,C k ,T l }; In the formula, D i,j,k,l B is the only logical location path for carbon emission data; i M is the unique identifier for the i-th building; j Number the j-th meter; C k Code the kth energy supplier; T l This is the identifier for the l-th time series. S24, perform initial reading verification and table number binding authentication on the standardized on-chain data, confirming the following logic: In the formula, Verify(M j B i ) represents the j-th metering device M j With the i-th building B i Verify the binding relationship between them; M j Number the j-th meter; B i The unique number of the i-th building; S25, Verify (M) j B i If ) = 0, authentication fails. The failed authentication data is recorded in the off-chain abnormal data buffer and an abnormal identifier is attached. Such data must not be directly entered into the main chain ledger. At the same time, an audit record is generated, and the energy supply company that uploaded the data is automatically notified to bind and review or correct the data. Verify(M j B i If ) = 1, authentication is successful, a digital signature is generated, and the data is marked as authenticated.

3. The building carbon emission trusted authentication method integrating the Internet of Things and consortium blockchain as described in claim 2, characterized in that: S3 specifically includes: S31, the verification agency adds a timestamp to all signed and authenticated on-chain building data to form a complete on-chain record of building carbon emission data: TX n ={ID building ,ID meter ,T,V,EF,H data ,Sign node }; In the formula, TX n Record a complete building carbon emission data on the blockchain; ID building ID is the basic unit identifier for carbon emission attribution. meter The energy type is identified by: T for timestamp; V for energy consumption reading; EF for carbon emission factor; H for energy type. data For the final generated data hash digest; Sign node Sign the uploader's identity; S32, based on the complete on-chain record of building carbon emission data, performs integrity verification on the final generated data hash digest and uploader identity signature; S33. After the data integrity verification is completed, the multi-node consensus mechanism process is automatically triggered. Data that successfully passes the consensus will be written into the consortium blockchain ledger to form an immutable solidified evidence.

4. The building carbon emission trusted authentication method integrating the Internet of Things and consortium blockchain as described in claim 3, characterized in that: In S4, the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network include: Meter number matching: Verify meter number M j Is it bound to the building ID? Numerical rationality assessment: Is the monthly emission intensity of building data too high or too low? Time continuity assessment: Whether the data upload period is a continuous time period; Signature validity verification: Verify the digital signature using the node's public key.

5. The building carbon emission trusted authentication method integrating the Internet of Things and consortium blockchain as described in claim 4, characterized in that: In S5, the building carbon emission intensity of energy supply companies is calculated using the following formula: EF x,n ={ID x ,Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer }; T effective =T publish +ΔT; In the formula, EI i Let be the carbon emission intensity per unit area of ​​the i-th building; Let A be the total carbon emissions of the i-th building; i Q represents the building area of ​​the i-th building; i,x Value represents the amount of energy of type x used in the i-th building; layest This is the current effective version of carbon emission accounting; EF x,n-1 For energy category x, record the (n-1)th carbon emission factor; EF x,n This is the record for the nth carbon emission factor of energy type x; t is the current time; T publish The release time of carbon emission factors; T effective This refers to the actual effective time of the carbon emission factor. ID x Identifier for energy type x; Value x Let T be the carbon emission factor value for energy type x; expire For carbon emission factor failure time; H(F) x ) is the hash check value of the carbon emission factor content for energy type x; N issuer The authoritative node number for publishing carbon emission factors; ΔT is the transition period set by the system.

6. A building carbon emission trusted authentication system integrating the Internet of Things and consortium blockchain, applying the building carbon emission trusted authentication method integrating the Internet of Things and consortium blockchain as described in any one of claims 1-5, characterized in that: Includes the following modules: Consortium blockchain network construction module: Introduces a multi-channel mechanism to build a consortium blockchain network in which government management departments act as super nodes, qualified verification agencies and energy supply companies act as ordinary nodes; Signature authentication module: Collects raw building energy consumption data from energy supply companies and basic building information of the buildings being supplied with energy, forms unified standard on-chain data, and performs signature authentication; Verification and Evidence Preservation Module: Each energy supply company submits the signed and authenticated data to the consortium blockchain network through the on-chain API interface. The verification agency performs integrity verification on all the building data that has been uploaded to the blockchain. After the verification is passed, the signed and authenticated data is used to form an immutable solidified evidence through a multi-node consensus mechanism. Smart contract authentication module: Based on the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network, it authenticates the solidified and stored on-chain building data; Once authentication is successful, the contract will write the authentication identifier, triggering the carbon emission intensity calculation module to calculate the carbon emission intensity. If authentication fails, the reason for the failure will be recorded and fed back to the corresponding energy supplier through the on-chain notification mechanism for correction. Carbon emission intensity calculation module: Calculates the building carbon emission intensity of energy supply enterprises, binds the calculation results with the corresponding original data and writes them to the consortium blockchain for real-time verification by verification agencies or government regulatory platforms.

7. The trusted authentication system for building carbon emissions integrating the Internet of Things and consortium blockchain as described in claim 6, characterized in that: The signature authentication module includes a data structure generation unit, a data processing unit, an on-chain data formation unit, an authentication logic confirmation unit, and an authentication result judgment unit. Data Structure Generation Unit: IoT devices deployed inside the building collect raw building energy consumption data from energy supply companies and generate the following structure: Data processing unit: Performs source node identity signature and hash encryption processing on all collected data. H data =Hash(B i ‖M j ‖V i,j ‖T l ‖Sign node ); On-chain data formation unit: The source node identity signature and hash-encrypted data are combined according to four dimensions: building identity, metering equipment, energy supply unit, and time, to form standardized on-chain data. D i,j,k,l ={B i ,M j ,C k ,T l }; Authentication logic confirmation unit: Performs initial reading verification and table number binding authentication on the unified standard on-chain data, confirming the following logic: Authentication result judgment unit: Verify(M) j B i If ) = 0, authentication fails. The system records this data in the off-chain abnormal data buffer and adds an abnormal identifier. This type of data must not be directly entered into the main chain ledger. At the same time, an audit record is generated, and the energy supply company that uploaded this data is automatically notified to bind and review or correct the data. Verify(M j B i If ) = 1, authentication is successful, a digital signature is generated, and the data is marked as authenticated.

8. The building carbon emission trusted authentication system integrating the Internet of Things and consortium blockchain as described in claim 7, characterized in that: The verification and evidence storage module includes an on-chain record formation unit, an integrity verification unit, and a multi-node consensus unit; On-chain record formation unit: The verification agency adds a timestamp to all signed and authenticated on-chain building data to form a complete on-chain record of building carbon emission data. TX n ={Id building ,ID meter ,T,V,EF,H data ,Sign node }; Integrity verification unit: Based on the complete on-chain record of building carbon emission data, it performs integrity verification on the final generated data hash digest and uploader identity signature; Multi-node consensus unit: After the data integrity verification is completed, the system automatically triggers the multi-node consensus mechanism process. Data that successfully passes the consensus will be written into the consortium blockchain ledger to form an immutable solidified evidence.

9. The building carbon emission trusted authentication system integrating the Internet of Things and consortium blockchain as described in claim 8, characterized in that: In the smart contract authentication module, the smart contract authentication rules pre-deployed by government management departments in the consortium blockchain network include: Meter number matching: Verify meter number M j Is it bound to the building ID? Numerical rationality assessment: Is the monthly emission intensity of building data too high or too low? Time continuity assessment: Whether the data upload period is a continuous time period; Signature validity verification: Verify the digital signature using the node's public key.

10. The trusted authentication system for building carbon emissions integrating the Internet of Things and consortium blockchain as described in claim 9, characterized in that: In the carbon emission intensity calculation module, the building carbon emission intensity of energy supply companies is calculated using the following formula: EF x,n ={ID x ,Value x ,T publish ,T effective ,T expire ,H(F x ),N issuer }; T effective =T publish +ΔT。

Images