A green electricity transaction trusted settlement verification method

Abstract

This invention relates to the field of power trading and settlement technology, specifically to a reliable settlement verification method for green electricity trading. The method first acquires and standardizes multi-source data to form a transaction verification unit, which is then divided into a common energy field and a green attribute field. A true settlement track and a counterfactual settlement track are set up, and the same settlement function is used for dual-track lockstep settlement. The green electricity attribute contribution vector is extracted, and then a reliable settlement judgment value is generated by combining metering, consumption, and voucher boundaries. When the verification fails, the minimum conflict constraint set is extracted and a minimum conflict evidence package is generated. Finally, the result summary is written onto the blockchain.

Description

Technical Field

[0001] This invention relates to the field of power trading and settlement technology, and more specifically, to a reliable settlement verification method for green electricity trading. Background Technology

[0002] Verification of green electricity transaction settlement is an important component of the green energy trading system in the electricity market, and it is directly related to the fairness, transparency, and effective circulation of green electricity transactions.

[0003] Current green electricity transaction settlement verification typically combines ordinary electricity settlement with green attribute settlement, making it difficult to accurately separate the independent contribution of green attributes to the settlement results. This results in poor attributability of verification results and fails to effectively verify the consistency between green attribute payments and actual consumption and certificate status. Furthermore, when verification fails, existing technologies often require the disclosure of full business data to pinpoint the problem. This not only poses the risk of leakage of commercial data of trading entities and user privacy, but also makes it difficult to quickly locate the core conflict points that led to the verification failure. This increases the time cost and complexity of dispute resolution and is also detrimental to regulatory agencies conducting efficient audits.

[0004] Therefore, this invention proposes a reliable settlement verification method for green electricity transactions. Summary of the Invention

[0005] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a reliable settlement and verification method for green electricity transactions.

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

[0007] A trusted settlement verification method for green electricity transactions includes the following steps:

[0008] Step S1: Obtain green electricity transaction, metering, settlement, green attribute certificate and consumption certificate data as data to be verified, standardize them according to the same verification rule version and merge them into transaction verification units, and generate on-chain input summary, rule version and field summary path;

[0009] Step S2: According to the verification rule version, the transaction verification unit is divided into a normal energy field and a green attribute field. The real settlement track input and the counterfactual settlement track input are set. The real settlement track retains the normal energy field and the green attribute field, while the counterfactual settlement track keeps the normal energy field valid and performs a masking mapping on the green attribute field.

[0010] Step S3: Use the same settlement function to perform dual-track lockstep settlement on the real settlement track input and the counterfactual settlement track input. When the ordinary electrical energy output is consistent, extract the green attribute output difference in the two settlement tracks to obtain the green electrical attribute contribution vector.

[0011] Step S4: Generate a reliable settlement judgment value based on the consistency relationship between the green electricity attribute contribution vector and the metering boundary, consumption boundary, voucher boundary and settlement price;

[0012] Step S5: When the trusted settlement judgment value is not passed, generate a set of failure constraints based on the failed branch, extract the minimum conflict constraint set and generate a minimum conflict evidence package;

[0013] Step S6: Output the trusted settlement pass result or trusted settlement fail result, and write the corresponding digest onto the chain.

[0014] Furthermore, in step S1, the data to be verified includes the transaction contract number, transaction entity identifier, power generation project identifier, metering point identifier, settlement cycle, transaction electricity volume, power generation side metered electricity volume, power consumption side metered electricity volume, settlement electricity volume, settlement price, green attribute unit price, settlement voucher number, settlement voucher amount, green attribute voucher number, voucher corresponding electricity volume, voucher holder account, voucher lock status, voucher transfer status, voucher cancellation status, consumption entity identifier, consumption scenario identifier, consumption cycle, consumption certificate electricity volume, data source signature, and timestamp; the standardization includes unified field names, unified measurement units, unified time format, unified entity identifier format, unified signature format, and unified numerical precision.

[0015] Furthermore, when forming the transaction verification unit, the data is merged and standardized according to the same transaction contract, the same settlement cycle, the same transaction entity relationship, and the same verification rule version; when the same transaction contract corresponds to multiple green attribute voucher numbers in the same settlement cycle, the multiple green attribute voucher numbers are treated as a set of voucher status fields in the same transaction verification unit, and the contract boundary of the transaction verification unit remains unchanged.

[0016] Furthermore, the on-chain input digest is generated based on the standardized coded transaction identifier field, subject identifier set, electricity metering field set, settlement certificate field set, consumption certificate field set, green attribute certificate status field set, and verification rule version; the on-chain input digest, verification rule version, field digest path, and data source signature are written on-chain, while the original contract text, complete load curve, and complete settlement bill are kept off-chain.

[0017] Furthermore, in step S2, the ordinary electricity field includes the trading entity, settlement cycle, metered electricity volume on the generation side, metered electricity volume on the consumption side, ordinary electricity price, basic settlement amount, deviation handling rules, metering data quality identifier, and basic settlement voucher; the green attribute field includes green attribute voucher number, voucher status, green attribute unit price, green attribute price, green consumption declaration, consumption certificate, green electricity priority clearing mark, voucher lock status, voucher transfer status, and voucher cancellation status; when a field affects both ordinary electricity settlement and green attribute settlement, the field is split into ordinary electricity subfield and green attribute subfield, and field summary paths are set for each.

[0018] Furthermore, when setting up the real settlement track input and the counterfactual settlement track input, activation bits are set for the fields in the transaction verification unit. In the real settlement track input, the activation bits of the ordinary electricity field and the green attribute field are both in a valid state. In the counterfactual settlement track input, the activation bit of the ordinary electricity field is in a valid state, and the activation bit of the green attribute field is in a masked state. When performing masking mapping on the green attribute field in the masked state, the voucher status field is mapped to a state that cannot participate in green electricity settlement, the green attribute price field is mapped to a state that is not included, the green consumption declaration field is mapped to a state of empty declaration, the voucher occupancy status is mapped to a state of unoccupied, and the consumption certificate field is retained in the summary structure but does not participate in the calculation of the declarable consumption amount of the counterfactual settlement track.

[0019] Furthermore, in step S3, the dual-track lock-step settlement adopts the same field sorting, the same metering data retrieval method, the same ordinary energy settlement rules, the same deviation handling rules, the same rounding rules, the same status update time, and the same numerical precision; the ordinary energy output includes ordinary energy settlement amount, ordinary energy price, deviation settlement result, basic settlement voucher status, and basic payment status; when the ordinary energy output in the true settlement track output is inconsistent with the ordinary energy output in the counterfactual settlement track output, the corresponding transaction verification unit is marked as a counterfactual track generation anomaly, and the differential verification of the transaction verification unit is stopped.

[0020] Furthermore, the green electricity attribute contribution vector is obtained by subtracting the green attribute output from the counterfactual settlement track output from the green attribute output in the actual settlement track output. The green electricity attribute contribution vector includes the settlement electricity volume increment, price increment, declarable consumption volume increment, and voucher occupancy status difference brought about by the green attribute. When the price increment is zero but the actual settlement track outputs declarable consumption volume, it is marked as an abnormal declaration source. When the price increment is not zero but the voucher occupancy status difference indicates that the voucher is not effectively occupied, it is marked as a price voucher abnormal. When the declarable consumption volume increment is greater than the settlement electricity volume increment, it is marked as a consumption declaration excess abnormality.

[0021] Furthermore, in step S4, the metering boundary is determined by the metered electricity volume on the generation side, the metered electricity volume on the consumption side, the traded electricity volume, the settlement cycle, and the quality of the metering data; the consumption boundary is determined by the actual consumption volume that the consumption entity can support with consumption proof within the same settlement cycle and the same consumption scenario; the voucher boundary is obtained by summing up the valid green attribute voucher electricity volume that can be used in the current transaction verification unit; when generating a reliable settlement judgment value, it is determined whether the settlement electricity volume increment brought by the green attribute simultaneously satisfies the metering boundary, the consumption boundary, and the voucher boundary, whether the price increment brought by the green attribute corresponds to the green attribute unit price and the settlement electricity volume increment, and whether the current voucher status belongs to the voucher status set allowed to participate in this settlement verification under the verification rule version.

[0022] Furthermore, in step S5, the set of failed constraints includes measurement boundary constraints, consumption boundary constraints, voucher boundary constraints, green attribute price constraints, subject and cycle binding constraints, and on-chain digest consistency constraints. A constraint dependency relationship consisting of constraint nodes and field nodes is established for the set of failed constraints, and a stable sort is formed according to constraint type, field source, verification rule version, and timestamp. Candidate constraints are removed sequentially, and satisfiability judgment is re-executed. Constraints that make the remaining constraints satisfiable after removal are retained, resulting in a minimum conflict constraint set. A minimum conflict evidence package is generated based on the dependency fields of each constraint in the minimum conflict constraint set. The minimum conflict evidence package includes conflict header information, necessary plaintext fields, digest proof fields, signature proof fields, and verification rule identifiers. When there is a need to correct settlement vouchers, update voucher status, or resubmit consumption proofs, the verification process is re-executed based on the new input digest. The original verification record is not overwritten, and the new verification record is stored in association with the original verification record according to the transaction verification unit identifier, verification rule version, and timestamp.

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

[0024] 1. To address the problem that existing technologies struggle to accurately separate the settlement contribution of green attributes, this invention employs a dual-track lockstep settlement technique. This technique divides the fields of the transaction verification unit into ordinary energy fields and green attribute fields. By controlling the activation bit, it generates a true settlement track input that retains all fields and a counterfactual settlement track input that masks the green attribute fields. The same settlement function is used to execute dual-track settlement under identical parameter conditions. After verifying the invariance of ordinary energy, the green energy attribute contribution vector is extracted. This accurately quantifies the incremental impact of green attributes on settlement electricity volume, price, and consumption, thus improving the accuracy and verifiability of green energy settlement verification results.

[0025] 2. To address the issues of excessive data exposure and low conflict localization efficiency when existing technologies fail verification, this invention generates a set of failure constraints containing multiple types of constraints based on the failure branch when the trusted settlement judgment fails. It establishes the dependency relationship between constraints and fields and extracts the minimum conflict constraint set, thereby generating a minimum conflict evidence package containing only the necessary proof fields. This can quickly locate the core reason for the verification failure while minimizing the scope of data disclosure and protecting data privacy, which helps to improve the efficiency and transparency of green electricity transaction dispute handling. Attached Figure Description

[0026] Figure 1 A flowchart of a trusted settlement verification method for green electricity transactions;

[0027] Figure 2 This is a flowchart illustrating the steps for generating the true settlement track input and the counterfactual settlement track input in this invention;

[0028] Figure 3 This is a flowchart illustrating the steps involved in performing dual-track lockstep settlement and calculating the contribution of green electricity attributes in this invention. Detailed Implementation

[0029] Example, refer to Figure 1 The green electricity transaction trusted settlement verification method of this embodiment specifically includes the following steps:

[0030] Step S1: Generate a transaction verification unit and solidify the on-chain input summary.

[0031] The electricity volume, settlement vouchers, and consumption certificates of green electricity transactions are organized into a single data object, so that the subsequent counterfactual settlement differential verification has a unified input boundary. The input summary, rule version, and field summary path are fixed on the chain, while the original business data is retained off the chain.

[0032] S11. Collect and standardize transaction verification data:

[0033] The verification system obtains the data to be verified from the green electricity trading platform, the electricity metering system, the settlement system, the green attribute certificate management system, and the energy consumption side consumption certificate system. The data to be verified includes the transaction contract number, transaction entity identifier, power generation project identifier, metering point identifier, settlement cycle, transaction volume, power generation side metered volume, power consumption side metered volume, settlement volume, settlement price, green attribute unit price, settlement certificate number, settlement certificate amount, certificate number, corresponding volume of the certificate, certificate holder account, certificate lock status, certificate transfer status, certificate cancellation status, consumption entity identifier, consumption scenario identifier, consumption cycle, consumption certificate volume, data source signature, and timestamp.

[0034] The data is standardized and coded according to a preset field order, which is as follows: transaction identifier, entity identifier, electricity metering, settlement voucher, green attribute voucher, consumption certificate, and signature timestamp. Standardized coding includes uniform field names, units of measurement, time formats, entity identifier formats, signature formats, and numerical precision. Field names uniformly adopt standard terminology for the power industry; units of measurement uniformly adopt the International System of Units (SI); time formats uniformly adopt UTC time formats; entity identifier formats uniformly adopt the Unified Social Credit Code or the Unified Entity Code for the power industry; signature formats uniformly adopt elliptic curve digital signature formats; and numerical precision is uniformly retained to the decimal places specified in the settlement rules. Specifically, electricity is uniformly represented by the same unit of electrical energy, price is uniformly represented by the same currency unit, and time is uniformly represented by the time granularity specified in the settlement rules. If the data units from different source systems are different, they are first converted according to the conversion relationships in the power transaction settlement rules before proceeding to the subsequent verification process.

[0035] S12. Forming a transaction verification unit:

[0036] According to the same transaction contract, the same settlement cycle, the same transaction entity relationship, and the same verification rule version, the standardized data are grouped into transaction verification units; one transaction verification unit corresponds to a set of green electricity transaction records, settlement voucher records, green attribute voucher status records, and consumption certificate records that can be processed by the same rule version;

[0037] For time-of-use green electricity transactions, transaction verification units can be generated according to hourly, fifteen-minute, or other time granularities specified in the transaction rules; for monthly green electricity transactions, transaction verification units can be generated according to the monthly settlement cycle. If the same transaction contract corresponds to multiple voucher numbers within the same settlement cycle, the multiple voucher numbers will be treated as a set of voucher status fields in the same transaction verification unit, without changing the contract boundaries of the transaction verification unit.

[0038] S13. Generate on-chain input digest:

[0039] For the first Each transaction verification unit generates an on-chain input summary:

[0040] ;

[0041] in, Indicates the first On-chain input summary for each transaction verification unit; This indicates a collision-resistant hash algorithm, which can use the SM3 hash algorithm issued by the State Cryptography Administration or the internationally used SHA-256 hash algorithm. Before hash calculation, all normalized encoded fields are converted into UTF-8 format byte streams, and then concatenation and hash operation are performed. Represents a normalized coding function; Indicates field concatenation; This indicates the transaction contract number, transaction order number, or transaction matching record number; A set of identifiers representing trading entities, settlement entities, certificate holders, and consumption entities; A set of fields representing the transaction volume, the generation-side metered volume, the consumption-side metered volume, and the settlement volume; A set of fields representing settlement voucher number, settlement amount, settlement electricity volume, payment status, and settlement institution signature; A set of fields representing the power consumption certificate number, power consumption entity, power consumption scenario, power consumption period, and power consumption certificate amount; A set of fields representing the green attribute voucher number, the corresponding electricity consumption of the voucher, the voucher holder's account, the lock status, the transfer status, and the cancellation status; This indicates the version of the verification rules applicable to this transaction verification unit;

[0042] The rules governing green electricity transactions, settlement, document verification, and agreements between the parties in effect at the time of the transaction shall be determined. , Field summary paths and data source signatures are written on the blockchain, while the original contract text, complete load curves, and complete settlement invoices are not directly written to the blockchain.

[0043] Step S2: Generate the true settlement track input and the counterfactual settlement track input.

[0044] like Figure 2 As shown, the participation of green attributes in the settlement is controlled by field hierarchy and activation bits. The true settlement track retains green attributes, while the counterfactual settlement track masks green attributes. However, both use the same raw input, the same rule version, and the same ordinary electrical energy field.

[0045] S21. Divide the ordinary electrical energy field and the green attribute field:

[0046] According to the rule version The fields in the transaction verification unit are divided into ordinary electricity fields and green attribute fields. The ordinary electricity fields include the transaction entity, settlement cycle, metered electricity volume on the generation side, metered electricity volume on the consumption side, ordinary electricity price, basic settlement amount, deviation handling rules, metering data quality identifier, and basic settlement voucher. The green attribute fields include green attribute voucher number, voucher status, green attribute unit price, green attribute price, green consumption declaration, consumption certificate, green electricity priority clearing mark, voucher lock status, voucher transfer status, and voucher cancellation status.

[0047] Field hierarchical results vary with rule version All fields should be fixed together. Changing the field type during the verification process is not allowed. If a field affects both ordinary energy settlement and green attribute settlement, it should be split into ordinary energy subfields and green attribute subfields, and field summary paths should be set for each, so that counterfactual processing only applies to the green attribute subfields.

[0048] S22. Set the green attribute activation position:

[0049] Activation bits are set for fields in the transaction verification unit. In the real settlement track, both the ordinary energy field and the green attribute field are in a valid state. In the counterfactual settlement track, the ordinary energy field remains valid, while the green attribute field is put into a masked state. The processing procedure is as follows:

[0050] ;

[0051] in, Indicates the first A normalized input field vector for each transaction verification unit; This indicates the field activation handling function. The logic is as follows: when the activation bit of the corresponding field is 1, it returns the original normalized value of the field; when the activation bit is 0, numeric fields return 0, status fields return a preset invalid status code, and string fields return an empty string. The invalid status codes for different field types are determined by the rule version. Unified regulations; Represents the actual settlement track input vector; Represents the input vector of the counterfactual settlement track; Represents the actual settlement track activation bit vector; This represents the counterfactual settlement track activation bit vector; when the activation bit is 1, it indicates that the corresponding field participates in the settlement calculation; when the activation bit is 0, it indicates that the corresponding field does not participate in the settlement calculation.

[0052] exist In the text, the activation bits for both the ordinary electrical energy field and the green attribute field are 1; In the code, the activation bit for the ordinary electrical energy field is 1, and the activation bit for the green attribute field is 0; field activation processing function. The original fields are not deleted; the field values ​​corresponding to the active state are only returned when the settlement function reads the fields.

[0053] S23. Perform green attribute masking mapping:

[0054] For green attribute fields with an activation bit of 0 in the counterfactual settlement track, according to the rule version A masking mapping is performed; the voucher status field is mapped to a status where it cannot participate in green electricity settlement, and its encoded value is determined by the rule version. The rules stipulate that the encoded values ​​differ from those for the valid participation status; the green attribute price field is mapped to an "not included" status, corresponding to a value of 0; the green consumption declaration field is mapped to an empty declaration status, corresponding to an empty string; and the voucher occupancy status is mapped to an "unoccupied" status, with its encoded value determined by the rule version. The regulations stipulate that, unlike the coded value of the occupied state, the consumption proof field is retained in the digest structure but does not participate in the calculation of the declarable consumption amount in the counterfactual settlement track;

[0055] Masking mapping does not change the on-chain input digest The corresponding original fields, the true settlement track, and the counterfactual settlement track can all be traced back to the same input summary via the field summary path. This proves that the two have the same origin.

[0056] Step S3: Perform dual-track lockstep settlement and calculate the contribution of green electricity attributes.

[0057] like Figure 3 As shown, the real settlement track and the counterfactual settlement track are executed separately under the same settlement function. Then, the differential result is guaranteed to come only from the green attribute field by the ordinary energy invariance check. The verification object is transformed from the surface result of the settlement voucher to the incremental impact brought by the green attribute.

[0058] S31. Perform dual-track lockstep settlement:

[0059] The same settlement function is used to process the input of the real settlement track and the counterfactual settlement track respectively. The two tracks use the same field sorting, the same metering data acquisition method, the same ordinary electric energy settlement rules, the same deviation handling rules, the same rounding rules, the same status update time and the same numerical precision.

[0060] The dual-track settlement process is as follows:

[0061] ;

[0062] in, Indicates the rule version The corresponding settlement function has two basic logics: ordinary energy settlement and green attribute settlement. Ordinary energy settlement calculates the price of ordinary energy based on the metered electricity, ordinary energy price and deviation handling rules in the ordinary energy field. Green attribute settlement calculates the price of green attribute based on the green attribute unit price and green attribute contribution electricity in the green attribute field. The rounding rules adopt the method specified in the settlement rules, which may include rounding to the nearest whole number, rounding up or rounding down. This represents the actual settlement track output vector; This represents the output vector of the counterfactual settlement track; Represents the actual settlement track input vector; Represents the input vector of the counterfactual settlement track;

[0063] The output vector of the true settlement track should include at least the settlement amount of ordinary electricity, the price of ordinary electricity, the amount of electricity contributed by green attributes, the price of green attributes, the amount of consumption that can be declared, the status of voucher occupancy, the status of voucher cancellation, and the status of settlement voucher binding; the output vector of the counterfactual settlement track should include at least the settlement amount of ordinary electricity, the price of ordinary electricity, the settlement amount after masking green attributes, the status of the price after masking green attributes, the status of empty consumption declaration, and the status of unoccupied vouchers.

[0064] S32. Perform a standard electrical energy invariance check:

[0065] Extract ordinary electrical energy output from the true settlement track output and the counterfactual settlement track output. Ordinary electrical energy output includes ordinary electrical energy settlement amount, ordinary electrical energy price, deviation settlement result, basic settlement voucher status and basic payment status.

[0066] The verification of the invariance of ordinary electrical energy is as follows:

[0067] ;

[0068] in, This represents the ordinary electrical energy output extraction function, according to the rule version. The specified output vector field index is used to extract field values ​​related to ordinary electricity settlement from the settlement track output vector to form the ordinary electricity output vector; This represents the actual settlement track output vector; This represents the output vector of the counterfactual settlement track. (Function) The extracted fields are determined by the rule version. Identify and extract only the fields relevant to standard electricity billing;

[0069] If the verification fails, it means that the green attribute masking affects the settlement of ordinary electricity energy. The transaction verification unit is marked as an anomaly in the generation of the counterfactual track, and the differential verification of the transaction verification unit is stopped. If the verification succeeds, it means that the real settlement track and the counterfactual settlement track are consistent at the level of ordinary electricity energy, and the subsequent differential results can be attributed to the participation status of the green attribute field.

[0070] S33. Calculate the contribution vector of green electricity attributes:

[0071] After the ordinary electrical energy invariance check is passed, the green attribute output is extracted from the two settlement tracks, and the green electrical attribute contribution vector is calculated:

[0072] ;

[0073] in, Indicates the first Green electricity attribute contribution vector of each transaction verification unit; This indicates the function for extracting the green attribute output, based on the rule version. The specified output vector field index is used to extract field values ​​related to green attribute settlement from the settlement track output vector to form a green attribute output vector. This indicates the increase in settlement electricity volume resulting from the green attribute; This indicates the price increase resulting from the green attribute; This indicates the increase in declarable absorbability resulting from the green attribute; The green attribute represents the difference in voucher occupancy status. All of the above components are obtained by subtracting the counterfactual settlement track output from the true settlement track output.

[0074] Its dimension is electrical energy. The unit of measurement is monetary. Its dimension is electrical energy. The state difference value is given by the following formula: in, The document occupancy status code for the actual settlement track; The document occupancy status code is used for the counterfactual settlement track; a valid occupancy status code is 1, and an unoccupancy status code is 0.

[0075] when When the actual settlement track output is zero but the declared consumption is zero, it is marked as an abnormal declaration source. Not zero but When a voucher is not being used effectively, it is marked as an abnormal payment voucher. Greater than When this occurs, it is marked as an abnormality due to excessive consumption declaration.

[0076] Step S4: Determine the reliability of the settlement based on the difference results.

[0077] The green electricity attribute contribution vector is consistent with the metering boundary, consumption boundary, voucher boundary, and settlement price. Only when the increment generated by the green attribute is supported by the electricity volume, voucher, and consumption certificate will a credible verification result be output.

[0078] S41. Determine three types of boundary quantities:

[0079] Determine the measurement boundary , absorption boundary and voucher boundaries ;

[0080] Measurement boundary The amount of electricity measured on the generation side, the amount of electricity measured on the consumption side, the amount of electricity traded, the settlement cycle, and the quality of the metering data are determined by the following formula:

[0081] ;

[0082] in, For the electricity metering aggregation function, the aggregation rules and data retrieval priorities are determined by the rule version. It is confirmed that compliant integration of multiple sets of measurement data can be achieved through preset aggregation logic; This refers to all valid metered electricity data under the same transaction verification unit; if there are multiple metering records within the same transaction verification unit, the rules shall apply. The data is generated according to the specified data retrieval order or aggregation method. The data collection order can be arranged from highest to lowest quality, with priority given to higher quality data; the aggregation method can be summation, averaging, or maximum value, depending on the rule version. Regulation;

[0083] Disposal Boundary The amount of electricity consumed is determined by the actual electricity consumption supported by consumption certificates within the same settlement period and the same consumption scenario. The calculation formula is as follows:

[0084] ;

[0085] in, For the current transaction verification unit, the electricity consumption corresponding to the kth valid consumption certificate in the current scenario is defined. This represents the total number of valid consumption certificates under the bound scenario; if the consumption certificate involves multiple scenarios, only the electricity consumption of the scenario bound to the current transaction verification unit will be counted. When the same consumer entity has multiple consumption certificates under the same settlement period and consumption scenario, the consumption boundary is obtained by summing the electricity amounts of all valid consumption certificates. ;

[0086] voucher boundaries The calculation formula is as follows: The total amount of valid green attribute certificates available for the current transaction verification unit is calculated as follows:

[0087] ;

[0088] in, The approved electricity amount corresponding to the kth valid green attribute certificate; This represents the total number of valid vouchers under the current transaction verification unit; vouchers that have been frozen, locked by other settlement statements, or cancelled and cannot be used for the current declaration are not included. The certificate boundary is obtained by summing the corresponding electricity amounts of all eligible green attribute certificates. ;

[0089] S42. Perform trusted settlement determination:

[0090] The reliable settlement judgment value is determined according to the following formula:

[0091] ;

[0092] in, Indicates the first The credible settlement judgment value of each transaction verification unit; This indicates an indicator function that evaluates all conditions within the parentheses sequentially. If any condition is false, it immediately returns 0; if all conditions are true, it returns 1. The order in which the conditions are evaluated is determined by the rule version. Regulation; This indicates the increase in settlement electricity volume resulting from the green attribute; This indicates the price increase resulting from the green attribute; Indicates the measurement boundary; Indicates the absorption boundary; Indicate the boundaries of the voucher; This indicates the unit price for green attributes, and its unit is monetary units per unit of electrical energy. Indicates the current status of the voucher; Indicates the rule version The following is a set of voucher statuses that are allowed to participate in this settlement verification;

[0093] like If the transaction verification unit confirms that it has passed the trusted settlement verification, Enter the minimum conflict evidence verification process;

[0094] S43. Solidify trusted reconciliation results:

[0095] when At that time, a trusted settlement record is generated, which includes an input summary. The following data are generated: a summary of the true settlement track, a summary of the counterfactual settlement track, a result of the ordinary energy invariance verification, a summary of the green energy attribute contribution vector, a trusted settlement judgment value, a rule version, a voucher status index, and a consumption proof index; the above summaries are written on the chain, and the status of the transaction verification unit is updated to trusted reconciliation;

[0096] when At that time, only the transaction verification unit identifier, input summary, failure time, rule version, failure status, and the summary of the minimum conflict evidence package generated subsequently are recorded on the chain. The complete contract, complete load curve, or complete settlement bill is not disclosed.

[0097] Step S5: Extract the least conflicting evidence package:

[0098] When verification fails, the reason for failure is transformed into a constraint unsatisfaction problem, and the smallest contradictory subset that caused the failure is extracted. Only the fields required to prove the validity of the contradictory subset are disclosed to avoid exposing the full amount of data.

[0099] S51. Generate a set of failed constraints:

[0100] for The transaction verification unit generates a set of failure constraints. ,gather Includes constraints related to the currently failed branch, but excludes all business rules unrelated to the failure;

[0101] Failure constraints include measurement boundary constraints, consumption boundary constraints, voucher boundary constraints, green attribute payment constraints, subject and cycle binding constraints, and on-chain digest consistency constraints;

[0102] Measurement boundary constraint judgment Whether the maximum amount of green electricity that the metering data can support is exceeded depends on fields including transaction period, metering point identifier, metered electricity, metering data source signature, and metering summary path.

[0103] Elimination boundary constraint judgment Whether it exceeds the actual consumption volume that the consumption entity can prove within the same cycle depends on the following fields: consumption entity, consumption scenario, consumption cycle, consumption proof electricity volume, consumption proof signature, and consumption proof digest path.

[0104] Document boundary constraint judgment Whether the amount of electricity exceeds the capacity supported by the valid credentials depends on fields including credential number, corresponding electricity amount, holder account, lock status, transfer status, cancellation status, and credential status summary path.

[0105] Green attribute pricing constraint judgment Is it equal to the unit price of the green attribute? and differential charge The product of these parameters depends on fields including the green attribute unit price, differential electricity consumption, settlement amount, settlement voucher number, and settlement voucher summary path.

[0106] The binding constraint between the subject and the cycle determines whether the transaction contract subject, settlement document subject, document holder and consumer subject meet the rule version. The specified binding or authorization relationship depends on fields including subject identifier, contract number, voucher account, consumer subject, authorization relationship field, and settlement period;

[0107] On-chain digest consistency constraints determine whether the disclosed fields can be traced back to the on-chain input digest. Its dependent fields include field-level digest path, field encoding method, on-chain input digest, and data source signature;

[0108] S52. Generate constraint dependencies:

[0109] For the set of failure constraints Generate constraint dependencies. Constraint dependencies consist of constraint nodes and field nodes; if a field is necessary data to validate a constraint, then the constraint is dependent on that field.

[0110] For any constraint Its dependent field set is denoted as ,gather By rule version The constraint type is determined together and cannot be manually expanded after a verification failure;

[0111] For example, the dependency fields for the consumption boundary constraint only include the consumption subject, consumption scenario, consumption cycle, consumption certificate electricity volume, consumption certificate signature, and corresponding digest path, excluding the complete electricity consumption curve. The dependency fields for the green attribute price constraint only include the green attribute unit price, differential electricity volume, and the corresponding price field in the settlement voucher, excluding the details of ordinary electricity price. The dependency fields for the voucher boundary constraint only include the voucher number, voucher status, voucher-corresponding electricity volume, status update time, and status digest path, excluding all historical transaction records of the voucher.

[0112] S53. Extract the minimum set of conflicting constraints:

[0113] From the set of failure constraints Extract the minimum set of conflict constraints The minimum set of conflicting constraints cannot be satisfied simultaneously, but after removing any one of the constraints, the remaining constraints can be satisfied simultaneously.

[0114] ;

[0115] in, Indicates the first The minimum set of conflict constraints for each transaction verification unit; This represents the set of failure constraints for the transaction verification unit; Represents a subset of candidate constraints; Indicates the number of constraints in the candidate constraint subset; The constraint satisfiability judgment function is calculated using the following formula:

[0116] , Represents any constraint in the subset of candidate constraints; This indicates the removal of constraints from the subset of candidate constraints. The remaining set of constraints;

[0117] This embodiment uses a deterministic reduction process for extraction. First, according to The corresponding failed branch determines the candidate constraint set. Next, a stable sort is formed according to constraint type, field source, rule version, and timestamp. The priority of constraint type, from highest to lowest, is: on-chain digest consistency constraint, subject-cycle binding constraint, state constraint, and numerical boundary constraint. The priority of field source, from highest to lowest, is: on-chain data, metering system data, settlement system data, voucher management system data, and consumption proof system data. The stable sort is first sorted by constraint type priority, then by field source priority, and finally by rule version and timestamp. Next, one constraint is temporarily removed sequentially, and the satisfiability judgment is re-executed. If the candidate set is still unsatisfiable after removal, it means the removed constraint is not a necessary constraint for proving the conflict and is deleted. If the candidate set becomes satisfiable after removal, it means the removed constraint is a necessary condition for the conflict and is retained. This process is repeated until the removal of any retained constraint leads to the disappearance of the conflict.

[0118] Satisfaction assessment is performed according to constraint type; for numerical boundary constraints, metered electricity, consumed electricity, voucher-based electricity, and differential electricity are converted to the same unit of measurement and handled according to the rule version. The numerical precision is compared; for state constraints, it is determined whether the voucher status belongs to the set of allowed states. Regarding entity binding constraints, determine whether there are rule versions among the transaction entity, certificate holder, settlement entity, and consumer entity. Recognized binding or authorization relationships; for digest consistency constraints, verify whether the normalized encoding results of the disclosed fields can be traced back to the on-chain input digest along the field-level digest path. ;

[0119] S54. Generate a minimum conflict evidence package:

[0120] Based on the minimum set of conflict constraints Generate a minimum conflict evidence package Candidate evidence fields come from The set of dependent fields for each constraint is selected, without taking irrelevant fields;

[0121] ;

[0122] in, Indicates the first The minimum conflict evidence package for each transaction verification unit; Represents the set of candidate evidence fields; Represents any field in the candidate evidence field set; Representation field The disclosure weight ranges from 1 to 10 and can be assigned by combining the field sensitivity level and the necessity of re-verification. The higher the sensitivity level and the lower the necessity of re-verification, the higher the disclosure weight. The evidence package verification function is calculated using the following formula: The disclosure weight of complete contract text, complete load curve and complete settlement statement can be set to the highest level, while the disclosure weight of status value, summary path and signature field can be set to the lowest level.

[0123] A greedy algorithm is used to select the set of fields that can prove the minimum conflict constraint set is unsatisfactory and has the minimum total disclosure weight. The minimum conflict evidence package includes conflict header information, necessary plaintext fields, digest proof fields, signature proof fields, and verification rule identifiers. Conflict header information includes transaction verification unit identifier, rule version, failure time, minimum conflict constraint number, and differential verification result digest. Necessary plaintext fields include the minimum field value that must be disclosed to prove the conflict. Digest proof fields include field-level digest path, input digest, settlement document digest path, acceptance certificate digest path, and document status digest path. Signature proof fields include signature of the metering data source, signature of the settlement institution, signature of the document status provider, signature of the acceptance certificate issuer, and timestamp. Verification rule identifiers include rule version number, numerical precision rule, field encoding rule, and status set identifier;

[0124] When a conflict arises from the differential electricity exceeding the consumption boundary, the evidence package discloses the differential electricity, the consumption proof electricity, the consumption entity, the consumption cycle, and the corresponding summary path, but does not disclose the complete electricity consumption curve. When a conflict arises from an invalid voucher status, the evidence package discloses the voucher number, voucher status, status update time, and status summary path, but does not disclose the entire voucher transaction history. When a conflict arises from a mismatch in green attribute pricing, the evidence package discloses the green attribute unit price, the differential electricity, and the corresponding pricing field in the settlement voucher, but does not disclose the details of ordinary electricity pricing.

[0125] Step S6: Output the verification results and support re-verification and updates.

[0126] The trusted pass result or the result with the least conflict evidence will be output to the transaction entity, settlement institution, energy user and regulatory node. When there is data correction in the future, a new verification record will be generated without overwriting the original on-chain record.

[0127] S61. Output reliable pass result:

[0128] when Upon completion, a trusted settlement result is output. This result includes the transaction verification unit identifier, trusted settlement electricity volume, green attribute price, declarable consumption volume, voucher occupancy status, settlement voucher summary, consumption proof summary, rule version, and on-chain status index. Transaction entities can use this to complete trusted reconciliation of green electricity transactions, energy users can use this to retain verification proof of green electricity consumption declarations, and regulatory nodes can use this to conduct random checks on on-chain summaries and necessary proof paths.

[0129] S62. Output a reliable failure result:

[0130] when When the transaction fails, the system outputs a trusted settlement failure result. This result includes the transaction verification unit identifier, failure status, minimum conflict constraint number, minimum conflict evidence package summary, and verifiable path. It does not output raw data fields unrelated to minimum conflict.

[0131] Minimum conflict evidence package The summary is written on the blockchain, and the transaction verification unit status is marked as verification failed. The complete evidence package is not written on the blockchain. After authorization, the transaction entity, settlement institution, or regulatory node can obtain the least conflict evidence package and perform a re-verification. The authorization method can be digital signature verification. Only the entity holding a valid digital signature can obtain the complete least conflict evidence package.

[0132] S63. Verification and updating of enforcement evidence packages:

[0133] After obtaining the minimum conflict evidence package, the reviewing party first verifies whether the field digest path in the evidence package can be traced back to the on-chain input digest. Then according to the rule version Restore the minimum set of conflicting constraints Then, the necessary fields in the evidence package are used to perform a satisfiability check, and finally, it is verified whether the remaining constraints can be satisfied after any constraint is removed. If all the above verifications pass, it is confirmed that the evidence package can prove the verification failure, and the disclosure scope is limited to the fields required for minimum conflict.

[0134] If the transaction entity corrects the settlement voucher, updates the voucher status, or resubmits the acceptance certificate, S1 to S6 are re-executed based on the new input digest. The original verification record is not overwritten. The new verification record is associated with the original verification record through the transaction verification unit identifier, rule version, and timestamp. On the chain, the transaction verification unit identifier is used as the primary key to associate and store all verification records of the same transaction verification unit in the order of timestamps. Each verification record contains the hash value of the previous verification record, forming a chain-like association structure to support subsequent auditing and dispute resolution.

[0135] Through the detailed description of the above embodiments, the green electricity transaction trusted settlement verification method of the present invention establishes a unified and traceable input boundary for green electricity settlement verification by constructing a standardized transaction verification unit and solidifying the input summary on the blockchain; it achieves pluggable processing of green attributes through field layering and activation bit control, and accurately separates the independent contributions of ordinary electricity and green attributes to the settlement result by combining a dual-track lockstep settlement mechanism; it ensures the credibility of green electricity settlement results through multi-dimensional consistency judgment of metering boundary, consumption boundary, and certificate boundary; and it achieves accurate location of core conflicts and minimizes data disclosure when verification fails through a minimum conflict evidence package generation mechanism. The present invention forms a complete green electricity transaction trusted settlement verification process, which can provide technical support for green electricity transaction settlement reconciliation, green consumption certificate verification, and industry regulatory audit.

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

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

[0138] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes 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.

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

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

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

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

[0143] 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 green electricity transaction trusted settlement verification method, characterized in that, The method flow is as follows: Step S1: Obtain green electricity transaction, metering, settlement, green attribute certificate and consumption certificate data as data to be verified, standardize them according to the same verification rule version and merge them into transaction verification units, and generate on-chain input summary, rule version and field summary path; Step S2: According to the verification rule version, the transaction verification unit is divided into a normal energy field and a green attribute field. The real settlement track input and the counterfactual settlement track input are set. The real settlement track retains the normal energy field and the green attribute field, while the counterfactual settlement track keeps the normal energy field valid and performs a masking mapping on the green attribute field. Step S3: Use the same settlement function to perform dual-track lockstep settlement on the real settlement track input and the counterfactual settlement track input. When the ordinary electrical energy output is consistent, extract the green attribute output difference in the two settlement tracks to obtain the green electrical attribute contribution vector. Step S4: Generate a reliable settlement judgment value based on the consistency relationship between the green electricity attribute contribution vector and the metering boundary, consumption boundary, voucher boundary and settlement price; Step S5: When the trusted settlement judgment value is not passed, generate a set of failure constraints based on the failed branch, extract the minimum conflict constraint set and generate a minimum conflict evidence package; Step S6: Output the trusted settlement success result or trusted settlement failure result, and write the corresponding digest onto the chain.

2. The green electricity transaction trusted settlement verification method according to claim 1, characterized in that, In step S1, the data to be verified includes the transaction contract number, transaction entity identifier, power generation project identifier, metering point identifier, settlement cycle, transaction electricity volume, power generation side metered electricity volume, power consumption side metered electricity volume, settlement electricity volume, settlement price, green attribute unit price, settlement voucher number, settlement voucher amount, green attribute voucher number, voucher corresponding electricity volume, voucher holder account, voucher lock status, voucher transfer status, voucher cancellation status, consumption entity identifier, consumption scenario identifier, consumption cycle, consumption certificate electricity volume, data source signature, and timestamp; the standardization includes unified field names, unified measurement units, unified time format, unified entity identifier format, unified signature format, and unified numerical precision.

3. The green electricity transaction trusted settlement verification method according to claim 2, characterized in that, When forming the transaction verification unit, the data is merged and standardized according to the same transaction contract, the same settlement period, the same transaction entity relationship, and the same verification rule version. When the same transaction contract corresponds to multiple green attribute voucher numbers in the same settlement period, the multiple green attribute voucher numbers are treated as a set of voucher status fields in the same transaction verification unit, and the contract boundary of the transaction verification unit remains unchanged.

4. The green electricity transaction trusted settlement verification method according to claim 1, characterized in that, The on-chain input digest is generated based on the standardized coded transaction identifier field, subject identifier set, electricity metering field set, settlement certificate field set, consumption certificate field set, green attribute certificate status field set, and verification rule version. The on-chain input digest, verification rule version, field digest path, and data source signature are written on the chain, while the original contract text, complete load curve, and complete settlement bill are kept off-chain.

5. The method for verifying trusted settlement of green electricity transactions according to claim 1, characterized in that, In step S2, the ordinary electricity field includes the trading entity, settlement cycle, metered electricity volume on the generation side, metered electricity volume on the consumption side, ordinary electricity price, basic settlement amount, deviation handling rules, metering data quality identifier, and basic settlement voucher; the green attribute field includes the green attribute voucher number, voucher status, green attribute unit price, green attribute price, green consumption declaration, consumption certificate, green electricity priority clearing mark, voucher lock status, voucher transfer status, and voucher cancellation status; when a field affects both ordinary electricity settlement and green attribute settlement, the field is split into ordinary electricity subfield and green attribute subfield, and field summary paths are set for each.

6. The green electricity transaction trusted settlement verification method according to claim 5, characterized in that, When setting up the real settlement track input and the counterfactual settlement track input, activation bits are set for the fields in the transaction verification unit. In the real settlement track input, the activation bits of the ordinary energy field and the green attribute field are both in a valid state. In the counterfactual settlement track input, the activation bit of the ordinary energy field is in a valid state, and the activation bit of the green attribute field is in a masked state. When performing masking mapping on the green attribute field in the masked state, the voucher status field is mapped to a non-participation in green electricity settlement state, the green attribute price field is mapped to a non-inclusion state, the green consumption declaration field is mapped to an empty declaration state, the voucher occupancy status is mapped to an unoccupied state, and the consumption certificate field is retained in the summary structure but does not participate in the calculation of the declarable consumption amount of the counterfactual settlement track.

7. The green electricity transaction trusted settlement verification method according to claim 1, characterized in that, In step S3, the dual-track lock-step settlement uses the same field sorting, the same metering and data retrieval method, the same ordinary energy settlement rules, the same deviation handling rules, the same rounding rules, the same status update time, and the same numerical precision. The ordinary energy output includes the ordinary energy settlement amount, the ordinary energy price, the deviation settlement result, the basic settlement voucher status, and the basic payment status. When the ordinary energy output in the true settlement track is inconsistent with the ordinary energy output in the counterfactual settlement track, the corresponding transaction verification unit is marked as a counterfactual track generation anomaly, and the differential verification of that transaction verification unit is stopped.

8. The green electricity transaction trusted settlement verification method according to claim 7, characterized in that, The green electricity attribute contribution vector is obtained by subtracting the green attribute output from the counterfactual settlement track output from the green attribute output in the actual settlement track output. The green electricity attribute contribution vector includes the settlement electricity volume increment, price increment, declarable consumption volume increment, and voucher occupancy status difference brought about by the green attribute. When the price increment is zero but the actual settlement track outputs declarable consumption volume, it is marked as an abnormal declaration source. When the price increment is not zero but the voucher occupancy status difference indicates that the voucher is not effectively occupied, it is marked as a price voucher abnormal. When the declarable consumption volume increment is greater than the settlement electricity volume increment, it is marked as a consumption declaration excess abnormality.

9. The green electricity transaction trusted settlement verification method according to claim 1, characterized in that, In step S4, the metering boundary is determined by the metered electricity volume on the generation side, the metered electricity volume on the consumption side, the traded electricity volume, the settlement cycle, and the quality of the metering data; the consumption boundary is determined by the actual consumption volume that the consumption entity can support with consumption certificates within the same settlement cycle and the same consumption scenario; and the voucher boundary is obtained by summing up the valid green attribute voucher electricity volume that can be used in the current transaction verification unit. When generating a reliable settlement judgment value, it is determined whether the settlement electricity increment brought about by the green attribute simultaneously satisfies the metering boundary, consumption boundary, and voucher boundary; whether the price increment brought about by the green attribute corresponds to the green attribute unit price and the settlement electricity increment; and whether the current status of the voucher belongs to the set of voucher statuses allowed to participate in this settlement verification under the verification rule version.

10. The green electricity transaction trusted settlement verification method according to claim 1, characterized in that, In step S5, the set of failed constraints includes measurement boundary constraints, absorption boundary constraints, voucher boundary constraints, green attribute price constraints, subject and cycle binding constraints, and on-chain digest consistency constraints. Constraint dependencies are established for the set of failed constraints, consisting of constraint nodes and field nodes, and a stable sort is formed according to constraint type, field source, verification rule version, and timestamp. Candidate constraints are removed sequentially, and satisfiability judgment is re-executed. Constraints that become satisfiable after removal are retained, resulting in a minimum conflict constraint set. A minimum conflict evidence package is generated based on the dependency fields of each constraint in the minimum conflict constraint set. The minimum conflict evidence package includes conflict header information, necessary plaintext fields, digest proof fields, signature proof fields, and verification rule identifiers. When there is a need to correct settlement vouchers, update voucher status, or resubmit consumption certificates, the verification process is re-executed based on the new input summary. The original verification record is not overwritten, and the new verification record is stored in association with the original verification record according to the transaction verification unit identifier, verification rule version, and timestamp.

Images