A carbon factor trusted version synchronization management method

Abstract

The present application relates to the technical field of carbon accounting data governance, in particular to a carbon factor credible version synchronization management method, which converts carbon factor records into verifiable version objects and constructs an effective version set; initiatively collects version change premonitory signals, generates a time expansion compatible area and a transition curve commitment; calculates a double-entropy normalized value in combination with target node accounting sensitivity, solves an optimal switching time slot and generates a differentiated synchronization patch; generates a compliance proof that does not leak sensitive data through a zero-knowledge proof circuit; binds to generate a credible synchronization package, supports version recovery with a smooth rebound curve and historical data reproduction.

Description

Technical Field

[0001] This invention relates to the field of carbon accounting data governance technology, and more specifically, to a method for synchronizing and governing trusted versions of carbon factors. Background Technology

[0002] Carbon factors are the core foundational data of the carbon accounting system, widely used in various scenarios such as enterprise carbon emission accounting, carbon emission trading, and product carbon footprint certification. The accurate synchronization and reliable governance of carbon factors directly affect the consistency, compliance, and traceability of carbon accounting results, making it a key technical aspect that urgently needs improvement in the current carbon data management field. Carbon factors are characterized by diverse sources, high update frequency, and significant differences in applicable domains. Carbon factors vary significantly across different regions, industries, and processes, and change with policy adjustments, technological advancements, and updates to accounting standards.

[0003] Current carbon factor version synchronization largely adopts a passive triggering model, initiating the synchronization process only after the official release of a new version. This lacks mechanisms for early prediction and transitional adaptation of version changes, easily leading to abrupt changes in accounting data at version switching points, requiring significant manual data verification and correction. Synchronization strategies typically use globally unified time nodes, failing to differentiate based on the accounting task progress, report lock-in period, business operation cycle, and resource load of different nodes. This may cause significant governance impacts and even affect the normal business operation of nodes. During compliance verification, target nodes are usually required to submit complete activity data, factor values, and accounting details, posing a risk of leakage of sensitive information such as enterprise production and operation data. When version release anomalies or prediction errors necessitate rollback, the common approach is to directly switch to the old version, which can easily cause secondary data jumps, disrupting the continuity of historical accounting data and increasing the difficulty of subsequent audits and data reproduction.

[0004] Therefore, this invention proposes a method for the synchronous management of trusted versions of carbon factors. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a method for the synchronous management of trusted versions of carbon factors.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A method for managing the synchronization of trusted versions of carbon factors specifically includes the following steps:

[0008] Step S1: The server converts carbon factor records into predictable, synchronizable, and verifiable version objects, generates factor value commitments for version objects that have passed the publisher's signature verification, constructs a verifiable and valid version set and saves the root digest of the set, and identifies carbon factor semantic objects based on version metadata and applicable domains.

[0009] Step S2: The server actively collects and encodes multiple types of version change precursor signals at fixed intervals, matches the precursor signals with the applicable domain of the version object, calculates the version change probability, and generates a time dilation compatibility zone and corresponding transition curve commitment when the preset trigger conditions are met.

[0010] Step S3: After the server verifies the official new version object, it combines the accounting sensitivity summary submitted by the target node to calculate the normalized value of the dual entropy of data deviation and governance impact, solves the optimal switching time slot of the target node, and generates the switching decision commitment and the corresponding synchronization patch of the differentiated synchronization strategy.

[0011] Step S4: After the target node completes the accounting calculation, it executes the zero-knowledge proof compliance verification circuit to generate a compliance proof that does not disclose sensitive data. The proof content covers version authenticity, time validity, transition state legality, switching strategy consistency and accounting calculation correctness. Circuit constraints prevent the abuse of the transition compatibility area.

[0012] Step S5: The server binds the version object, various commitments, synchronization patches, and compliance certificates to generate a digitally signed trusted synchronization package. The target node executes the trusted synchronization package. In case of prediction failure, the version is restored and historical accounting data is reproduced through a rebound patch with a smooth rebound curve.

[0013] Furthermore, in step S1, the server receives carbon factor data submitted by the carbon factor publisher and generates a version object for each carbon factor, which includes a version identifier, factor value, applicable information, publisher summary, evidence summary, version status, and version metadata. The server identifies two carbon factors with different publication numbers but consistent version metadata and applicable domains as different publication forms of the same semantic object, and identifies carbon factors with the same name but different applicable domains, units, or accounting systems as different semantic objects.

[0014] Furthermore, in step S1, the server generates a version identifier by concatenating the publisher's public key hash with the time slot; the server writes the factor value commitment into the valid version set and generates a corresponding member path for each version commitment; the server and the target node pre-agree on the encoding method of the integer time slot so that subsequent curve calculation, time comparison and zero-knowledge proof circuit comparison are all completed in the integer field.

[0015] Furthermore, in step S2, the server collects early warning signals by connecting to public data sources, industry databases, and the pre-notification interface of the publishing end. Each early warning signal is encoded into a signal object containing a signal identifier, signal type, applicable domain, direction of change, magnitude of change, credibility, time effect, and evidence summary. The server matches the applicable domain of the early warning signal with the applicable domain of the version object according to the dimensions of region, industry, process, energy type, time granularity, and accounting system.

[0016] Furthermore, in step S2, the server calculates the version change risk increment based on the signal matching result, signal strength, signal credibility, and time effect value, and then calculates the version change probability based on the accumulated version change risk increment; the server performs weighted median processing on the signed change amplitude of the candidate signal to obtain the prediction correction ratio, generates a time dilation transition curve based on the prediction correction ratio, and generates a transition curve commitment containing transition curve parameters.

[0017] Furthermore, in step S3, after the server obtains the official new version object, it verifies the version identifier, applicable domain, applicable time, publisher summary, evidence summary, and accounting system identifier; if the new version is not released within the expected window, the direction of change is inconsistent with the predicted direction, or the actual change exceeds the predicted range, the server generates a rebound patch or re-executes the warning signal processing procedure.

[0018] Furthermore, in step S3, the server calculates the normalized value of data deviation and the normalized value of governance impact based on the accounting sensitivity summary submitted by the target node. The server then selects the optimal switching time slot from the set of candidate switching time slots determined by the report lock-in period, mandatory compliance period, node available synchronization window, and business operation cycle, and finds the time slot that minimizes the weighted sum of data deviation and governance impact.

[0019] Furthermore, in step S3, the server generates a switching decision commitment that includes the optimal switching time slot and synchronization strategy; the server generates a synchronization patch that includes forward and reverse operations; before the target node executes the patch, it verifies that the prior state summary is consistent with the local state; idempotent tokens are used to prevent the same patch from being executed repeatedly; and reverse operations are used to achieve version recovery.

[0020] Furthermore, in step S4, the target node first converts the activity data, factor values, and accounting results into fixed-point integers, and then executes the zero-knowledge proof compliance verification circuit; the circuit generates multiple Boolean intermediate signals to verify the consistency of factor value commitments, member affiliation relationships, time validity, switching state consistency, and accounting calculation correctness, respectively.

[0021] Furthermore, in step S4, the zero-knowledge proof compliance verification circuit determines the allowable factor value range based on the accounting time slot, version status, transition curve commitment, and switching decision commitment, and constrains the factor values ​​actually used by the target node to be within the allowable error range; the circuit selects the corresponding fixed-point accounting function based on the accounting system identifier to verify the correctness of the accounting results.

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

[0023] 1. To address the issues of unpredictable carbon factor version changes and unreasonable synchronization timing leading to accounting data deviations and governance impacts, this invention employs a technique of actively collecting multiple types of version change precursor signals and encoding them as signal objects. Through signal matching and parameter calculation, the probability of version changes is predicted. When triggering conditions are met, a time dilation compatibility zone and transition curve commitment are generated, making version changes a pre-adaptable time process. Simultaneously, by combining the accounting sensitivity summary submitted by the target node, the normalized value of the dual entropy of data deviation and governance impact is calculated. The optimal switching time slot is then determined from the candidate switching time slot set, generating a synchronization patch for a differentiated synchronization strategy. This helps reduce accounting data deviations and minimizes the impact of version synchronization on node business operations.

[0024] 2. To address the issues of sensitive data leakage and historical data inconsistency caused by unstable version recovery in existing compliance verification processes, this invention employs a zero-knowledge proof compliance verification circuit. Activity data, factor values, and calculation results are converted into fixed-point integers before circuit verification, generating compliance proofs covering multiple dimensions such as version authenticity and time validity. Compliance verification is completed without leaking sensitive data. Simultaneously, version recovery is achieved through a rebound patch with a smooth rebound curve, gradually returning to the target version state along the rebound curve. Historical calculation data is also marked and reviewed, helping to maintain the consistency and reproducibility of historical calculation data. Attached Figure Description

[0025] Figure 1 A flowchart of a trusted version synchronization governance method for carbon factors;

[0026] Figure 2 This is a flowchart illustrating the implementation steps of the precursor signal processing and time dilation compatibility region generation for this invention version change.

[0027] Figure 3 This is a flowchart illustrating the implementation steps of the dual-entropy switching decision and synchronization patch generation in this invention. Detailed Implementation

[0028] Example, refer to Figure 1 The carbon factor trusted version synchronization governance method of this embodiment specifically includes the following steps:

[0029] Step S1: Generate the carbon factor version object and the set of valid versions.

[0030] The server converts carbon factor records into predictable, synchronizeable, and verifiable version objects, forming a valid version set summary. Subsequent precursor prediction, transition compatibility, dual-entropy switching, and ZKP proof (zero-knowledge proof) all use this version object and its set summary.

[0031] S11, Carbon Factor Version Object Generation:

[0032] The server receives carbon factor data submitted by the carbon factor publisher and generates a version object for each carbon factor. The version object includes a version identifier. Factor values ,unit Applicable regions Applicable industries Applicable processes Applicable time start point Applicable time end point Accounting system identification Summary of the publisher Evidence Summary Version status and version metadata ;

[0033] Version identifier Generated by concatenating the publisher's public key hash with a timestamp, ensuring global uniqueness; Publisher digest The hash result of the issuer's digital certificate public key; evidence digest Hash results for carbon factor supporting materials; version status It includes five possible values: pending activation, in effect, in transition, expired, and bounce-back.

[0034] S12, Integer Time Slot Convention:

[0035] In this embodiment, all times are represented using integer time slots. The granularity of the time slots is determined by the accounting system. For example, hourly factors use hourly slots, annual factors use annual slots, and project cycle factors use project cycle slots. The encoding method of the time slots is pre-agreed between the server and the target node, so that subsequent curve calculations, time comparisons, and ZKP circuit comparisons are all completed within the integer domain.

[0036] S13, Construction of the valid version set:

[0037] The server generates a factor value commitment for the version object verified by the publisher's signature and writes the commitment into the valid version set. The valid version set is implemented using a verifiable set, such as a Merkle tree, a sparse Merkle tree, or a verifiable accumulator; the server stores the root digest of the set. And commit to generating member paths for each version. In a ZKP circuit, the target node passes through... It proves that the factor commitments it uses belong to the set of valid versions without having to repeatedly perform complex publisher signature verification in the circuit;

[0038] Factor value commitments are the hash concatenation results of factor values ​​and version metadata in version objects; leaf nodes of a Merkle tree are single factor value commitments, and internal nodes are the concatenation results of hashes of child nodes.

[0039] S14, Carbon Factor Semantic Object Recognition:

[0040] Version metadata It should include at least the applicable domain, applicable time, unit, accounting system, publisher summary, and evidence summary. The applicable domain includes four dimensions: region, industry, process, and energy type. If two carbon factors have different publication numbers but the version metadata and applicable domain are the same, the server will identify them as different publication forms of the same semantic object. If they have the same name but different applicable domains, units, or accounting systems, the server will identify them as different semantic objects to avoid cross-scenario synchronization errors. The publication number is a unique identifier for the carbon factor assigned by the publisher.

[0041] Step S2: Version change precursor signal processing and time dilation compatibility zone generation.

[0042] like Figure 2 As shown, the server maps the precursor signals to specific carbon factors and generates a transitional compatibility zone before the official release of the new version, so that version changes are no longer sudden events, but a time process that can be adapted to in advance.

[0043] S21. Acquisition and encoding of precursor signals:

[0044] The server collects precursor signals at fixed intervals. Each precursor signal is encoded into a signal object, which includes a signal identifier and a signal type. The fields include the scope of impact, direction of change, magnitude of change, credibility, time effect, and evidence summary; the signal type can be a policy signal, technical signal, academic signal, or market signal, and the server calculates directly according to the fieldization rules;

[0045] Signal acquisition is achieved by connecting to public data sources, industry databases, and pre-notification interfaces of the publishing end; the change magnitude field is the relative change ratio of the factor value indicated by the signal, with a value range of 0 to 1; the time effect field includes the effective start time slot and the effective end time slot of the signal.

[0046] S22. Signal matching and parameter calculation:

[0047] The server matches the signal's applicable domain with the version object's applicable domain. Matching dimensions include region, industry, process, energy type, time granularity, and accounting system. The matching result is... Its value is between 0 and 1, and is obtained by normalizing the overlap of the matching dimensions; signal strength Obtained by normalization of the change amplitude field; signal reliability The time-based value is determined by the source signature, the integrity of the evidence, the validity of the publication time, and the consistency of the repeat signal. Indicates the signal in the time slot The effectiveness of the signal decreases when the signal exceeds the effective window;

[0048] Matching results The calculation method is the ratio of the number of successfully matched dimensions to the total number of matched dimensions; signal strength This is the ratio of the change range field to the maximum permissible change range, the maximum permissible change range being specified by the accounting system; signal reliability. The weighted average of the scores for each evaluation item, with scores ranging from 0 to 1; time factor. The linear attenuation function is used for calculation, with a value of 1 in the effective start time slot and a value of 0 in the effective end time slot.

[0049] S23, Version Change Probability Prediction:

[0050] For the target carbon factor The server is in the time slot Calculate the incremental risk of version change:

[0051] ;

[0052] in, This represents a dimensionless increment of risk. In the time slot With carbon factor The set of signals applicable to the domain matching; The signal type weight is configured by the carbon factor category and the calculation scenario, and its value ranges from 0 to 1. and All are dimensionless values;

[0053] The server is at the prediction starting point Up to the current time slot Calculate the probability of version change between:

[0054] ;

[0055] in, This is a dimensionless probability value; For discrete time slot variables; This is the start time slot for this round of predictions, usually the time slot of the most recent official version confirmation or the time slot of the most recent prediction reset. If the preset triggering conditions are met, the server generates a time dilation compatibility zone. The preset triggering conditions are configured through accounting system rules.

[0056] S24. Generation of time dilation transition curve:

[0057] Forecast correction ratio The signed change amplitude of the candidate signal is obtained by weighted median processing, where the signed change amplitude is a dimensionless proportion, and the factor value is expected to decrease. When the value is positive, the factor value is expected to increase. If the signal direction is scattered and cannot form a stable direction, the server only generates a shadow transition curve and does not allow it to enter the formal calculation output.

[0058] Weights in weighted median processing and the corresponding signal reliability Proportional;

[0059] Let the old version factor value be Its dimension is emission units divided by activity units, and the transition start time slot is... The expected release time slot is In the time slot At this point, the transition compatibility factor is:

[0060] ;

[0061] in, Dimensions and same; It is a dimensionless correction function; This is a dimensionless time schedule; This represents a truncation function whose output is neither less than 0 nor greater than 1; It is determined by the expected release time slot, the lead time of the precursor signal, and the sensitivity of the target node. The lead time of the precursor signal is the time slot difference between the signal acquisition time and the expected release time. Determined by inferring results from the expected release time, version release plan, or time window in the signal;

[0062] S25, Transition Curve Commitment Generation:

[0063] Server-side generation of transition curve commitment The commitment fields include the old version summary, , , The curve type, allowable error parameters, and curve parameter summary are specified. The commitment is the hash result of concatenating all fields. After receiving the commitment, the target node does not directly trust the plaintext curve but uses the commitment to constrain the actual usage factor value in subsequent ZKP circuits.

[0064] Step S3: Dual-entropy switching decision and synchronization patch generation.

[0065] like Figure 3 As shown, the server determines the optimal switching time slot for the target node after a new version is released or after entering the prediction window.

[0066] S31. New version object validation:

[0067] Once the server obtains the official new version object, it first verifies the version identifier, applicable domain, applicable time, publisher summary, evidence summary, and accounting system identifier. If the new version passes the verification, it enters the dual-entropy switching decision. If the new version is not released in the expected window, or the direction of the new version change is inconsistent with the predicted direction, or the actual change exceeds the predicted range, the server generates a bounce patch or re-enters S2.

[0068] S32. Submission of sensitivity summary for accounting:

[0069] The target node submits a sensitivity summary to the server. This summary does not contain detailed activity data, but includes the range of the number of affected tasks, the upper bound of the activity bucket, the report status, the node resource status, and the downstream dependency status.

[0070] The number of affected tasks is divided into ranges based on orders of magnitude; the upper limit of activity volume is divided into buckets based on the order of magnitude standards stipulated in the accounting system; the reporting status includes four values: not started, in progress, completed, and disclosed; the node resource status includes four values: idle, normal, busy, and overloaded; the downstream dependency status includes three values: no dependency, weak dependency, and strong dependency.

[0071] S33. Calculation of the normalized value of double entropy:

[0072] The server uses this summary to calculate the normalized value of the data deviation:

[0073] ;

[0074] in, For the target node In the time slot Dimensionless data deviation value; For the target node The set of accounting tasks affected in China; The weight is the importance weight of the task, which is determined by whether the task involves audit, regulatory submission, export certification or internal calculation, and the value ranges from 0 to 1. For time slots The reference factor value is used when a new version has been released, and when it is still in the transition period, the allowable transition value is used. The factor value currently used by the target node; For the task The corresponding activity level upper bound or normalized activity level has units that match the factor activity level units. The granularity coefficient is used for disclosure, with a value ranging from 0 to 1. The finer the granularity, the larger the value. The deviation normalization benchmark for the target node is in units of emissions, determined by the node reporting granularity, task scale, and compliance tolerance range, and obtained through statistical analysis of historical accounting data of the node.

[0075] The normalized value of the governance impact is determined according to the following formula:

[0076] ;

[0077] in, This represents the dimensionless impact value of governance. The set of impact factors for the target node includes computing resource consumption, network transmission load, audit chain reconstruction, report jumps, and downstream linkages; For the first The weight of the impact category, with a value ranging from 0 to 1, is configured by the governance strategy; For the first Impact-like events in time slots The normalized cost is determined by the node resource status, task locking status, and synchronization window, and its value ranges from 0 to 1.

[0078] S34. Solving for the optimal switching time slot:

[0079] The optimal switchover time slot for the target node is:

[0080] ;

[0081] in, For the target node The optimal switching time slot; The set of candidate switching time slots is determined by the report lock-in period, mandatory compliance period, node availability synchronization window, and business operation cycle. equal ; equal ; and These are data bias weights and governance impact weights, respectively. Both are dimensionless weights, configured according to the application scenario of each node, and their values ​​range from 0 to 1. In this embodiment, and ;

[0082] S35, Switching Decision Commitment Generation:

[0083] Server-side generation of switching decision commitment The commitment fields include Synchronization strategy, node category, candidate time slot summary, dual-entropy parameter summary, and server signature summary; the commitment is the hash result of concatenating all fields, and the synchronization strategy includes residual synchronization, full synchronization, delayed synchronization, and bounce synchronization;

[0084] Residual synchronization only transmits the difference data between the old and new versions; full synchronization transmits the complete new version object; delayed synchronization is performed within a specified window after the optimal switching time slot; and bounce synchronization performs a version rollback operation when prediction fails.

[0085] S36. Rules for Synchronizing Patch Generation and Execution:

[0086] The server then generates a synchronization patch, which includes a patch identifier, operation type, preceding state summary, following state summary, execution condition, idempotent token, forward operation, reverse operation, and summary of affected objects.

[0087] The operation type includes five possible values: add, modify, delete, transition, and bounce; the pre-state summary is the hash result of the target node's local version state before patch execution; the post-state summary is the hash result of the target node's local version state after patch execution; the execution conditions are the time slot range and node state requirements for patch execution; the idempotent token is a unique identifier for the patch, randomly generated by the server; the forward operation describes the specific version update steps of the patch execution; the reverse operation describes the specific version recovery steps of the patch revocation; the affected object summary is the set of carbon factor version identifiers affected by the patch.

[0088] Before executing a patch, the target node must verify that the previous state summary is consistent with the local state. If they are consistent, the forward operation is executed and the subsequent state summary is recorded. If they are inconsistent, the execution is rejected and a bridging patch is requested. Idempotent tokens are used to prevent the same patch from being executed repeatedly, and reverse operations are used to restore the previous state when a new version is revoked, a prediction fails, or the accounting rules change.

[0089] Step S4: ZKP compliance verification circuit execution.

[0090] After completing the accounting, the target node generates a compliance certificate, which covers the authenticity of the version, the validity of the time, the legality of the transition state, the consistency of the switching strategy, and the correctness of the accounting calculation, but does not disclose the activity data, actual factor values, and accounting results.

[0091] S41. Numerical Fixed-Point Conversion:

[0092] The target node first converts the numerical input into fixed-point integers:

[0093] ;

[0094] in, For numerical values Fixed-point integers; This can be activity data, factor values, or calculation results; For accounting system The specified decimal precision is determined by the rule parameters, unit precision, and report rounding rules; This indicates rounding to the nearest integer; the circuit internally uses fixed-point integer arithmetic to avoid inconsistent verification results caused by floating-point calculations.

[0095] S42. Circuit Input Definition:

[0096] Public input includes version identifier Factor value commitment Accounting time slot Accounting system identification Rule Parameter Summary Transition curve commitment Switching decision commitments and valid version root summary ;

[0097] Private inputs include location-based activity data. Fixed-point factor value , Targeted accounting results Version metadata Member path Version status Switching strategy plaintext parameters Allowable error and optimal switching time slot ;

[0098] S43, Factor Value Commitment Generation:

[0099] Factor values ​​are committed to being generated according to the following formula:

[0100] ;

[0101] in, It is a collision-resistant hash function; Indicates field concatenation; The hash result of the fixed-point factor value; This provides a digest of version metadata; the hash function uses a hash algorithm that is easy to implement in circuits, such as the Poseidon hash algorithm.

[0102] S44, Core Boolean Signal Verification:

[0103] The ZKP circuit internally generates several Boolean intermediate signals, and the commitment consistency signal is used to verify the circuit's recalculation. Consistent with public inputs; member signals are used for verification. Able to Merged into The time-valid signal is used for verification. It falls within the valid time range recorded in the version metadata and meets the time granularity requirements in the rule parameters; the switching status signal is used for verification. and Constraint consistency; correctly calculated signals are used for verification. Depend on Based on the calculation rules, the circuit requires all of the above signals to be true;

[0104] For time comparison and range judgment, the circuit uses integer comparison constraints. Specifically, the difference to be compared is converted into a non-negative integer, and it is proven to be within the allowable range through bit decomposition. This process avoids the uncertainty caused by directly using size comparison in a finite field.

[0105] S45. Transition and Switching State Constraints:

[0106] For the time dilation compatibility region, the circuit is based on and Determine the allowable factor value Then, constraints:

[0107] ;

[0108] in, The localization factor value actually used by the target node; For accounting time slots and version status The following are the allowed fixed-point factor values; To allow for error, the accuracy is determined by the fixed-pointing precision, unit conversion precision, and report rounding rules; if If it is an old version state, the allowed value is the fixed-point value of the old version; if it is a transition state, it is calculated from the time dilation curve; if it is a new version state, it is the fixed-point value of the new version; if it is a bounce state, it is calculated from the curve parameters recorded in the bounce patch.

[0109] For handover strategy consistency, the circuit recalculates the handover decision commitment and verifies its consistency with the public input. Consistent, if Earlier The circuit allows for older or transitional states; if No earlier than The circuit only allows delayed synchronization states explicitly stated in the new version state or switching decision commitment; if the strategy is bounce synchronization, the circuit only allows the bounce state and enforces the bounce factor value constraint.

[0110] S46. Verification of calculation correctness:

[0111] To ensure the accuracy of the calculation, the circuit selects the calculation function according to the calculation system identifier:

[0112] ;

[0113] in, For fixed-point accounting results; For fixed-point activity data or activity data vectors ; For fixed-point factor values; For accounting system The corresponding fixed-point accounting function; This is a set of rule parameters, including unit conversion parameters, time granularity parameters, amortization parameters, rounding parameters, and allowable error parameters; in linear accounting scenarios, Performed according to fixed-point multiplication and scaling rules; in amortized or segmented scenarios. The corresponding calculation branch is selected by the selector signal, and bit constraints are used to ensure that only one branch is effective.

[0114] S47. Compliance Certificate Generation and Verification:

[0115] Proof of target node generation:

[0116] ;

[0117] in, Proof of ZKP compliance; For carbon factor version compliance verification circuit; For private input set; The set of public inputs; the verifier bases its work on the public inputs and... When the verification is successful, the verifier confirms that the carbon factor version used by the target node is valid, the time is legal, the switching strategy is consistent, and the accounting calculation is correct, but cannot obtain the activity data, actual factor value, and accounting result. ZKP proof is implemented through mainstream zero-knowledge proof protocols, such as the Groth16 protocol.

[0118] The target node sends the generated ZKP compliance certificate and the corresponding public input digest to the server.

[0119] Step S5: Trusted synchronization packet binding, bounce handling and reproduction.

[0120] The server binds version objects, curve commitments, switching commitments, synchronization patches, and ZKP proofs to form a traceable data link. When a prediction fails, the target node recovers smoothly through a bounce patch, avoiding a secondary jump.

[0121] S51. Generation of trusted synchronization packets:

[0122] After verifying the ZKP compliance certificate, the server will send the version object digest and transition curve commitment. Switching decision commitments Valid version root summary Synchronization patches, rollback patches, patch execution conditions, ZKP compliance certificates or their digests, and server signature digests are bound together to generate a trusted synchronization package. The trusted synchronization package is digitally signed by the server to ensure integrity and non-repudiation.

[0123] S52, Trusted Synchronization Packet Reception and Execution:

[0124] After receiving the trusted synchronization packet, the target node processes it in the following order: First, it verifies the integrity of the server signature and digest; second, it verifies whether the patch's pre-patch state is consistent with the local version state; third, it determines whether the current time slot meets the patch execution conditions. If the conditions are met, the patch is executed and written to the local version chain; if the conditions are not met, the patch is cached and re-evaluated in the candidate time slot. If the pre-patch state is inconsistent, the target node does not execute the patch and requests the server to return a bridging patch or a target state digest. The bridging patch is used to convert the local state from the current version to the patch's pre-patch state.

[0125] S53, Compliance Certificate Binding Storage:

[0126] After the target node completes the calculation, it will combine the ZKP compliance certificate with... , and When binding and saving, external verifiers only need to obtain the public input and proof, without needing to access the target node's activity details, real factor values, and calculation results.

[0127] S54. Handling Prediction Failure Bounce:

[0128] When the official new version is not released within the expected window, or the direction of change in the official new version is inconsistent with the predicted direction, or the actual change exceeds the predicted range, the server generates a rebound patch. The rebound patch includes a rebound start time slot, target version status, rebound curve parameters, summary of affected tasks, summary of reverse operation, and summary of rebound reason. The rebound curve adopts the same cubic smoothing function form as the transition curve, and the parameters are determined by the rebound magnitude and rebound period. When the target node executes the rebound patch, it gradually returns to the old version status or enters the re-prediction process along the rebound curve.

[0129] S55. Reproduction of historical accounting data:

[0130] For internal calculation results generated using the transition compatibility factor, the target node saves the bounce flag; for reports that have not yet been officially disclosed, the target node recalculates according to the version status after the bounce; for reports that have already been disclosed, the target node does not directly rewrite the history, but generates a review summary and saves the relevant version commitment, patch summary and proof summary for subsequent audit reproduction. The review summary includes the report identifier, bounce time, difference in factor values ​​before and after the bounce and an explanation of the impact.

[0131] Through the detailed description of the above embodiments, the carbon factor trusted version synchronization governance method of the present invention standardizes and trusts the entire carbon factor version management process, constructing a complete technical system from version object generation, change precursor prediction, differentiated switching decision to compliance verification and version recovery. Based on verifiable version objects and a valid version set, the present invention achieves a smooth transition of version changes through a time dilation compatibility zone driven by precursor signals, adapts to the accounting needs and resource status of different nodes through a dual-entropy normalized switching decision mechanism, ensures data privacy during the compliance verification process through zero-knowledge proof technology, and ensures the reliability of version synchronization and the traceability of historical data through trusted synchronization packages and a smooth rebound mechanism, providing a systematic solution for trusted synchronization governance of carbon factor versions.

[0132] The preset parameters in the above formulas shall be set by those skilled in the art according to the actual situation.

[0133] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0134] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0135] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

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

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

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

Claims

1. A method for managing the synchronization of trusted versions of carbon factors, characterized in that, The method flow is as follows: Step S1: The server converts carbon factor records into predictable, synchronizable, and verifiable version objects, generates factor value commitments for version objects that have passed the publisher's signature verification, constructs a verifiable and valid version set and saves the root digest of the set, and identifies carbon factor semantic objects based on version metadata and applicable domains. Step S2: The server actively collects and encodes multiple types of version change precursor signals at fixed intervals, matches the precursor signals with the applicable domain of the version object, calculates the version change probability, and generates a time dilation compatibility zone and corresponding transition curve commitment when the preset trigger conditions are met. Step S3: After the server verifies the official new version object, it combines the accounting sensitivity summary submitted by the target node to calculate the normalized value of the dual entropy of data deviation and governance impact, solves the optimal switching time slot of the target node, and generates the switching decision commitment and the corresponding synchronization patch of the differentiated synchronization strategy. Step S4: After the target node completes the accounting calculation, it executes the zero-knowledge proof compliance verification circuit to generate a compliance proof that does not disclose sensitive data. The proof content covers version authenticity, time validity, transition state legality, switching strategy consistency and accounting calculation correctness. Circuit constraints prevent the abuse of the transition compatibility area. Step S5: The server binds the version object, various commitments, synchronization patches, and compliance certificates to generate a digitally signed trusted synchronization package. The target node executes the trusted synchronization package. In case of prediction failure, the version is restored and historical accounting data is reproduced through a rebound patch with a smooth rebound curve.

2. The carbon factor trusted version synchronization governance method according to claim 1, characterized in that, In step S1, the server receives carbon factor data submitted by the carbon factor publisher and generates a version object for each carbon factor, which includes version identifier, factor value, applicable information, publisher summary, evidence summary, version status and version metadata. The server identifies two carbon factors with different public numbers but the same version metadata and applicable domain as different publication forms of the same semantic object, and identifies carbon factors with the same name but different applicable domains, units or accounting systems as different semantic objects.

3. The carbon factor trusted version synchronization governance method according to claim 2, characterized in that, In step S1, the server generates a version identifier by concatenating the publisher's public key hash with the time slot; the server writes the factor value commitment into the valid version set and generates a corresponding member path for each version commitment; the server and the target node pre-agree on the encoding method of the integer time slot so that subsequent curve calculation, time comparison and zero-knowledge proof circuit comparison are all completed in the integer field.

4. The carbon factor trusted version synchronization governance method according to claim 1, characterized in that, In step S2, the server collects early warning signals by connecting to public data sources, industry databases, and the pre-notification interface of the publishing end. Each early warning signal is encoded into a signal object containing a signal identifier, signal type, applicable domain, direction of change, magnitude of change, credibility, time effect, and evidence summary. The server matches the applicable domain of the early warning signal with the applicable domain of the version object according to the dimensions of region, industry, process, energy type, time granularity, and accounting system.

5. The carbon factor trusted version synchronization governance method according to claim 4, characterized in that, In step S2, the server calculates the version change risk increment based on the signal matching result, signal strength, signal credibility, and time effect value, and then calculates the version change probability based on the accumulated version change risk increment. The server performs weighted median processing on the signed change amplitude of the candidate signal to obtain the prediction correction ratio, generates a time dilation transition curve based on the prediction correction ratio, and generates a transition curve commitment containing transition curve parameters.

6. The carbon factor trusted version synchronization governance method according to claim 1, characterized in that, In step S3, after the server obtains the official new version object, it verifies the version identifier, applicable domain, applicable time, publisher summary, evidence summary, and accounting system identifier. If the new version is not released within the expected window, the direction of change is inconsistent with the predicted direction, or the actual change exceeds the predicted range, the server generates a rebound patch or re-executes the warning signal processing procedure.

7. The carbon factor trusted version synchronization governance method according to claim 6, characterized in that, In step S3, the server calculates the normalized value of data deviation and the normalized value of governance impact based on the accounting sensitivity summary submitted by the target node. The server then selects the optimal switching time slot from the set of candidate switching time slots determined by the report lock-in period, mandatory compliance period, node available synchronization window and business operation cycle, and finds the time slot that minimizes the weighted sum of data deviation and governance impact.

8. The carbon factor trusted version synchronization governance method according to claim 7, characterized in that, In step S3, the server generates a switching decision commitment that includes the optimal switching time slot and synchronization strategy; the server generates a synchronization patch that includes forward and reverse operations; before the target node executes the patch, it verifies that the prior state summary is consistent with the local state; idempotent tokens are used to prevent the same patch from being executed repeatedly; and reverse operations are used to restore the version.

9. The carbon factor trusted version synchronization governance method according to claim 1, characterized in that, In step S4, the target node first converts the activity data, factor values, and accounting results into fixed-point integers, and then executes the zero-knowledge proof compliance verification circuit. The circuit generates multiple Boolean intermediate signals to verify the consistency of factor value commitments, member affiliation, time validity, switching state consistency, and accounting calculation correctness, respectively.

10. The carbon factor trusted version synchronization governance method according to claim 9, characterized in that, In step S4, the zero-knowledge proof compliance verification circuit determines the allowable factor value range based on the accounting time slot, version status, transition curve commitment, and switching decision commitment, and constrains the factor values ​​actually used by the target node to be within the allowable error range; the circuit selects the corresponding fixed-point accounting function based on the accounting system identifier to verify the correctness of the accounting results.

Images