A cross-agency carbon emission data synchronization method

Abstract

The present application relates to a kind of cross-agency carbon emission data synchronization method, belong to carbon emission data management technical field.The method includes: continuously collecting local carbon emission raw data, in each set period, based on the carbon emission raw data of current period, the corresponding Merkle root of the period is generated;Based on the Merkle root of current period, the corresponding digital signature is obtained, and the zero-knowledge range proof of current period is constructed;Based on the digital signature and zero-knowledge range proof, the compliance ticket corresponding to current period is generated, and the compliance ticket is used to verify emission compliance;The fluctuation between the Merkle root of current period and last period is calculated, and whether the fluctuation exceeds preset threshold is based on the fluctuation Dynamic selection is used single-chain architecture or double-chain architecture to carry out the data synchronization of current period compliance ticket.The present application method solves the technical problems, such as storage expansion caused by high-frequency carbon emission data directly on chain in prior art, privacy disclosure risk is big, single-chain consensus throughput is insufficient and compliance verification is complex.

Description

Technical Field

[0001] This invention relates to the field of carbon emission data management technology, and in particular to a method for synchronizing carbon emission data across organizations. Background Technology

[0002] With the comprehensive advancement of the "dual-carbon" strategy, carbon emission data has shifted from traditional annual accounting to real-time measurement at the "minute-to-second" level, becoming the common foundation for carbon trading settlement, green credit granting, and administrative supervision. However, if high-frequency 1Hz data is directly written to the blockchain, the annual increment at a single point can reach TB levels, causing storage expansion, bandwidth congestion, and node synchronization delays. At the same time, the original emission values ​​contain commercially sensitive information such as production capacity schedules and process parameters. Uploading the entire data to the blockchain is equivalent to disclosing core secrets, leading companies to "dare not and are unwilling to disclose" such information. Under a single-chain architecture, regardless of whether PBFT, Raft, or Fabric sorting services are used, the throughput is fixed in the range of 2000-3000 TPS. When carbon prices fluctuate drastically or production anomalies cause data jumps, the consensus layer cannot scale elastically, easily leading to transaction congestion, confirmation delays, or even forks and rollbacks, making it difficult to meet the timeliness requirements of the carbon market of "second-level rights confirmation and minute-level settlement." In addition, when regulatory authorities conduct random inspections of emissions compliance, they often have to choose between "seeing the data" and "protecting corporate privacy." Existing zero-knowledge solutions are either too large in size or incompatible with national cryptographic algorithms, making it difficult to generate them in real time in low-computing-power gateways in industrial sites, resulting in long compliance verification processes, high costs, and many disputes. Summary of the Invention

[0003] Based on the above analysis, this invention aims to disclose a cross-organizational carbon emission data synchronization method to solve the technical problems caused by directly uploading high-frequency carbon emission data to the blockchain in the prior art, such as storage expansion, high risk of privacy leakage, insufficient single-chain consensus throughput, and complex compliance verification.

[0004] This invention provides a method for synchronizing carbon emission data across institutions, specifically including the following steps:

[0005] Continuously acquire raw carbon emission data, and generate the corresponding Merkle root for each set period based on the raw carbon emission data of the current period;

[0006] Based on the Merkle root of the current period, obtain the corresponding digital signature and construct the zero-knowledge range proof of the current period.

[0007] Based on the digital signature and zero-knowledge scope proof, a compliance ticket corresponding to the current cycle is generated, and the compliance ticket is used to verify emission compliance;

[0008] Calculate the fluctuation between the current period and the Merkle root of the previous period, and dynamically select either a single-chain architecture or a dual-chain architecture to synchronize the data of compliant tickets in the current period based on whether the fluctuation exceeds a set threshold.

[0009] Furthermore, the continuous acquisition of raw carbon emission data, and the generation of the corresponding Merkle root based on the raw carbon emission data of the current period within each set period, includes:

[0010] The raw carbon emission data were divided into time granularities, and a corresponding timestamp was added after the data of each time granularity to obtain the data records corresponding to each time granularity.

[0011] Calculate the corresponding hash value for each of the multiple data records in the current period;

[0012] Construct a full binary Merkle tree based on all hash values ​​of the current period and generate the corresponding Merkle root.

[0013] Furthermore, the proof of the zero-knowledge range for constructing the current period includes:

[0014] Constructing a zero-knowledge scope proof for the current period based on the Bulletproofs protocol ;

[0015] During construction, the objective is to prove that , This represents the total carbon emissions for the current cycle. Indicates the current period number Carbon emissions at a time granularity; publicly available parameters are... , The number of data records in the current period. This is the upper limit for emissions per second.

[0016] Furthermore, the step of generating the compliant receipt corresponding to the current period based on the digital signature and zero-knowledge range proof includes:

[0017] ;

[0018] in, This indicates a compliant receipt. This is the Merkle root corresponding to the current period. For the digital signature corresponding to the Merkle root of the current period, Proof of the zero-knowledge scope for the current period.

[0019] Furthermore, the step of dynamically selecting between a single-chain architecture and a dual-chain architecture for compliant ticket data synchronization in the current period based on whether the volatility exceeds a set threshold includes:

[0020] When the volatility exceeds a set threshold, the data synchronization task dynamically switches to a dual-chain architecture, initiates a sharding mechanism, and distributes the data synchronization task to N parallel consensus shards for processing. The number of shards N is dynamically determined based on the volatility, and each shard runs HotStuff consensus independently.

[0021] Furthermore, based on the compliant receipts of the current period, the parameters of each segment are determined, including:

[0022] View number: ;

[0023] Proposal block: ;

[0024] Consensus threshold: ;

[0025] in, This is the fragment number. Indicates time, The maximum waiting time is set. The proposal block number. This is the Merkle root corresponding to the current period. For fragmentation The number of potentially malicious nodes in the network. For safety parameters, For view The corresponding number of validators.

[0026] Furthermore, the dual chains include a business chain and a traceability chain, and the carbon emission data synchronization method further includes: performing periodic consistency checks on the Merkle roots stored in the business chain and the traceability chain based on a set second period.

[0027] Furthermore, based on the established second cycle, the Merkle root stored in the business chain and traceability chain undergoes consistency verification, including:

[0028] Based on consistency check formula Perform a consistency check. If the formula is true, the business chain and the traceability chain are consistent; otherwise, they are inconsistent.

[0029] in, This represents the Merkle root of the business chain. This represents the Merkle root of the traceability chain.

[0030] Furthermore, the SM2 algorithm is used to obtain the corresponding digital signature based on the Merkle root of the current period.

[0031] Furthermore, the step of constructing a full binary Merkle tree based on all hash values ​​of the current period and generating the corresponding Merkle root includes:

[0032] Place all hash values ​​of the current period as leaf nodes at the bottom level of the Merkle tree;

[0033] The Merkle tree is constructed layer by layer from bottom to top: each node in each layer is a combination of the hash values ​​of its two child nodes; if the number of leaf nodes is odd, the last node is copied to ensure that the tree is a full binary tree; a hash operation is performed on each pair of leaf nodes to generate the hash value of the parent node;

[0034] Continue until you reach the top of the tree and obtain the Merkle root.

[0035] The present invention can achieve at least one of the following beneficial effects:

[0036] By integrating a dual-chain architecture, edge gateway compression, and national cryptographic zero-knowledge proof, the problems of storage expansion, privacy leakage, and performance bottleneck caused by high-frequency data uploading to the chain are solved. It is suitable for carbon emission data synchronization scenarios between multiple institutions, and significantly improves the lightweight, privacy, and credibility of cross-institution carbon emission synchronization.

[0037] By constructing a Merkle tree to obtain the corresponding Merkle root, data tampering can be effectively prevented; by compressing the original data, problems such as storage expansion and bandwidth congestion caused by large data volumes can be avoided during data synchronization.

[0038] By generating compact compliance receipts (≤1KB in length) based on digital signatures and zero-knowledge scope proofs, regulatory agencies can quickly verify emissions compliance, balancing efficiency and safety. Using TLV encoding and a fixed-length data format ensures data integrity, facilitates embedded C language processing, and streamlines subsequent verification and parsing, improving system efficiency and reliability.

[0039] By dynamically selecting between a single-chain architecture and a dual-chain architecture for compliant tickets in the current period based on whether the fluctuations in the current and previous periods exceed a set threshold, and dynamically determining the number of shards in the dual-chain architecture when the threshold is exceeded, the system achieves dynamic scaling of the number of channels based on the intensity of data fluctuations. This allows for rapid expansion of reasonable parallel throughput when data surges, significantly reducing network bandwidth usage and node synchronization time.

[0040] By providing reliable dual-chain consistency assurance, a dual-chain reconciliation mechanism of business chain and traceability chain was designed. Combined with the automatic rollback function, it can quickly complete the rollback and replay when data inconsistency is found, and restore consistency in a short time. This ensures the high consistency and reliability of cross-organizational data and avoids the inefficiency and lag of traditional manual reconciliation.

[0041] By providing efficient compliance verification functions, it enables regulatory authorities to quickly obtain compliance receipts and automatically generate electronic compliance certificates with national cryptographic signatures, which greatly shortens the compliance verification cycle for enterprises, significantly improves regulatory efficiency and user experience, and provides solid technical support for application scenarios such as green finance and carbon trading.

[0042] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0043] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0044] Figure 1 This is a flowchart of the method of the present invention;

[0045] Figure 2 This is a table illustrating the meaning and value range of each parameter in step a of Embodiment 2 of the present invention. Detailed Implementation

[0046] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0047] Example 1

[0048] One embodiment of the present invention discloses a method for synchronizing carbon emission data across institutions, specifically including steps S1-S4.

[0049] Step S1: Continuously acquire raw carbon emission data, and generate the corresponding Merkle root for each set period based on the raw carbon emission data of the current period.

[0050] In one specific embodiment, step S1 includes steps S11-S13.

[0051] S11. Divide the acquired raw carbon emission data into time granularities and add a corresponding timestamp to the data of each time granularity to obtain the data record corresponding to each time granularity. Combine all data records within the set period to obtain multiple data records for the current period.

[0052] Specifically, raw carbon emission data refers to unprocessed data on greenhouse gas emissions collected directly from emission sources or through monitoring equipment, typically representing the carbon emission value per unit time; edge gateways continuously acquire locally collected raw carbon emission data through sensors or detection equipment.

[0053] For example, raw carbon emission data can be collected at a frequency of 1 Hz, with "seconds" as the time granularity and 30 seconds as a cycle. Each cycle would contain 30 raw carbon emission data points. In practice, time calibration needs to be accurate to the millisecond level.

[0054] Add a corresponding timestamp after each second of data to obtain 30 data records within that period.

[0055] The following are examples of specific carbon emission values ​​for each second within a 30-second cycle, in kg:

[0056] d=[8.1,7.9,8.3,8.0,8.2,8.1,8.4,8.0,7.8,8.2,8.3,8.1,8.0,8.2,8. 1,8.3,8.0,7.9,8.1,8.2,8.0,8.1,8.3,8.2,8.1,8.0,8.2,8.1,8.0,8.1]

[0057] 243.3kg≤300kg (legal upper limit).

[0058] Based on the start time t0 = 1693555200000ms (Unix ms), the timestamps of each data are obtained as t = [1693555200000, 1693555201000, ..., 1693555229000].

[0059] S12. Calculate the corresponding hash value for each of the multiple data records in the current period.

[0060] Specifically, this embodiment uses the SHA-256 algorithm to calculate the hash value of each data record.

[0061] Taking i=0 as an example: Input byte stream = 0x0000017E69D76C004044000000000000 (8B timestamp + 8B IEEE-754 double precision), where i represents the sequence number of the data in the current period.

[0062] h0 = SHA - 256(0x0000017E69D76C004044000000000000) = 0x3a6f…b821 (256-bit hexadecimal), and h1…h can be calculated similarly. 29 Where h0 represents the hash value corresponding to the 0th data item in the current period;

[0063] S13. Construct a full binary Merkle tree based on all hash values ​​in the current period, and generate the corresponding Merkle root. Specifically:

[0064] Place all hash values ​​of the current period as leaf nodes at the bottom level of the Merkle tree;

[0065] The Merkle tree is constructed layer by layer from bottom to top: each node in each layer is a combination of the hash values ​​of its two child nodes; if the number of leaf nodes is odd, the last node is copied to ensure that the tree is a full binary tree; a hash operation is performed on each pair of leaf nodes to generate the hash value of the parent node;

[0066] Continue until you reach the top of the tree and obtain the Merkle root.

[0067] For example, when a period includes 30 data points, the Merkle root is represented as The following is the specific process of constructing a binary tree:

[0068] level0 (leaf node): node[0]=h0,…,node

[29] =h 29 ;

[0069] level1: node

[30] =SHA-256(node[0]∥node[1])…node

[44] =SHA-256(node

[28] ∥node

[29] );

[0070] level2: node

[45] =SHA-256(node

[30] ∥node

[31] )…node

[52] =SHA-256(node

[42] ∥node

[43] );

[0071] level3: node

[53] =SHA-256(node

[45] ∥node

[46] )…node

[56] =SHA-256(node

[51] ∥node

[52] );

[0072] level4: node

[57] =SHA-256(node

[53] ∥node

[54] ), node

[58] =SHA-256(node

[55] ∥node

[56] );

[0073] level5 (root): R 30 =SHA-256(node

[57] ∥node

[58] )=0x4b3c27a1f2e8…(32Byte length).

[0074] This embodiment obtains the corresponding Merkle root by constructing a Merkle tree. Since the Merkle root will change if any bit of data is tampered with, it can effectively prevent data from being tampered with. This embodiment compresses the original 480 bytes of data into 256 bits, or 32 bytes, which can avoid problems such as storage expansion and bandwidth congestion caused by large data volumes during data synchronization.

[0075] Step S2: Obtain the corresponding digital signature based on the Merkle root of the current period, and construct the zero-knowledge range proof for the current period.

[0076] Specifically, the SM2 algorithm is used to obtain the corresponding digital signature based on the Merkle root of the current period. The signature process includes:

[0077] Based on true random numbers Generate a public key. ;

[0078] Based on pre-set curve parameters, enterprise identity ID, and the public key, it is preprocessed into a 32-byte Z value. ,in Encode the length of the identifier. For enterprise identity ID, For elliptic curve parameters, , It is the base point of the elliptic curve;

[0079] The preprocessed 32-byte Z value is concatenated with the Merkle root to form a new data block. The SM3 hash algorithm is then used to perform a hash calculation on the concatenated data block to obtain a 256-bit hash value. e， ;

[0080] 256 bits k are drawn from a truly random source, and a dot product operation k·G is performed on an elliptic curve, where G is a base point of the elliptic curve, to obtain ( , ),based on and hash value e Calculated , n Further calculations ,in n The order of the elliptic curve is given by σ; the signature σ consists of r and s, and is 64 bytes in length.

[0081] Specifically, a zero-knowledge scope proof for the current cycle is constructed based on the Bulletproofs protocol. During construction, the objective is to prove that... , This represents the total carbon emissions for the current cycle. Indicates the current period number Carbon emissions at a time granularity; publicly available parameters are... , The number of data records in the current period. This is the upper limit for emissions per second.

[0082] In one specific embodiment, the proof process includes steps 1-5:

[0083] 1. The commitment parameters include: an elliptic curve Curve25519, where generators g and h are public and used to generate the public key. Unknown; large prime number; blinding factor r (randomly generated); where g and h are generated by a trusted ritual, and each parameter is hashed and written into the chip OTP (one-time programmable memory), which cannot be changed.

[0084] 2. Commitment to total computation based on generators .

[0085] 3. Regarding Perform interval splitting, that is This large number can be broken down into multiple parts, each of which falls within a specific range, thus proving that the entire large number (i.e., the total carbon emissions in the current cycle) falls within a large range without revealing the specific value.

[0086] 4. Inner product proof, specifically, generating random vectors. ;calculate , Five rounds of recursion, each round presenting a challenge. It was eventually proven The total length is 672 bytes. Among them, , These are a pair of vectors obtained by decomposing the secret value to be proven; they are the core data that constitute the range proof. , A, S, and π are randomly generated blinding vectors used to hide the core vectors to achieve zero-knowledge; L and R are commitment values ​​calculated based on these vectors, serving as the public output of each round of recursion; e is a random challenge generated by hashing the commitment values, used to ensure the security of non-interactive arguments; the final π is a result proof containing parameters from multiple rounds of recursion, used by the verifier to confirm that the secret value satisfies specific conditions; A, S, and π are also present. , , , , These are all common parameters used for proof. For parameters related to the challenge value, , These are the two vectors used in the proof.

[0087] 5. Verification and If the verification passes, the zero-knowledge scope proof is successfully generated; otherwise, the generation fails.

[0088] This embodiment constructs a zero-knowledge scope for the current period, proving that carbon emissions in the current period have not exceeded the legal limit without disclosing the specific carbon emission figures, thus avoiding privacy leaks. It should be noted that, as shown in the above steps, the zero-knowledge scope proof π can only be successfully generated and signed if the total emissions within that period do not exceed the legal limit. If emissions exceed the limit, the zero-knowledge scope proof algorithm will be unable to generate a valid proof π.

[0089] Step S3: Generate a compliance ticket corresponding to the current cycle based on the digital signature and zero-knowledge scope proof. The compliance ticket is used to verify emission compliance.

[0090] Specifically, the compliant receipts for the current period are represented as follows: ;

[0091] in, This indicates a compliant receipt. This is the Merkle root corresponding to the current period (where m is the number of data records in the current period). For the digital signature corresponding to the Merkle root of the current period, Proof of the zero-knowledge scope for the current period.

[0092] Furthermore, when generating compliant receipts, Write to the header of the receipt. An example could be a hexadecimal string. The receipt uses TLV encoding, which facilitates direct memcpy operation using embedded C language during implementation.

[0093] This embodiment generates compact compliance receipts (≤1KB in length) based on digital signatures and zero-knowledge scope proofs, facilitating rapid verification of emissions compliance by regulatory agencies while balancing efficiency and safety. The use of TLV encoding and a fixed-length data format ensures data integrity, facilitates processing in embedded C language, and enables subsequent verification and parsing, thereby improving system efficiency and reliability.

[0094] Verifying emissions compliance using compliance receipts includes: verifying digital signatures on compliance receipts based on the enterprise's public key; and verifying zero-knowledge scope proofs on compliance receipts. Proof based on zero-knowledge scope Verify that a company's carbon emissions comply with regulations.

[0095] For compliant receipts verified in the current cycle, data synchronization is required.

[0096] Step S4: Calculate the fluctuation between the current period and the Merkle root of the previous period, and dynamically select whether to use a single-chain architecture or a dual-chain architecture to synchronize the data of compliant tickets in the current period based on whether the fluctuation exceeds a set threshold.

[0097] Specifically, when the fluctuation exceeds a set threshold, the system considers the emissions to have "jumped" and switches the data synchronously from a single-chain architecture to a dual-chain architecture. The dual-chain architecture includes a business chain and a traceability chain, and dynamically determines the number of shards based on the fluctuation. Each shard runs HotStuff consensus independently.

[0098] Furthermore, the fluctuation is calculated by XORing the current period's Merkle root with the previous period's Merkle root by bytes and counting the number of 1s, S. ,in This indicates the Merkle root length, which is 256 bits.

[0099] The number of fragments is determined using the following formula:

[0100] ceil represents rounding up. .

[0101] Furthermore, based on the compliant receipts of the current period, the parameters of each segment are determined, including:

[0102] View number: ;

[0103] Proposal block: ;

[0104] Consensus threshold: ;

[0105] in, This is the fragment number. Indicates time, The maximum waiting time is preferably 3 seconds. The proposal block number. This is the Merkle root corresponding to the current period. For fragmentation The number of potentially malicious nodes in the network. For safety parameters, the value range is usually between (2 / 3, 1), with a preferred value of 3 / 4. For view The corresponding number of validators.

[0106] In this embodiment, by considering whether the fluctuation amount of the current period and the previous period exceeds a set threshold, a single-chain architecture or a dual-chain architecture is dynamically selected for data synchronization of compliant tickets in the current period. When the threshold is exceeded, the number of shards in the dual-chain architecture is dynamically determined according to the threshold. This enables dynamic scaling of the number of channels based on the intensity of data fluctuations, rapidly expanding reasonable parallel throughput when data surges, and significantly reducing network bandwidth usage and node synchronization time.

[0107] Furthermore, the cross-agency carbon emission data synchronization method disclosed in this embodiment also includes step S5.

[0108] Step S5: Perform periodic consistency checks on the Merkle roots of the business chain and traceability chain based on the set second cycle.

[0109] Specifically, based on the consistency verification formula

[0110] A consistency check is performed. If the formula holds true, the business chain and the traceability chain are consistent; otherwise, they are inconsistent. This represents the Merkle root of the business chain. This represents the Merkle root of the traceability chain.

[0111] When the evidence stored in the business chain and the traceability chain is inconsistent, the system immediately triggers the "rollback and replay" process: first, the business chain is rolled back to the previous height (in blockchain, this refers to the height of the previous block), the suspicious transaction is cancelled, and then the gateway is allowed to resubmit the original ticket to the backup sub-channel. When a new block is generated, the comparison is repeated until the XOR result is zero, which means the verification result is consistent.

[0112] This embodiment provides reliable dual-chain consistency assurance by designing a dual-chain reconciliation mechanism for the business chain and the traceability chain. Combined with the automatic rollback function, it can quickly complete the rollback and replay when data inconsistency is detected, and restore consistency in a short time. This ensures a high degree of consistency and reliability of cross-organizational data and avoids the inefficiency and lag of traditional manual reconciliation.

[0113] Furthermore, in the cross-agency carbon emission data synchronization method disclosed in this embodiment, when the regulatory authority conducts real-time queries and compliance verification, the following steps are specifically included:

[0114] Regulatory authorities use enterprise codes and cycle numbers to search for corresponding compliant receipts;

[0115] Digital signatures in compliance receipts are verified using the enterprise's public key.

[0116] Zero-knowledge scope proof in verification compliance receipts ;

[0117] After all the above steps have been verified, the regulatory authorities will generate the corresponding emission compliance certificate.

[0118] This embodiment provides an efficient compliance verification function, enabling regulatory authorities to quickly obtain compliance receipts and automatically generate electronic compliance certificates with national cryptographic signatures. This greatly shortens the compliance verification cycle for enterprises, significantly improves regulatory efficiency and user experience, and provides solid technical support for application scenarios such as green finance and carbon trading.

[0119] Example 2

[0120] One embodiment of the present invention discloses a specific implementation process of a cross-agency carbon emission data synchronization method, specifically including steps S21-S25.

[0121] Step S21: Continuously acquire raw carbon emission data, and generate the corresponding Merkle root for each set period based on the raw carbon emission data of the current period.

[0122] Step S21 includes steps S21-1 to S21-4.

[0123] S21-1, The edge gateway continuously acquires locally collected raw carbon emission data through sensors or detection devices. It includes step ae.

[0124] a. Pre-collection of measuring points and installation of instruments (sensors or detection equipment).

[0125] For example, a φ50mm hole is vertically drilled at 0.5H in the main flue of the boiler emitting carbon emissions. The hole opening is then ground to remove burrs, and an infrared CO2 analyzer probe is inserted. The probe length is 800mm, ensuring the sampling point is located in the core area of ​​the airflow. The instrument has a range of 0-20%vol, a resolution of 0.01%vol, a factory error of ±0.3%vol, a built-in 4-20mA two-wire output, a load resistance of 250Ω, and corresponds to instantaneous emissions of 0-20kg / s. The probe's outer sheath is made of 316L stainless steel, resistant to 300℃, to prevent high-temperature corrosion. Figure 2 This is a table illustrating the meaning and value range of each parameter in step a.

[0126] b. Electrically isolate the equipment before collecting raw carbon emission data.

[0127] The instrument's 4-20mA signal is led to the PLC analog module via shielded twisted-pair cable (RVVP2×1.5mm²). The module has a 16-bit ADC with a sampling current resolution of 0.1μA, equivalent to 0.002kg / s. The PLC RS-485 port is connected to the edge gateway through an ADM2483 isolation chip with an isolation voltage of 2.5kV to suppress ground loop current and ensure no code loss during long-distance transmission.

[0128] c. Establish BeiDou / GPS time reference for edge gateways.

[0129] After the gateway is powered on, the BeiDou / GPS dual-mode module prioritizes locking onto BeiDou and outputs a PPS pulse (1Hz, 100ms width) with an error of <5ms. The rising edge of the PPS pulse triggers the MCU hardware timer, which generates a "second interrupt" every 1000ms. The interrupt service routine immediately reads the PLC register to ensure that the timestamp is strictly aligned with UTC milliseconds, thus avoiding the accumulation of network latency.

[0130] d. Serial port interrupts and circular buffers of data transmission devices

[0131] The MCU is configured with USART1 at 9600bps, 8E1, and DMA double buffering. Every 8 bytes (1 data record) received triggers a DMA interrupt, and the ISR writes the data to a circular buffer (256 records in length, 16 bytes per element: 8-byte timestamp + 8-byte emission value). The main loop polls every 10ms; if the buffer is half full, it immediately preprocesses the data to prevent sudden overflow.

[0132] e. Perform second pulse verification on the edge gateway.

[0133] Specifically, every 30 seconds, the gateway compares the number of PPS pulses with the local RTC count. If the difference is greater than 2ms, the RTC is immediately corrected using BeiDou time, and the correction record is written to Flash for post-audit.

[0134] S21-2. Divide the acquired raw carbon emission data into time granularities and add a corresponding timestamp after the data of each time granularity to obtain the data record corresponding to each time granularity.

[0135] Preferably, raw carbon emission data is collected at a frequency of 1Hz, with "seconds" as the time granularity and a cycle of 30 seconds, resulting in 30 raw carbon emission data points per cycle. In implementation, time calibration needs to be accurate to the millisecond level. A corresponding timestamp is added to the data after each second to obtain 30 data records for that cycle.

[0136] The following are the specific carbon emission values ​​for each second within a 30-second cycle, in kg:

[0137] d=[8.1,7.9,8.3,8.0,8.2,8.1,8.4,8.0,7.8,8.2,8.3,8.1,8.0,8.2,8. 1,8.3,8.0,7.9,8.1,8.2,8.0,8.1,8.3,8.2,8.1,8.0,8.2,8.1,8.0,8.1]

[0138] 243.3kg≤300kg (legal upper limit).

[0139] Based on the start time t0 = 1693555200000ms (Unix ms), the timestamps of each data are obtained as t = [1693555200000, 1693555201000, ..., 1693555229000].

[0140] Furthermore, in implementation, a second counter is used for triggering. The 32-bit second counter inside the MCU (microcontroller unit) is incremented by PPS pulses (pulses per second). When the counter = 30, a "block ready" event is generated, triggering DMA (direct memory access) to copy the first 30 elements of the circular buffer to the "block cache", which is fixed at 480 bytes (30×16). The copying process is completed by DMA without occupying the CPU.

[0141] Furthermore, during implementation, outlier cases are sequentially assessed for each of the 30 emission values: if d i <0 or d i >10kg, marked as abnormal; if |d i -d i-1 A value exceeding 5kg is marked as an anomaly. The anomaly is calculated by linear interpolation using the value from the previous second, and a 1-bit interpolation flag is added for subsequent auditing and tracing. It's important to note that identifying anomalies ensures data continuity and smooths data fluctuations: First, carbon emission data is continuous time-series data, and "holes" or abrupt changes that clearly violate physical laws are highly undesirable. When anomalies are detected, linear interpolation is used to replace them, ensuring the continuity of the data flow, which is crucial for many subsequent processing steps. Second, abrupt changes can directly cause drastic changes in the Merkle root. Therefore, automatically correcting anomalies during implementation avoids "pseudo-fluctuations" caused by single sensor failures or interference, thus preventing unnecessary performance scaling (such as false triggering of sharding), helping to maintain system stability, and allowing computing power to be used for genuine business fluctuations.

[0142] Furthermore, during implementation, a total summation and checksum are performed in each cycle. Specifically, a 4-byte sum Σd is appended to the end of the block cache in each cycle. i Add another 2 bytes of checksum (simple checksum) to ensure no code is lost during transmission.

[0143] Furthermore, during implementation, after the current cycle ends, the circular buffer and the second counter are reset, and new second data continues to be written, achieving "seamless rolling" between cycles.

[0144] S21-3. Calculate the corresponding hash value for each of the multiple data records in the current period.

[0145] When i=0: Input byte stream = 0x0000017E69D76C004044000000000000 (8B timestamp + 8B IEEE-754 double precision), where i represents the sequence number of the data in the current period.

[0146] h0 = SHA - 256(0x0000017E69D76C004044000000000000) = 0x3a6f…b821 (256-bit hexadecimal), and h1…h can be calculated similarly. 29 Where h0 represents the hash value corresponding to the 0th data item in the current period;

[0147] In implementation, for each fixed 16-byte data entry, the embedded system stores the first 8 bytes as a little-endian Unix timestamp (Unix timestamp) and the last 8 bytes as a little-endian carbon emission value, with the least significant bit first, for easy direct reading by the MCU. The MCU is configured with the SHA-256 hardware engine in "peripheral-triggered" mode (DMA handles data transfer without CPU intervention). The DMA automatically triggers a hash calculation every 16 bytes, writing the 256-bit result to the "leaf array" node[0…29], totaling 960 bytes. The leaf array address needs to be aligned to a 32-byte boundary for SIMD (Single Instruction Multiple Data) loading. The DMA uses a double-buffering mechanism, alternating between two buffers: one for the current hash calculation and the other for the next data transfer. Once all hash calculations are complete, the DMA generates a completion interrupt, the MCU disables the HA-256 hardware engine, and the leaf array is set to read-only for subsequent S21-4 Merkle tree calculations.

[0148] S21-4. Construct a full binary Merkle tree based on all hash values ​​in the current period and generate the corresponding Merkle root. Specifically:

[0149] Place all hash values ​​of the current period as leaf nodes at the bottom level of the Merkle tree;

[0150] The Merkle tree is constructed layer by layer from bottom to top: each node in each layer is a combination of the hash values ​​of its two child nodes; if the number of leaf nodes is odd, the last node is copied to ensure that the tree is a full binary tree; a hash operation is performed on each pair of leaf nodes to generate the hash value of the parent node;

[0151] Continue until you reach the top of the tree and obtain the Merkle root.

[0152] For example, a period consists of 30 data points, represented by the Merkle root as follows: The following is the specific process of constructing a binary tree:

[0153] level0 (leaf node): node[0]=h0,…,node

[29] =h 29 ;

[0154] level1: node

[30] =SHA-256(node[0]∥node[1])…node

[44] =SHA-256(node

[28] ∥node

[29] );

[0155] level2: node

[45] =SHA-256(node

[30] ∥node

[31] )…node

[52] =SHA-256(node

[42] ∥node

[43] );

[0156] level3: node

[53] =SHA-256(node

[45] ∥node

[46] )…node

[56] =SHA-256(node

[51] ∥node

[52] );

[0157] level4: node

[57] =SHA-256(node

[53] ∥node

[54] ), node

[58] =SHA-256(node

[55] ∥node

[56] );

[0158] level5 (root): R 30 =SHA-256(node

[57] ∥node

[58] )=0x4b3c27a1f2e8…(32Byte length).

[0159] This embodiment reduces on-chain storage by more than 90% by compressing the preferred 30-second period of the Merkle root and merging 30 high-frequency data into a single 256-bit hash value. By constructing a Merkle tree with a height of 5, it satisfies the second preimage resistance, effectively preventing data from being tampered with.

[0160] Step S22: Obtain the corresponding digital signature based on the Merkle root of the current period, and construct the zero-knowledge range proof of the current period.

[0161] Specifically, the SM2 algorithm is used to obtain the corresponding digital signature based on the Merkle root of the current period. The signature process includes:

[0162] Based on the pre-set curve parameters, enterprise identity ID, and public key coordinates, a 32-byte Z value is preprocessed. During implementation, the curve parameters are stored in the chip ROM. The chip concatenates the enterprise identity ID and public key coordinates into a 64-byte data block and uses the hardware SM3 algorithm to perform hash calculation, efficiently generating a 32-byte Z value. The Z value is cached for 24 hours so that it can be reused when needed.

[0163] The preprocessed 32-byte value is concatenated with the Merkle root to form a new data block. The SM3 hash algorithm is then used to perform a hash calculation on the concatenated data block, e = SM3(Z∥M), where M = R. 30 This yields a 256-bit (32-byte) hash value. e ;

[0164] 256 bits k are extracted from a true random source and multiplied by k·G on an elliptic curve, where G is the base point of the elliptic curve, to obtain (x1, y1). The adjacent x1 is extracted to calculate r and s. The signature σ is composed of r and s and has a length of 64 bytes.

[0165] Specifically, a zero-knowledge scope proof for the current cycle is constructed based on the Bulletproofs protocol. During construction, the objective is to prove that... , This represents the total carbon emissions for the current cycle. Indicates the current period number Carbon emissions at a time granularity; publicly available parameters are... , The number of data records in the current period. This is the upper limit for emissions per second.

[0166] During implementation, the objective is The proof process is the same as steps 1-5 in Example 1.

[0167] Step S23: Generate a compliance ticket corresponding to the current cycle based on the digital signature and zero-knowledge scope proof. The compliance ticket is used to verify emission compliance.

[0168] Specifically, the compliant receipts for the current period are represented as follows: ;

[0169] in, This indicates a compliant receipt. This is the Merkle root corresponding to the current period (where m is the number of data records in the current period). For the digital signature corresponding to the Merkle root of the current period, Proof of the zero-knowledge scope for the current period.

[0170] Furthermore, when generating compliant receipts, Write to the header of the receipt. An example could be a hexadecimal string. The receipt uses TLV encoding, which facilitates direct memcpy operation using embedded C language during implementation.

[0171] In this embodiment, by employing zero-knowledge scope proof technology, the emissions are proven to be within the legal range without disclosing specific emission values, thus meeting the enterprise's data confidentiality requirements.

[0172] Step S24: Calculate the fluctuation between the current period and the Merkle root of the previous period, and dynamically select whether to use a single-chain architecture or a dual-chain architecture to synchronize the data of compliant tickets in the current period based on whether the fluctuation exceeds a set threshold.

[0173] Specifically, when the fluctuation exceeds a set threshold, the system considers the emissions to have "jumped", synchronizes the data from a single-chain architecture to a dual-chain architecture, and dynamically determines the number of shards based on the fluctuation, with each shard running HotStuff consensus independently.

[0174] Furthermore, the fluctuation is calculated by XORing the current period's Merkle root with the previous period's Merkle root by bytes and counting the number of 1s, S. ,in This indicates the length of the Merkle root, which is 256.

[0175] The number of fragments is determined using the following formula:

[0176] ceil represents rounding up. .

[0177] For example, when the threshold At that time, if ,but The system recognizes that emissions have "jumped" and switches from a single-chain architecture to a dual-chain architecture, replicating the original HotStuff consensus channel (shard) into two independent subnets (shards) within 3 seconds.

[0178] Furthermore, based on the compliant receipts of the current period, the parameters of each segment are determined, including:

[0179] View number: ;

[0180] Proposal block: ;

[0181] Consensus threshold: ;

[0182] in, This is the fragment number. Indicates time, The maximum waiting time is set. The proposal block number. This is the Merkle root corresponding to the current period. For fragmentation The number of potentially malicious nodes in the network. For view The corresponding number of validators.

[0183] For example, the end timestamp of the current period is 1693555230. ; Preset number of validators , ;but = 3, That is, a channel with 4 validators can tolerate 1 malicious node, while a channel with 6 validators can tolerate 2 malicious nodes.

[0184] Furthermore, during implementation, when Δ is less than the set threshold for three consecutive cycles, N is automatically decremented by 1 until N=1, releasing network resources.

[0185] In this embodiment, the number of shards is determined based on the volatility, and each shard runs HotStuff consensus independently. The throughput of a single shard is ≥3000 TPS (transactions per second), achieving a total throughput of 3000 TPS×N, effectively solving the single-chain bottleneck problem that may be caused by large fluctuations in carbon emission data.

[0186] Furthermore, the cross-agency carbon emission data synchronization method disclosed in this embodiment also includes step S25.

[0187] Step S25: Perform periodic consistency checks on the Merkle roots of the business chain and traceability chain based on the set second cycle.

[0188] Specifically, based on the consistency verification formula A consistency check is performed. If the formula holds true, the business chain and the traceability chain are consistent; otherwise, they are inconsistent. This represents the Merkle root of the business chain. This represents the Merkle root of the traceability chain.

[0189] When the evidence stored in the business chain and the traceability chain is inconsistent, the system immediately triggers the "rollback and replay" process: first, the business chain is rolled back to the previous height (in blockchain, this refers to the height of the previous block), the suspicious transaction is cancelled, and then the gateway is allowed to resubmit the original ticket to the backup sub-channel. When a new block is generated, the comparison is repeated until the XOR result is zero, which means the verification result is consistent.

[0190] In this embodiment, the dual-chain Merkle root-to-table mechanism ensures data consistency between the business chain and the traceability chain, thereby improving system credibility and auditing capabilities. In terms of convenient compliance verification, the generated receipt structure is compact (≤1KB), which facilitates regulatory agencies to quickly verify emission compliance, balancing efficiency and safety.

[0191] Furthermore, in the cross-agency carbon emission data synchronization method disclosed in this embodiment, when the regulatory authority conducts real-time queries and compliance verification, the following steps are specifically included:

[0192] Regulatory authorities can search for corresponding compliant receipts based on enterprise codes and cycle numbers; batch queries can be implemented during implementation.

[0193] The digital signature in the compliance receipt is verified based on the enterprise's public key; during implementation, the regulator can run it locally without relying on the enterprise's system.

[0194] Zero-knowledge scope proof based on verification of compliance receipts using total commitments. ;

[0195] After all the above steps have been verified, the regulatory authorities will generate the corresponding emission compliance certificate.

[0196] This embodiment provides an efficient compliance verification function, enabling regulatory authorities to quickly obtain compliance receipts and automatically generate electronic compliance certificates with national cryptographic signatures. This greatly shortens the compliance verification cycle for enterprises, significantly improves regulatory efficiency and user experience, and provides solid technical support for application scenarios such as green finance and carbon trading.

[0197] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for synchronizing carbon emission data across institutions, characterized in that, Includes the following steps: Continuously acquire raw carbon emission data, and generate the corresponding Merkle root for each set period based on the raw carbon emission data of the current period; Based on the Merkle root of the current period, obtain the corresponding digital signature and construct the zero-knowledge range proof of the current period. Based on the digital signature and zero-knowledge scope proof, a compliance ticket corresponding to the current cycle is generated, and the compliance ticket is used to verify emission compliance; Calculate the fluctuation between the current period and the Merkle root of the previous period, and dynamically select either a single-chain architecture or a dual-chain architecture to synchronize the data of compliant tickets for the current period based on whether the fluctuation exceeds a set threshold.

2. The carbon emission data synchronization method according to claim 1, characterized in that, The continuous acquisition of raw carbon emission data, and the generation of the corresponding Merkle root based on the raw carbon emission data of the current period within each set period, includes: The raw carbon emission data were divided into time granularities, and a corresponding timestamp was added after the data of each time granularity to obtain the data records corresponding to each time granularity. Calculate the corresponding hash value for each of the multiple data records in the current period; Construct a full binary Merkle tree based on all hash values ​​of the current period and generate the corresponding Merkle root.

3. The carbon emission data synchronization method according to claim 2, characterized in that, The zero-knowledge range proof for constructing the current period includes: Constructing a zero-knowledge scope proof for the current period based on the Bulletproofs protocol ; During construction, the objective is to prove that , This represents the total carbon emissions for the current cycle. Indicates the current period number Carbon emissions at a time granularity; publicly available parameters are... , The number of data records in the current period. This is the upper limit for emissions per second.

4. The carbon emission data synchronization method according to claim 3, characterized in that, The process of generating the compliance receipt corresponding to the current period based on the digital signature and zero-knowledge scope proof includes: ； in, This indicates a compliant receipt. This is the Merkle root corresponding to the current period. For the digital signature corresponding to the Merkle root of the current period, Proof of the zero-knowledge scope for the current period.

5. The carbon emission data synchronization method according to claim 4, characterized in that, The dynamic selection of single-chain or dual-chain architecture for compliant ticket data synchronization in the current period based on whether the volatility exceeds a set threshold includes: When the volatility exceeds a set threshold, the data synchronization task dynamically switches to a dual-chain architecture, initiates a sharding mechanism, and distributes the data synchronization task to N parallel consensus shards for processing. The number of shards N is dynamically determined based on the volatility, and each shard runs HotStuff consensus independently.

6. The carbon emission data synchronization method according to claim 5, characterized in that, Based on the compliant receipts of the current period, the parameters of each segment are determined, including: View number: ; Proposal block: ; Consensus threshold: ; in, This is the fragment number. Indicates time, The maximum waiting time is set. The proposal block number. This is the Merkle root corresponding to the current period. For fragmentation The number of potentially malicious nodes in the network. For safety parameters, For view The corresponding number of validators.

7. The carbon emission data synchronization method according to any one of claims 1-6, characterized in that, The dual chains include a business chain and a traceability chain. The carbon emission data synchronization method further includes: performing periodic consistency checks on the Merkle roots stored in the business chain and the traceability chain based on a set second period.

8. The carbon emission data synchronization method according to claim 7, characterized in that, The periodic consistency verification of the Merkle root stored in the business chain and traceability chain based on the established second cycle includes: Based on consistency check formula Perform a consistency check. If the formula is true, the business chain and the traceability chain are consistent; otherwise, they are inconsistent. in, This represents the Merkle root of the business chain. This represents the Merkle root of the traceability chain.

9. The carbon emission data synchronization method according to claim 2, characterized in that, The SM2 algorithm is used to obtain the corresponding digital signature based on the Merkle root of the current period.

10. The carbon emission data synchronization method according to claim 2, characterized in that, The process of constructing a full binary Merkle tree based on all hash values ​​of the current period and generating the corresponding Merkle root includes: Place all hash values ​​of the current period as leaf nodes at the bottom level of the Merkle tree; The Merkle tree is constructed layer by layer from bottom to top: each node in each layer is a combination of the hash values ​​of its two child nodes; if the number of leaf nodes is odd, the last node is copied to ensure that the tree is a full binary tree; a hash operation is performed on each pair of leaf nodes to generate the hash value of the parent node; Continue until you reach the top of the tree and obtain the Merkle root.

Images