A smart meter data blockchain settlement method

Abstract

The present application relates to the technical field of financial settlement and payment, and particularly relates to a smart meter data blockchain settlement method. The method comprises the following steps: obtaining a smart meter with a security element, a reading frame and a device signature, performing time anchor point registration, binding a rate version image and a share table version image, registering a commitment, generating a table side commitment package and a minimum index key structure; extracting a field comparison set, performing source signature verification, consistency check and consistency judgment, generating a peer check package and a bill consistency proof package; aggregating the same window details and field reorganization, performing risk stratification and path selection, generating a bill object, a bill state record and a settlement execution instruction; completing single transaction atomic settlement of the execution instruction and the bill object, writing a balance snapshot, generating a voucher and a session archive, and processing disputes. The present application reduces plaintext exposure, improves checkable and settlement continuity, supports voucher traceability and governance closed loop.

Description

Technical Field

[0001] This invention relates to the field of financial settlement and payment technology, and in particular to a blockchain settlement method for smart meter data. Background Technology

[0002] In the field of financial settlement and payment technology, existing solutions for smart meter data to participate in settlement typically revolve around a multi-level reconciliation and step-by-step settlement process, consisting of direct transmission of meter readings from smart meters with security elements, metering aggregation at the concentrator side, and access and distribution through a settlement front-end gateway. This process suffers from limitations such as the potential for data tampering during transmission and delivery across different stages, difficulties in synchronizing rate and allocation standards across different systems, and the disconnect between settlement triggering and reconciliation determination. Existing methods often rely on fixed-period or threshold-triggered deductions, separating reconciliation, payment, balance registration, and voucher generation into different stages. In scenarios where on-chain recording and off-chain processing occur in parallel, inconsistencies in field definitions and unclear source status can easily arise, making it difficult to ensure the stable generation of on-chain settlement vouchers and the continuous linkage of session archiving. Regarding the joint processing of how to generate on-chain settlement vouchers based on the table-side commitment package and minimal index key structure, through consistency judgment and single-transaction atomic settlement, existing technologies generally have gaps in aspects such as the minimal exposure design of commitments and indexes, field-level comparison between concentrator metering summaries and settlement front-end gateway metering summaries, rule-based version management of consistency judgment, and the same-transaction orchestration of settlement execution instructions and billing objects. This makes it difficult to form a continuous process of collection-comparison-judgment-settlement-archiving in smart meter-involved settlement application scenarios. As a result, the peer verification package and bill consistency proof package are difficult to be stably received by subsequent billing objects, billing status records, and settlement execution instructions, which in turn affects the unified generation and traceable management of settlement transaction receipts, on-chain settlement vouchers, dispute vouchers, and review lists. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a smart meter data blockchain settlement method, comprising:

[0004] Acquire smart meters with safety elements, reading frames, and device signatures; register time anchors based on session IDs, including recording occurrence time, reception time, and registration time; perform term registration and definition, including establishing unique spelling entries and semantic descriptions for keywords; use version selectors and validity checkers to perform rate version mirror binding and apportionment table version mirror binding; and perform index key construction and commitment registration processing based on meter identifiers, time windows, and meter reading rounds to generate a minimal index key structure.

[0005] Based on the minimum index key structure, source signature verification is performed using the key registration list and certificate registration list. Consistency checks are performed based on the rate version mirror and the allocation table version mirror. Time anchors are compared with rate versions and allocation ratios with dimensional standards. Consistency judgment and evidence encapsulation operations are performed using rule registration sub-units to generate bill consistency proof packages.

[0006] Based on the bill consistency proof package, the same window details are aggregated using the primary key merging strategy, fields are compiled according to the predefined field mapping table, and risk stratification strategy mapping, settlement path selection and parameter assembly are performed using the rule registration sub-unit and strategy mapping unit to generate settlement execution instructions.

[0007] Based on the settlement execution instruction, the instruction acceptance unit and transaction orchestration unit are used to perform single-transaction atomic settlement, including deduction operation, collection operation, balance update operation and bill fingerprint writing operation, balance snapshot writing, voucher generation using voucher generation unit, session archiving, anomaly appeal detection and freeze suspension operation, and generate dispute vouchers and review list.

[0008] Furthermore, smart meters with security elements, reading frames, and device signatures include:

[0009] The smart meter with security element refers to an energy metering device with a built-in security element and local signature capability. The security element is used to complete the reading frame signing and key control on the device side. The reading frame includes meter identification, channel number, sampling time, meter reading round and channel status. The device signature refers to the local signature result of the smart meter with security element on the current reading frame and its ancillary fields.

[0010] Furthermore, the rule registration sub-unit includes:

[0011] The rule registration sub-unit includes rules for judging the order of time anchors, rules for matching rate versions, rules for matching apportionment ratios, rules for judging the consistency of units, and rules for prioritizing source status.

[0012] Furthermore, the process of generating vouchers using the voucher generation unit includes:

[0013] The processing chain is initiated by the credential generation unit. The credential generation unit first retrieves the actual block height and transaction index from the on-chain query module based on the transaction hash, and writes the retrieval results into the block height reference field and the transaction index field.

[0014] Furthermore, the process of performing consistency checks based on the rate version mirror and the allocation table version mirror, comparing the time anchor with the rate version and the allocation ratio with the dimensional scope, and using the rule registration sub-unit to perform consistency judgment and evidence encapsulation operations also includes:

[0015] The field lookup list is matched with the peer verification package by session number and primary key field. If a primary key is found to have only a commitment fingerprint reference or only a digest reference during the matching process, the judgment unit does not perform inference merging, but only writes a missing tag on the primary key entry and retains the entry for subsequent judgment.

[0016] Entering the consistency rule matching stage, the consistency rule set is maintained by the rule registration sub-unit. The rules maintained by the rule registration sub-unit include the time anchor chronology judgment rule, rate version matching rule, apportionment ratio matching rule, unit consistency judgment rule and source status priority rule.

[0017] The three types of labels and source status markers for each record in the field comparison list are substituted into the corresponding rules for judgment. The judgment results are not recorded as pass rate or score, but are only applied to the corresponding fields in the form of pass label, difference label and conflict label, and the entry judgment results are formed at the entry level.

[0018] Furthermore, the process of consistency assessment and evidence encapsulation also includes:

[0019] Evidence encapsulation is performed by the encapsulation unit, which aggregates the judgment results of entries with the same primary key according to the session number, along with the corresponding commitment fingerprint reference and digest reference, to generate traceable proof entries;

[0020] The proof entry contains field-level judgment labels, source status markers, time scale records, and mirror version number references. The proof entry does not contain plaintext readings or intermediate calculation quantities.

[0021] The encapsulation unit assigns an entry number to each proof entry and establishes a mapping relationship with the session number. During the encapsulation process, it records the encapsulation time and encapsulation channel, and writes the rule version number used for judgment into the entry header.

[0022] After encapsulation, the process moves to the packaging and output stage. In this stage, the proof entries are serialized in primary key order to form a bill consistency proof package.

[0023] Furthermore, based on the settlement execution instruction, the process of performing single-transaction atomic settlement and balance snapshot writing, which includes deduction operation, collection operation, balance update operation and bill fingerprint writing operation, using the instruction acceptance unit and transaction orchestration unit, also includes:

[0024] Perform entry verification, which verifies whether the path identifier is within the effective range under the current session's policy version number, whether the execution parameters have the required items, and whether the bill object reference exists and is consistent with the session number;

[0025] In cases where fields are missing or effective ranges do not match, the entry verification does not make a default inference. Instead, it adds an instruction verification tag to the settlement execution instruction and sets the path identifier to the frozen review path, and still proceeds to the subsequent transaction orchestration stage.

[0026] The transaction orchestration unit assembles transactions based on path identifiers. Under the direct settlement path, it assembles deduction operations, collection operations, balance update operations, and bill fingerprint writing operations. Under the limit settlement path, it assembles limit deduction sub-operations and registers the uncovered balance as pending amount. Under the delayed settlement path, it records the delay window and assembles the delayed commit sub-operation. Under the freeze review path, it suspends deduction and collection and only registers the freeze flag.

[0027] They are fixed in the same transaction and are identified by both the session number and the transaction sequence number.

[0028] Furthermore, the process of using the instruction acceptance unit and the transaction orchestration unit also includes:

[0029] The transaction orchestration unit adopts a single-transaction atomic settlement orchestration method, which incorporates each sub-operation into the same on-chain transaction for execution. The transaction includes references to bill object fields and version numbers, and the path identifier and session number are written in the on-chain transaction header.

[0030] Furthermore, after the transaction orchestration is completed, the execution engine unit initiates a smart contract call. The smart contract reads the path identifier and execution parameters in the settlement execution instruction and executes the corresponding sub-operations in the orchestration order.

[0031] During the deduction operation, the smart contract standardizes and verifies the payment asset identification and deduction granularity, and registers the deduction record when it meets the path limit;

[0032] During the payment collection process, the smart contract verifies the identity of the asset to be collected against the same field and records the payment collection.

[0033] In the balance update operation, the smart contract locates the account status of both parties based on the primary key field in the bill object field set, calculates the difference between the old and new balances, and writes it into the balance snapshot.

[0034] In the bill fingerprint writing operation, the smart contract writes the commitment fingerprint reference and version number reference from the bill object into the credential field, and leaves the block height placeholder field to be filled by the on-chain return value after submission.

[0035] Furthermore, the execution engine unit writes the execution time scale at the beginning of the transaction execution and the commit time scale at the end of the transaction execution, and records the execution time scale and the commit time scale together in the transaction context;

[0036] The execution engine unit classifies and labels exceptions during execution: when a business exception occurs, it records the business exception label and branches according to the path rules; when a system exception occurs, it records the system exception label and suspends the transaction in the current session, with the transaction replay unit triggering subsequent replay.

[0037] The key innovations of this invention include:

[0038] (1) Based on the reading organization of the table-side commitment package and the minimum index key structure, and after the time anchor registration, the rate version image and the apportionment table version image are bound together to form the minimum exposed data commitment and caliber locking link, involving the reading frame, device signature and commitment hash registration of smart meters with security elements.

[0039] (2) Regarding the generation of the peer verification package, based on the source signature verification and caliber consistency check, the table-side commitment package, the concentrator metering summary and the settlement front-end gateway metering summary are compared and judged for field comparison, and evidence is encapsulated to generate the bill consistency proof package, which involves the judgment process of field comparison set and rule version reference.

[0040] (3) Starting from the bill object and settlement execution instruction, construct an integrated execution closed loop of single transaction atomic settlement and balance snapshot writing, voucher generation and session archiving, and abnormal appeal detection and freeze suspension processing. Output settlement transaction receipt, on-chain settlement voucher, dispute voucher and review list, involving path selection and parameter assembly of same transaction submission and session number through.

[0041] The following are its main beneficial effects:

[0042] (1) It is applied to the collection-registration-indexing link from smart meters with safety elements to on-chain records. It carries the reading commitment through the meter-side commitment package and the minimum index key structure. After the rate version mirror and the allocation table version mirror are bound, the minimum exposed input with verifiable caliber is formed, which reduces the impact of plaintext reading and caliber drift caused by cross-system direct transmission. It is suitable for settlement scenarios where meter reading time slots are segmented and multiple rate periods coexist.

[0043] (2) It is applied to the multi-source reconciliation and evidence generation link. Through the field-level comparison of source signature verification and consistency check, it generates the peer verification package and bill consistency proof package, so that the device signature, time anchor and version image are uniformly referenced in the same session, reducing the risk of unclear source status and inconsistent field standards caused by cross-link transmission and landing. It is suitable for scenarios where the concentrator metering summary and the settlement front-end gateway metering summary are accessed in parallel.

[0044] (3) It operates on the settlement execution and voucher governance chain. Through single-transaction atomic settlement, it writes the deduction, receipt and balance snapshot into the same transaction completion. After voucher generation and session archiving, it connects the abnormal appeal detection and freeze suspension processing, forming a continuous record from settlement execution instruction to on-chain settlement voucher, dispute voucher and review list. It can review transaction path and session state, and is suitable for business boundaries where direct settlement, limit settlement and delayed settlement coexist. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating a smart meter data blockchain settlement method provided in an embodiment of this application. Detailed Implementation

[0046] Example 1: Refer to Figure 1 This is a flowchart illustrating a smart meter data blockchain settlement method provided in an embodiment of the present invention. The process may include at least steps S100-S400:

[0047] S100: Obtain the smart meter with safety element, reading frame and device signature; register the time anchor based on the session number, including the record occurrence time, reception time and registration time; perform term registration and definition, including establishing unique spelling entries and semantic descriptions for keywords; use version selector and validity checker to perform rate version mirror binding and apportionment table version mirror binding; perform index key construction and commitment registration processing based on meter identifier, time window and meter reading round; generate minimal index key structure.

[0048] S200: Based on the minimum index key structure, source signature verification is performed using the key registration list and certificate registration list. Consistency checks are performed based on the rate version mirror and the allocation table version mirror. Time anchors are compared with rate versions and allocation ratios with dimensional standards. Consistency judgment and evidence encapsulation operations are performed using rule registration sub-units to generate bill consistency proof packages.

[0049] S300: Based on the bill consistency proof package, use the primary key merging strategy to aggregate details within the same window, compile fields according to the predefined field mapping table, use the rule registration sub-unit and strategy mapping unit to perform risk stratification strategy mapping, settlement path selection and parameter assembly processing, and generate settlement execution instructions.

[0050] S400: Based on the settlement execution instruction, the instruction acceptance unit and transaction orchestration unit are used to perform single-transaction atomic settlement, including deduction operation, collection operation, balance update operation and bill fingerprint writing operation, balance snapshot writing, voucher generation using voucher generation unit, session archiving, anomaly appeal detection and freeze / suspend operations, and generate dispute vouchers and review lists.

[0051] Step S100 includes at least steps S110-S130:

[0052] S110. Obtain the smart meter with safety element, reading frame and device signature, perform time anchor registration, terminology registration and definition, and obtain the meter side commitment package.

[0053] Specifically, the input source for this step is the smart meter with a security element installed on-site and its corresponding meter reading channel. The smart meter with a security element refers to an energy metering device with a built-in security element and local signature capability. The security element is used to complete reading frame signing and key control on the device side. The reading frame refers to a set of metering values ​​and auxiliary fields packaged by the meter firmware within the meter reading time slot. Auxiliary fields include meter identifier, channel number, sampling time, meter reading round, and channel status. The device signature refers to the local signature result of the smart meter with the security element on the current reading frame and auxiliary fields, used for subsequent source verification. On the access side, the acquisition module pulls reading frames according to the predetermined meter reading time slot and simultaneously reads the device signature. The pulling process uses a session number to label each pull, which is used as a consistent association item in subsequent steps. To form a unified standard, the read reading frame is first sent to the standardization processing stage, mapping the meter identifier, meter reading round, and channel number to unified field names, and completing the consistent registration of units, dimensions, and decimal places. The registration result is bound to the session number. The process then proceeds to the time anchor registration stage. This time anchor registration records the occurrence time, reception time, and registration time of the reading frame within the acquisition link, and writes the chronological relationship between these three times into the time anchor record. Each time anchor record corresponds one-to-one with a reading frame, used for subsequent comparison of time consistency across different links. For terminology management, terminology registration and definition are performed. This process provides unified definitions for keywords such as smart meters with safety components, reading frames, device signatures, meter reading slots, session numbers, and time anchor registration. A unique spelling entry and semantic description are created for each keyword, and the terminology registration and definition establish a reference relationship with the session number, facilitating the use of the same semantic meaning in subsequent steps. Handling anomalies includes missing device signatures, incomplete reading frame fields, incomplete time scales, and duplicate meter readings. Missing or abnormal cases are simply marked without estimation or replacement, and the anomaly label is written with the anomaly category and cause description. Further, after completing data collection, standardization, time anchor registration, and terminology registration, the process proceeds to the table-side commitment generation stage. A table-side commitment refers to the commitment fingerprint and index field set calculated for each reading frame and its associated fields. The commitment fingerprint originates from the reading content and key associated fields, while the index field set includes the meter identifier, time window, and meter reading cycle. Together, the commitment fingerprint and index field set constitute a table-side commitment unit. The table-side commitment generation stage generates several table-side commitment units for each session number and packages these units into a table-side commitment package. The table-side commitment package contains a commitment fingerprint sequence, an index field sequence, time anchor records, and anomaly marker records. The table-side commitment package does not contain the plaintext data of the reading frame. After generation, the table-side commitment package is registered in the commitment cache. The commitment cache establishes a multi-key index based on the session number, meter identifier, and time window. The cache only stores commitments and necessary index fields, not plaintext readings.For commitment units whose device signatures cannot be verified, the commitment cache is maintained but labeled with an unverifiable source to provide source status information for subsequent consistency comparisons.

[0054] Understandably, the output of this step is a table-side commitment package. This package is explicitly labeled as an output field name, and at the end of the step, this output field name is associated with the input location of subsequent steps. Specifically, the table-side commitment package serves as one of the input items in step S120, used to bind the rate version mirror and the allocation table version mirror. It is also used in the processing chain of step S200 for field comparison with the peer digest. Regarding the connection between this main step and subsequent main steps, the table-side commitment package is also reserved as a reference source when generating subsequent billing objects, facilitating cross-main step access to commitment fingerprints and time anchor records.

[0055] S120. Extract the meter ID and time window from the meter-side commitment package, perform rate version mirror binding and allocation table version mirror binding, and generate version mirror binding records.

[0056] Specifically, the input source for this step is the meter-side commitment package generated in step S110. This package contains index fields such as meter identifier, time window, and meter reading cycle. The processing chain first performs index parsing on the meter-side commitment package to obtain the meter identifier and time window. The extracted meter identifier and time window are used as the unique locating key for the binding action in this step. The rate version mirror refers to a set of versioned configuration mirrors that record the rate structure, rate effective range, rate version number, and calculation caliber. The allocation table version mirror refers to a set of versioned configuration mirrors that record the allocation subject, allocation ratio, allocation effective range, and allocation version number. Both are published and referenced in read-only mirror format and are not modified in this step. The binding action is completed collaboratively by the version selector and the validity checker. The version selector retrieves the rate version image and the allocation table version image that are valid within the time window and are mapped to the meter identifier from the configuration image library based on the meter identifier and time window. The validity checker performs coverage checks on the effective interval, uniqueness checks on the version number, and integrity checks on the scope field of the selected images. If the checks fail, an invalid image mark is added to the binding record and the image reference is retained without performing substitution inference.

[0057] Further, after binding is complete, the image reference fixing stage begins. Image reference fixing provides a stable source of information for subsequent field-level consistency verification. This stage creates read-only reference entries for the rate version image and the allocation table version image, and writes these reference entries, along with the session number, meter identifier, and time window, into the binding list. The binding list is a component of the version image binding record, which also includes the time scale of the binding action and a source description. The source description records the image's release channel, release batch, and image verification summary, used to trace the image source in subsequent steps. Anomaly handling covers three scenarios: missing images, misalignment between the image's effective period and the time window, and inconsistent mapping between the image and the meter identifier. When an anomaly occurs, the binding list continues to output but with an anomaly marker. The anomaly marker does not cause image replacement or default rollback; subsequent steps can determine the processing path based on the anomaly marker. Understandably, the version mirror binding record, as an output of this step, is labeled with the output field name "Version Mirror Binding Record" at the end of this paragraph, and establishes a clear relationship with the input location of the next step: the version mirror binding record is used as one of the sole input sources in step S130 for fixing the version reference in index key construction and commitment registration, while retaining its cross-main step reference function in step S200, used to provide the basis for rate and allocation caliber in field comparison. To maintain terminology consistency, the spelling and interpretation of the rate version mirror and allocation table version mirror contained in the version mirror binding record follow the entries in the aforementioned terminology registration and definition, without renaming them.

[0058] S130. Construct the index key and register the commitment hash for the version image binding record to generate the minimum index key structure.

[0059] Specifically, the input sources for this step are the version mirror binding record output from step S120 and the table-side commitment package from step S110. The processing link first enters the index key construction stage. Index key construction is used to provide the minimum searchable set in subsequent cross-module searches. The construction action is completed without introducing plaintext readings. The construction content includes three types of primary key fields: meter identifier, time window, and meter reading cycle, along with subordinate fields such as session number and mirror version number reference. The primary key fields are used for unique positioning in multi-source data, and the subordinate fields are used to establish consistency in caliber references across different links. After the index key construction is completed, the commitment registration stage begins. Commitment registration is used to establish a one-to-one or one-to-many registration relationship between the commitment fingerprint in the table-side commitment package and the index key. The registration relationship is written to the commitment registration table. The commitment registration table only saves the commitment fingerprint, the minimum index key, and the necessary time scale, and does not save plaintext readings or calculate intermediate values. During the commitment registration process, duplicate commitments, inconsistencies between commitments and index keys, and overlapping time windows are detected. Detection results are appended to the commitment registration entry as an anomaly tag. The anomaly tag indicates the source and availability status of the registration entry and does not trigger valuation replacement or automatic repair. Further, after index key construction and commitment registration are completed, the minimum index key structure output stage begins. The minimum index key structure is a fixed set of fields consisting of meter identifier, time window, meter reading cycle, and mirror version number reference. This set is read-only, facilitating direct use as input parameters in subsequent steps. The minimum index key structure is bound to the session number, and the generation time scale and registration channel are recorded during persistence. The registration channel records the target domain and access policy to which this structure is written. The access policy limits the method and frequency of reading in subsequent steps. To accommodate subsequent peer digest verification, this stage also writes the minimum index key structure to the cross-link cache. The cross-link cache exposes a read-only access interface for subsequent steps and provides fast location capabilities based on session number and meter identifier. In scenarios where the index key lacks a primary key field, the minimum index key structure is still output, but a placeholder label is written at that primary key position. Subsequent steps use this placeholder label to branch the processing path. Understandably, the output of this step is the minimum index key structure. At the end of this section, the output field name is explicitly marked as the minimum index key structure, and its input position in the next step is specified: the minimum index key structure will be used as one of the input items in step S210 to locate the concentrator metering summary and the settlement front-end gateway metering summary in the peer-to-peer signature verification and caliber consistency check. It also serves as the index reference source when generating the bill object in step S300, and is used for primary key merging during peer-to-peer detail aggregation. In summary, the technical effect of this step is: through the joint processing of version mirror binding records and table-side commitment packages, a minimum index key structure that neither contains plaintext readings nor lacks stable positioning capabilities is formed, and the registration association between commitments and indexes is completed, providing a directly usable positioning and caliber reference basis for subsequent peer-to-peer verification and bill aggregation.

[0060] Step S200 includes at least steps S210-S230:

[0061] S210. Obtain the metering summary of the concentrator and the metering summary and minimum index key structure of the settlement front-end gateway, perform source signature verification and caliber consistency check, and obtain the peer verification packet.

[0062] Specifically, the input sources for this step are the minimum index key structure generated in step S130 and the data access channels from the concentrator and the settlement front-end gateway. The concentrator metering summary refers to the metering information summary aggregated by the concentrator according to the same meter reading time slot, which includes at least the meter identifier, time window, meter reading round, reading summary value, data source description, and summary signature. The settlement front-end gateway metering summary refers to the metering information summary translated by the settlement front-end gateway at the access layer and output according to unified field names, which includes at least the meter identifier, time window, meter reading round, reading summary value, access channel description, and summary signature. The minimum index key structure is used for primary key positioning and version reference matching when retrieving target summaries in the two access channels. When the processing link starts, the access module initiates a precise pull on the access channel according to the session number and the meter identifier, time window and meter reading round in the minimum index key structure. It requests the concentrator to output the corresponding concentrator metering summary and at the same time requests the settlement front-end gateway to output the corresponding settlement front-end gateway metering summary. The pull action is executed concurrently in the same session. The access module embeds the session number and access time scale into the returned summary record for subsequent traceability.

[0063] Furthermore, source signature verification is performed by the source verification unit. This unit verifies the signatures in the concentrator metering digest and the settlement front-end gateway metering digest, respectively. The signature metadata used for verification originates from the key registration list and certificate registration list of each source. The key registration list records the source identity, key identifier, key status, and validity period. The certificate registration list records the source certificate chain, revocation status, and audit channel. During the verification process, the source verification unit marks instances of missing signatures, expired signatures, signature mismatches, and revoked certificates. The marking results are appended to the corresponding digest as source status markers, without replacing the digest content itself. After source verification is completed, a consistency check is performed by the consistency check unit. This unit uses the mirror version number referenced in the minimum index key structure to retrieve the field scope of the rate version mirror and the allocation table version mirror from the version mirror binding record. It then compares the field names, unit descriptions, unit scales, and decimal place strategies of the two types of summaries item by item, while also verifying the time window coverage relationship and the meter reading cycle alignment relationship. When there are missing fields, inconsistent units, time window spans, or inconsistent meter reading cycles, the consistency check unit adds a difference label to the corresponding field and writes the difference label and source status mark into the summary verification result. For boundary scenarios such as duplicate fetching, summary record conflicts, and mismatched session numbers, the access module does not perform merging inference; it only writes the conflict description into the access conflict record, which remains read-only in this step. Understandably, after the source signature verification and caliber consistency check are completed, the encapsulation unit packages the concentrator metering summary, the settlement pre-gateway metering summary, the source status flag, the difference tag, the access time scale, and the session number into a peer verification package. The peer verification package is explicitly recorded as an output field name in this step, and its subsequent input position is clearly indicated at the end of the paragraph as one of the input items in step S220, used for field comparison with the table-side commitment package. At the same time, the peer verification package has cross-main step reference attributes between main steps, and can be passively referenced as a source description during the bill object generation process in step S300, used to describe the reconciliation source and source status, without changing the generation order and value rules of the bill fields.

[0064] S220. Extract the field comparison set from the table-side commitment package and the peer verification package, compare the time anchor, rate version, sharing ratio and unit caliber, and generate a field comparison list.

[0065] Specifically, the input sources for this step are the table-side commitment package generated in step S110 and the peer verification package output in step S210. The field comparison extraction unit first reads the commitment fingerprint sequence, index field sequence, time anchor record, and anomaly marker record from the table-side commitment package, and then reads the concentrator metering summary, settlement front-end gateway metering summary, source status marker, difference label, and access time scale from the peer verification package. Based on this, the field comparison extraction unit constructs candidate comparison entries. The candidate comparison entries use the meter identifier, time window, and meter reading round in the minimum index key structure as the primary key, and the corresponding fields of the commitment fingerprint and the two types of summaries as the columns to be compared. When a primary key corresponds to multiple summary records or commitment fingerprint records, the field comparison extraction unit marks each record as a case of multiple records with the same primary key and establishes a subordinate sequence number on the candidate comparison entry without weighting or valuation. The process then proceeds to the time anchor comparison sub-process, which is executed by the time alignment unit. The time alignment unit compares the occurrence time, reception time, and registration time in the table-side commitment packet with the access time scale in the peer verification packet to determine the order of events, records whether there are any cases of cross-window collection or cross-window registration, and writes the results into the time comparison label.

[0066] Furthermore, the rate version and allocation ratio comparison sub-process is executed by the caliber comparison unit. The caliber comparison unit calls the version mirror binding record to obtain the version number and field caliber of the rate version mirror and the allocation table version mirror. It then checks the rate and allocation fields of the two types of summary records in the candidate comparison entries item by item. During the check, no missing items are filled; only inconsistencies in version number, caliber description, or missing allocation ratios are recorded. The comparison results are written into the caliber comparison label. The dimension caliber comparison sub-process is executed by the dimension comparison unit. The dimension comparison unit checks the dimension expression of the corresponding fields of the commitment fingerprint and the two types of summaries item by item according to the unit, dimension, and decimal place strategy in the terminology registration and definition. Inconsistencies are recorded, and dimension difference labels are added to the corresponding fields. The field comparison extraction unit merges the time comparison label, caliber comparison label, and dimension difference label output by the above three sub-processes with the candidate comparison entries to form a comparison entry set. The comparison entry set maintains its binding relationship with the session number and also writes the source status mark. After the reference set is formed, the field reference construction unit generates a field reference set according to the primary key order. The field reference set is the core intermediate product of this step, containing primary key fields, commitment fingerprint references, two types of digest references, and three types of reference tags. It does not carry plaintext reading fields and does not return valuation results. For digest records with abnormal markers in the source signature, the field reference construction unit retains the record in the field reference set and adds a source abnormality tag. Subsequent consistency judgments can use this to select the path.

[0067] Understandably, after generating the field comparison set, the field comparison construction unit enters the list output stage. The list output stage forms a field comparison list from the field comparison set during the serialization process, and embeds an output time scale and processing channel identifier into each list record. The field comparison list is explicitly recorded as the output field name as the output product of this step, and its subsequent input position is clearly indicated at the end of the paragraph as the input item of step S230 for consistency judgment and evidence encapsulation. At the same time, the field comparison list has cross-main step reference attributes between main steps, and can be passively referenced as field source description when the bill object is generated in step S300, without changing the generation order of the bill object fields.

[0068] S230. Perform consistency judgment and evidence encapsulation on the field comparison list to generate a bill consistency proof package.

[0069] Specifically, the input sources for this step are the field comparison list output from step S220, the peer verification package output from step S210, and the version mirror binding record from step S120. The judgment unit first performs item-level pairing between the field comparison list and the peer verification package according to the session number and primary key field. During the pairing process, if a primary key is found to have only a commitment fingerprint reference or only a digest reference, the judgment unit does not perform inference merging, but only writes a missing tag on the primary key entry and retains the entry for subsequent judgment. Then, the consistency rule matching stage is entered. The consistency rule set is maintained by the rule registration subunit. The rules maintained by the rule registration subunit include time anchor priority relationship judgment rules, rate version matching rules, apportionment ratio matching rules, dimensional consistency judgment rules, and source status priority rules, etc. The judgment unit substitutes the three types of tags and source status markers of each record in the field comparison list into the corresponding rules for judgment. The judgment result is not recorded as a pass rate or score, but only falls on the corresponding field in the form of pass tag, difference tag, and conflict tag, and forms the entry judgment result at the entry level. For cases where the source status is abnormal but the scope is consistent, the judgment unit marks the entry judgment result as "Source restricted, passed"; for cases where the source status is normal but the scope is different, the judgment unit marks the entry judgment result as "Scope difference, pending verification"; for cases where time anchors are registered or collected across windows, the judgment unit adds a time abnormality label to the entry judgment result.

[0070] Furthermore, evidence encapsulation is performed by the encapsulation unit. This unit aggregates the judgment results of entries with the same primary key according to the session number, along with the corresponding commitment fingerprint reference and digest reference, generating traceable proof entries. Each proof entry includes field-level judgment tags, source status markers, time scale records, and mirror version number references. Proof entries do not contain plaintext readings or intermediate calculation quantities. The encapsulation unit assigns an entry number to each proof entry and establishes a mapping relationship with the session number. During the encapsulation process, it records the encapsulation time and channel, and writes the rule version number used for judgment into the entry header for easy traceability in subsequent invoice object generation and dispute resolution stages. After encapsulation, the process proceeds to the packaging output stage. This stage serializes the proof entries according to the primary key order, forming an invoice consistency proof package. This package is the output of this step and is explicitly recorded as the output field name. The bill consistency proof package is explicitly used at the end of the segment for the input item in step S310, which is used for window detail aggregation and field compilation. At the same time, the bill consistency proof package has cross-main step reference attributes between main steps. It can be passively referenced as a review basis in the dispute handling path of step S400 without changing the generation process of settlement transaction receipt and on-chain settlement voucher.

[0071] In summary, the technical effects of this step are as follows: By making rule-based judgments and encapsulating evidence on the field comparison list, a bill consistency proof package is formed that is associated one-to-one with the session number, primary key field, and version reference. This provides directly usable judgment conclusions and source explanations for the subsequent generation of bill objects and the selection of settlement paths, and maintains traceable records of source status and differences in caliber.

[0072] In one embodiment, S230, consistency judgment and evidence encapsulation are performed on the field comparison list to generate a bill consistency proof package. The input sources for this step are the field comparison list output in step S220, the peer verification package output in step S210, and the version mirror binding record in step S120. When the processing link starts, the judgment unit first performs item-level pairing between the field comparison list and the peer verification package according to the session number and primary key field. If it is found that a primary key only has a commitment fingerprint reference or only has a digest reference during the pairing process, the judgment unit does not perform inference merging, but only writes a missing tag on the primary key entry and retains the entry for subsequent judgment. Then, the consistency rule matching stage is entered. The consistency rule set is maintained by the rule registration subunit. The rules maintained by the rule registration subunit include time anchor priority relationship judgment rules, rate version matching rules, apportionment ratio matching rules, unit consistency judgment rules, and source status priority rules, etc. The judgment unit substitutes the three types of tags and source status markers for each record in the field comparison list into the corresponding rules for judgment. The judgment result is not recorded as a pass rate or score, but is only applied to the corresponding field in the form of a pass tag, a difference tag, and a conflict tag, forming an entry judgment result at the entry level. For cases where the source status is abnormal but the scope is consistent, the judgment unit marks the entry judgment result as "Source Restricted Pass"; for cases where the source status is normal but the scope is different, the judgment unit marks the entry judgment result as "Scope Difference Pending Review"; for cases where there is cross-window registration or cross-window collection at the time anchor point, the judgment unit adds a time abnormality tag to the entry judgment result.

[0073] Formula ① is used to calculate the violation index of the time anchor sequence. It measures the degree of violation of the time sequence based on the occurrence time, reception time, registration time in the time anchor record and the access time scale in the peer verification packet.

[0074]

[0075] in: Indicates the time of occurrence, derived from the time anchor record in the field lookup list, and takes the value of the timestamp. This indicates the receiving time, which is derived from the time anchor record in the field lookup list, and its value range is the timestamp value. The registration time is derived from the time anchor record in the field lookup list, and its value range is the timestamp value. This indicates the access time scale, which originates from the access time scale field in the peer's verification packet, and its value range is the timestamp value; This indicates a violation of the time sequence indicator, and its value range is non-negative real numbers. The occurrence time, receipt time, and registration time are extracted from the field comparison list and recorded as follows. , , The access time scale is extracted from the peer's verification packet and recorded as... The four elements together form the formula ①. .

[0076] Formula ① As an input item for the time anchor point rule judgment in this step, it is used for the time consistency score calculation in subsequent formula ②.

[0077] Formula ② is used to convert the time violation index into a time consistency score, and introduces the time window length for normalization. The higher the score, the better the time sequence consistency.

[0078] in: The output is derived from formula ① and its range is non-negative real numbers; The time window length is derived from the time window span of the index field sequence in the field lookup list, and its value range is positive real numbers. This represents the time consistency score, with a value range of (0,1).

[0079] Obtained from formula ① Time window length in the field comparison list Together they form the formula ② Formula ② As an intermediate indicator for rule matching in this step, it is used to generate the entry judgment result of subsequent formula ③.

[0080] The output of this section is the item judgment result, which includes fields such as time consistency score, missing label, pass label, difference label, conflict label, and source status mark. These fields are used as input items in the evidence encapsulation step of this main step to generate proof items.

[0081] Following the aforementioned time consistency score The results of matching with other rules enter the fusion and judgment stage. The judgment unit aggregates the multi-rule outputs for each item based on the rule weights and priorities maintained by the rule registration sub-unit, forming the overall judgment result at the item level. For rate version matching rules, the judgment unit checks whether the rate version mirror version number in the version mirror binding record is consistent with the rate field version number of the two types of summary records in the peer verification package. If they are consistent, it is recorded as pass; otherwise, it is recorded as difference. For the allocation ratio matching rule, it checks whether the allocation table version mirror version number is consistent with the allocation field version number of the summary record. For the unit consistency judgment rule, it checks whether the unit and unit strategies in the terminology registration and definition are consistent with the unit expression of the summary record field. For the source status priority rule, it records the normal status as pass and the abnormal status as difference based on the source status mark in the peer verification package. The above rule matching results and time consistency scores jointly participate in the generation of the item judgment result. Formula ③ is used to calculate the overall consistency score of the item. Combining the time consistency score with other rule binary indicators, the influence of multiple rules is fused in a product form. The higher the score, the better the item consistency.

[0082]

[0083] in: The output is derived from formula ② and its range is (0,1]. This indicates the rate version matching metric, which is derived from the comparison result between the rate version image version number in the version image binding record and the rate field version number in the peer verification package. The value range is {0,1}, where 1 indicates a match and 0 indicates a mismatch. This represents the matching index of the sharing ratio, which is derived from the comparison result between the version number of the sharing table in the version image binding record and the version number of the sharing field in the peer verification package. The value range is {0,1}. The unit consistency index is derived from the comparison between the unit strategy in the terminology registration and definition and the unit of the field in the peer verification package, and its value range is {0,1}. This indicates the source status indicator, which originates from the source status flag in the peer's verification packet. Its value range is {0,1}, where 1 indicates normal and 0 indicates abnormal. This represents the overall consistency score of the item, with a value range of [0,1].

[0084] Obtained from formula ② Generated by matching rules , , , Together they form the formula ③ Formula ③ As the core indicator for judging the results of this step, it is used as input for subsequent evidence encapsulation.

[0085] Formula ④ is used to map the overall consistency score of an item to an item judgment label, and discretizes it based on a threshold to generate pass, difference, or conflict labels, which facilitates subsequent evidence encapsulation and use.

[0086]

[0087] in: The output is derived from formula ③ and has a range of [0,1]. This indicates that the threshold is derived from the threshold configuration in the rule registration sub-unit, and the value range is (0,1). The difference threshold is derived from the threshold configuration in the rule registration sub-unit, and its value range is (0,1). ; This represents the entry judgment label, with a value range of discrete enumeration {pass label, difference label, conflict label}.

[0088] Obtained from formula ③ Thresholds in the rule registration sub-unit , Together they form the formula in ④ Formula ④ The output label of the entry judgment result in this step is used for the generation of proof entries in subsequent evidence encapsulation.

[0089] The output of this section is the item judgment result, which includes fields such as the overall consistency score of the item, the item judgment label, the source status mark, and the time scale record. These fields are used as input items in the evidence encapsulation step of this main step to construct the proof item.

[0090] Following the aforementioned entry judgment results and related fields, the evidence encapsulation stage begins. The encapsulation unit aggregates entry judgment results with the same primary key and their corresponding commitment fingerprint and digest references according to the session number, generating traceable proof entries. Proof entries include field-level judgment tags, source status markers, time scale records, and mirror version number references. Proof entries do not contain plaintext readings or intermediate calculation quantities. The encapsulation unit assigns an entry number to each proof entry and establishes a mapping relationship with the session number. During the encapsulation process, it records the encapsulation time and channel, and writes the rule version number used for judgment into the entry header for easy traceability in subsequent invoice object generation and dispute resolution stages. After encapsulation, the process proceeds to the packaging and output stage. The packaging and output stage serializes the proof entries according to the primary key order, forming an invoice consistency proof package.

[0091] Formula ⑤ is used to calculate the unique identifier of the proof entry, generating a hash value based on the entry number, session number, and time scale to ensure the traceability and tamper-proof nature of the entry.

[0092]

[0093] in: This represents the entry number, derived from the sequence number assigned by the encapsulation unit, and its value range is positive integer; This represents the session ID, which originates from the session ID field in the pairing process; This indicates the encapsulation time scale, which is derived from the timestamp recorded by the encapsulation unit, and its value range is the timestamp value. This represents a hash function, using the SHA-256 algorithm. This represents a unique identifier for the proof entry, and its value range is a fixed-length string.

[0094] By entry number Session number With packaging time Together they form the formula in ⑤ Formula ⑤ As a header field of the proof entry, it is used for the serialization organization of subsequent formula ⑥.

[0095] Formula 6 is used to generate the serialized structure of the bill consistency proof package, sort the proof entries according to the primary key order and calculate the overall fingerprint, which facilitates rapid retrieval and verification in subsequent steps.

[0096] in: The output set derived from formula ⑤; This indicates a sorting function based on the primary key field, which includes the meter identifier, time window, and meter reading cycle. This indicates the concatenation operator; Represents a hash function; This represents the serialized structure of the bill consistency proof packet, with a value range of binary data.

[0097] The set of proof entry identifiers obtained from formula ⑤ After sorting and hashing, the result is shown in formula ⑥. Formula 6 As the output of this step, it is used as the input for subsequent steps.

[0098] The output of this section is a bill consistency proof package. The bill consistency proof package contains fields such as proof item sequence, serialization structure, rule version number, and time scale record. These fields are used as input items in the same window detail aggregation and field compilation stage of step S310 for bill object generation. At the same time, the bill consistency proof package has cross-main step reference attributes and can be passively referenced as a review basis in the dispute handling path of step S400.

[0099] This section summarizes the technical effects: By combining time anchor rules with multi-rule fusion judgments, fine-grained item judgment results are generated, and evidence encapsulation is combined to form a traceable proof package, ensuring the objectivity and verifiability of consistent judgments and providing a reliable evidentiary basis for subsequent settlements.

[0100] Step S300 includes at least steps S310-S330:

[0101] S310. Obtain the bill consistency proof package and minimum index key structure, perform same-window detail aggregation and field compilation to obtain the bill object;

[0102] Specifically, the input sources for this step are the bill consistency proof package output from step S230 and the minimum index key structure output from step S130, with the two maintaining a correspondence in the session number and primary key fields. The bill consistency proof package refers to the set of proof entries consisting of entry judgment results, field-level judgment tags, source status markers, time scale records, and mirror version number references; the minimum index key structure refers to the fixed set of fields consisting of meter identifier, time window, meter reading cycle, and mirror version number references. The processing link first involves the same-window positioning unit retrieving and locating the bill consistency proof package based on the meter identifier, time window, and meter reading cycle in the minimum index key structure, extracting proof entries belonging to the same meter and the same meter reading cycle within the same time window, and generating a same-window candidate set; the same-window candidate set is written with the session number and positioning time scale during generation, and is used to trace the positioning process in subsequent grouping and aggregation stages. In cases where multiple proof entries exist under the same primary key, the peer location unit sequentially labels them using their subordinate serial numbers, without merging any fields or removing entries with abnormal sources, and retains the abnormal source tags as is in the peer candidate set. The next step is peer detail aggregation, performed by the aggregation unit. This unit uses a primary key merging strategy to merge the peer candidate set, grouping entries based on the triplet of meter identifier, time window, and meter reading cycle, aggregating entries in the same group into peer detail blocks. The peer detail block serves as the basic container for subsequent field compilation, containing the entry set, source status summary, judgment tag summary, and time scale summary. During the merging process, the aggregation unit does not prune entry content, perform valuation or inference, but only records the number of entries and tag coverage on the peer detail block, writing the recorded content into the block-level description header of the peer detail block.

[0103] Further, field organization is performed by a field organization unit. This unit categorizes and standardizes the fields in the peer detail block according to a predefined field mapping table. The field mapping table, provided by terminology registration and definition, includes a unique set of spellings and field names, encompassing fields such as commitment fingerprint references, source status markers, time scale records, mirror version number references, and entry judgment tags. Field organization first performs field relocation, grouping synonymous fields from different sources into a unified field name without altering their meaning. Next, it performs field ordering, fixing the field order according to the bill object's field order requirements, and writing the sorting result into a field order description. Then, it performs a field coverage check, marking each field to ensure it is completely covered by the peer detail block, generating missing tags for missing fields and attaching explanations of the reasons for the missing fields. Missing tags do not trigger any filling actions. After field organization is complete, a bill field set is generated. This set contains the fixed field items required by the bill object and references the original entries and judgment tags in the peer detail block. Subsequently, the object generation unit constructs a bill object instance based on the bill field set. The bill object is a structured object containing a field set, version reference, commitment fingerprint reference, verification status, and session number. The verification status is obtained by summarizing item judgment tags and is used to indicate the basis for subsequent risk stratification strategies. When generating the bill object, the object generation unit writes the object generation time scale and the object generation channel identifier. The channel identifier is used to record the processing path traversed during object generation. During the object generation stage, if the same window detail block contains source anomaly tags or caliber difference tags, the bill object will retain this tag set in the verification status field without changing the field values ​​or field order.

[0104] Understandably, the output of this step is a billing object. The billing object is explicitly recorded as an output field name at the end of this section, and its subsequent input position is clearly defined in the statement as an input item for step S320. This input is used to extract the consistency level and risk factor from the billing object and perform risk stratification strategy mapping. Simultaneously, the billing object has cross-main-step reference attributes and can be passively referenced as a field source description during the voucher generation and session archiving process in step S400, without changing the generation order of settlement transaction receipts and on-chain settlement vouchers.

[0105] S320. Extract the consistency level and risk factor from the bill object, perform risk stratification strategy mapping, and generate a bill status record.

[0106] Specifically, the input source for this step is the bill object output from step S310. The bill object contains fields such as verification status, commitment fingerprint reference, source status marker, time scale record, and mirror version number reference. The processing chain first involves the factor extraction unit parsing the bill object to extract a set of risk factors for stratified judgment. This risk factor set includes source status density, coverage of caliber differences, time scale span, item judgment label distribution, and mirror version number change trajectory. All of these risk factors are descriptive indicators directly calculated or extracted from the internal fields of the bill object, without containing plaintext readings or relying on external valuation actions. The factor extraction unit establishes an extraction description for each risk factor, recording the factor's field source, extraction time, and extraction channel. If a missing field is encountered during extraction, the factor extraction unit writes a missing label at the corresponding factor position and retains the factor's position in the risk factor set, without filling in the missing factors. The process then proceeds to the consistency level determination stage, which is performed by the level determination unit. This unit classifies the consistency level of the billing object based on the verification status and risk factor set. The classification rules are derived from the rule registration subunit and are marked with a version number, including source status mapping rules, caliber difference mapping rules, time scale mapping rules, and label coverage mapping rules. The level determination process concatenates and merges the level fragments output by each mapping rule to form the billing consistency level. The billing consistency level is expressed as a discrete level, consisting of an enumeration of levels such as "sufficient," "moderate," and "insufficient." The level determination unit writes a consistency level field onto the billing object and writes the rule version number and determination time scale next to the level field.

[0107] Furthermore, the risk stratification strategy mapping is performed by the strategy mapping unit. The unit selects the corresponding risk stratification strategy from the strategy library based on the consistency level and risk factor set. The strategy library is maintained and published by version by the strategy registration subunit and includes strategy entries such as direct settlement strategy, limit settlement strategy, delayed settlement strategy, and freeze review strategy. The strategy mapping unit writes the selection results into the strategy field of the bill status record and adds a strategy version number and strategy effective range description to the selected strategy entry. For bill objects with a sufficient consistency level, the strategy mapping unit maps them to the direct settlement strategy; for bill objects with a moderate consistency level, the strategy mapping unit maps them to the limit settlement strategy or delayed settlement strategy; for bill objects with an insufficient consistency level or with an abnormal source label and high coverage of caliber differences, the strategy mapping unit maps them to the freeze review strategy. During the strategy mapping process, no field values ​​of the bill object are changed, and the bill field set is not trimmed; only the strategy expression is added to the bill status record. The bill status record is a structured record formed in this step, containing bill object references, consistency level, risk factor set, strategy fields, rule version number, strategy version number, and judgment time scale. The bill status record is associated with the session number when it is written, and the output time scale and output channel identifier are recorded in the persistence layer. The output channel identifier is used to quickly retrieve the corresponding policy entry and version information in the subsequent path selection and parameter assembly stages.

[0108] Understandably, the output of this step is a bill status record. This record is explicitly recorded as an output field name at the end of this section, and its subsequent input position is clearly defined in the statement as an input item for step S330, used for settlement path selection and parameter assembly to generate settlement execution instructions. Simultaneously, the bill status record has cross-step reference attributes between main steps, and can be passively referenced in the atomic settlement and dispute rollback of step S400 as path replay and archiving descriptions, without changing the execution order of single-transaction atomic settlement and balance snapshot writing.

[0109] S330. Select a settlement path and assemble parameters for the bill status record to generate a settlement execution instruction;

[0110] Specifically, the input source for this step is the bill status record output from step S320. The bill status record contains a bill object reference, consistency level, risk factor set, policy fields, and version information. The processing chain first involves the path selection unit selecting a settlement path based on the policy fields in the bill status record. The settlement path enumerates the direct settlement path, limit settlement path, delayed settlement path, and freeze review path in the corresponding policy library. The path selection unit reads the policy version number and effective range description from the policy field and performs version matching against the policy entries with the same name in the policy library. Version matching does not involve backtracking or default inference. If the versions do not match, the bill status record is labeled with a policy version anomaly during the path selection stage, and a freeze review path is selected. For the direct settlement path, the path selection unit writes the path identifier into the path selection result; for the limit settlement path, the path selection unit reads the policy parameter references related to the limit; for the delayed settlement path, the path selection unit reads the policy parameter references related to the delay; for the freeze review path, the path selection unit records the freeze reason and review entry reference. After path selection is completed, the parameter assembly stage begins. This stage is performed by the parameter assembly unit, which retrieves the necessary execution parameters from the parameter library based on the path selection results. The parameter library, maintained by the parameter registration subunit, includes payment asset identifiers, receiving asset identifiers, deduction granularity, path limits, delay windows, freeze flag fields, handling fee configurations, deposit configurations, and session constraint items. The parameter assembly unit aligns the retrieved parameters by field and binds them to version numbers. It then combines the parameter entries with bill object references and session numbers to generate execution parameter groups. These execution parameter groups do not contain plaintext readings or valuation intermediates; they consist only of structured references and parameter entries generated during the reconciliation and strategy mapping stages.

[0111] Furthermore, instruction generation is performed by the instruction generation unit. Based on the execution parameter set, the instruction generation unit combines the field order description and mirror version number reference in the bill object to generate a settlement execution instruction. The settlement execution instruction is a structured instruction set for smart contracts to call, containing fields such as path identifier, execution parameters, bill object reference, session number, version number reference, and time scale description. The instruction generation unit performs a consistency self-check on the settlement execution instruction. The consistency self-check checks whether the path identifier and strategy field are consistent, whether the execution parameters are complete, and whether the version number reference exists. The check result is written to the instruction verification tag. If there are missing parameters or the version number reference is not in the effective range, the instruction generation unit writes an exception description at the instruction verification tag and sets the path identifier to a frozen review path, without stopping instruction generation or outputting an estimate. After generation, the settlement execution instruction enters the persistent output stage. The persistent output stage writes the output time scale and output channel identifier into the settlement execution instruction and establishes a strong association mapping with the session number, facilitating direct reference in step S410. To enhance the seamlessness of cross-step execution, the instruction generation unit includes references to bill status records and strategy entries in the settlement execution instruction. These references exist only as descriptive fields and do not affect the smart contract's access to core fields. The settlement execution instruction is explicitly recorded as an output field name at the end of the segment, and its subsequent input position is clearly defined in the statement as an input item for step S410, used for single-transaction atomic settlement and balance snapshot writing. It can also be passively referenced as a source description in the voucher generation and session archiving in step S420, without altering the voucher generation process. In summary, the technical effect of this step is: by path-based decomposition and parameter-based reorganization of the bill status record, a structured settlement execution instruction is constructed, enabling path selection, parameter assembly, and instruction generation to form a continuous link under the session number and version reference, providing directly usable instruction inputs and traceable parameter sources for the subsequent execution of single-transaction atomic settlement.

[0112] Step S400 includes at least steps S410-S430:

[0113] S410: Obtain the settlement execution instruction and bill object, perform single-transaction atomic settlement and balance snapshot writing, and obtain the settlement transaction receipt;

[0114] Specifically, the input sources for this step are the settlement execution instruction output in step S330 and the bill object output in step S310. A one-to-one correspondence is established between the two through session number and bill object reference. The settlement execution instruction is a structured instruction set for smart contract calls, containing fields such as path identifier, execution parameters, bill object reference, session number, version number reference, and time scale description. The bill object is a structured object containing a field set, version reference, commitment fingerprint reference, verification status, and session number. The processing chain first involves the instruction receiving unit performing an entry verification of the settlement execution instruction. The entry verification checks whether the path identifier is within the effective range under the current session's policy version number, whether the execution parameters have required fields such as payment asset identifier, receiving asset identifier, deduction granularity, path limit, delay window, or freeze flag, and whether the bill object reference exists and matches the session number. For cases with missing fields or mismatched effective ranges, the entry verification does not make a default inference; instead, it directly adds an instruction verification tag to the settlement execution instruction and sets the path identifier to a frozen verification path, still proceeding to the subsequent transaction orchestration stage. Subsequently, the transaction orchestration unit assembles transactions based on path identifiers. Under the direct settlement path, the unit assembles deduction, receipt, balance update, and bill fingerprint writing operations. Under the limited settlement path, it assembles limited deduction sub-operations and registers uncovered balances as pending amounts. Under the delayed settlement path, it records delay windows and assembles delayed commit sub-operations. Under the frozen review path, it suspends deductions and receipts and only registers a freeze flag. The assembly order of each sub-operation is fixed within the same transaction and identified by both the session number and transaction sequence number. To ensure that deductions, receipts, and balance updates are inseparable across multiple accounts, the transaction orchestration unit adopts a single-transaction atomic settlement orchestration method, executing each sub-operation within the same on-chain transaction. The transaction includes bill object field references and version number references, and the path identifier and session number are written in the on-chain transaction header for easy archiving later.

[0115] Furthermore, after the transaction orchestration is completed, the execution engine unit initiates a smart contract call. The smart contract reads the path identifier and execution parameters from the settlement execution instruction and executes the corresponding sub-operations in the orchestration order. In the deduction operation, the smart contract performs standardized verification of the payment asset identifier and deduction granularity, and registers the deduction record when it meets the path limit. In the collection operation, the smart contract performs same-field verification on the collection asset identifier and registers the collection record. In the balance update operation, the smart contract locates the account status of both parties based on the primary key field in the bill object field set, calculates the difference between the old and new balances, and writes it to the balance snapshot. In the bill fingerprint writing operation, the smart contract writes the commitment fingerprint reference and version number reference in the bill object into the voucher field, and leaves the block height placeholder field to be filled by the on-chain return value after submission. To ensure the consistency of actions within the same transaction, the execution engine unit writes the execution time scale at the beginning of the transaction execution and the commit time scale at the end of the transaction execution, and records the execution time scale and commit time scale together in the transaction context. The execution engine unit classifies and labels exceptions during execution: For business-related exceptions such as insufficient balance, path limit restrictions, or delayed window not yet expired, it records the business-related exception label and branches according to path rules; for systemic exceptions such as contract call failure, restricted permissions, or network interruption, it records the systemic exception label and suspends the transaction within the current session, with the transaction replay unit triggering subsequent replay. The transaction replay unit only records the replay entry point and replay conditions, without directly modifying the transaction content. After the transaction is executed, the commit return value is recorded in the receipt construction unit. The receipt construction unit compiles the deduction record, receipt record, balance snapshot, and session number to form a settlement transaction receipt draft; for cases with delayed submission or limits not covering the amount, the receipt construction unit adds pending amount labels and delayed submission labels to the receipt draft, and writes these two types of labels along with the path identifier into the receipt's supplementary fields.

[0116] Understandably, after the receipt construction unit is assembled, it enters the receipt output stage. In the output stage, the deduction record, receipt record, balance snapshot, session number, and transaction hash are assembled into a settlement transaction receipt. The block height reference placeholder field is left blank, to be filled in by subsequent steps based on the actual on-chain height. The settlement transaction receipt is explicitly recorded as an output field name, and its subsequent input position is clearly stated at the end of this section as an input item for step S420, used to generate on-chain settlement vouchers and complete session archiving. Simultaneously, the settlement transaction receipt has cross-main-step reference attributes, and can be passively referenced as an execution credential description in the bill object generation and status replay stage of step S300, without changing the generation order and value rules of the bill object fields.

[0117] In one embodiment, S410, the settlement execution instruction and the bill object are obtained, a single-transaction atomic settlement and balance snapshot writing are performed, and a settlement transaction receipt is obtained.

[0118] The input sources for this step are the settlement execution instruction output in step S330 and the bill object output in step S310. A one-to-one correspondence is established between the two through a session number and a bill object reference. The settlement execution instruction is a structured instruction set for smart contract calls, containing fields such as path identifier, execution parameters, bill object reference, session number, version number reference, and time scale description. The bill object is a structured object containing a field set, version reference, commitment fingerprint reference, verification status, and session number. The processing chain first involves the instruction receiving unit performing an entry verification of the settlement execution instruction. The entry verification checks whether the path identifier is within the effective range under the current session's policy version number, whether the execution parameters have required fields such as payment asset identifier, receiving asset identifier, deduction granularity, path limit, delay window, or freeze flag, and whether the bill object reference exists and matches the session number. During the verification process, for cases with missing fields or mismatched effective ranges, no default inference is made; instead, an instruction verification tag is directly added to the settlement execution instruction.

[0119] Formula ⑦ is used to calculate the pass index of the entry verification. It is based on the validity of the version number reference, the completeness of the execution parameters, and the session consistency check results, and uses a multiplication form to integrate multiple constraints.

[0120]

[0121] in: The version number reference validity index is derived from the comparison between the version number reference in the settlement execution instruction and the effective range in the strategy library. The value range is {0,1}, where 1 indicates validity. This indicator represents the completeness of execution parameters. It is derived from the existence check of necessary items such as payment asset identifier, receiving asset identifier, deduction granularity, path limit, delay window, and freeze flag field in the settlement execution instruction. The value range is {0,1}, where 1 indicates completeness. This represents the session consistency metric, derived from the consistency check between the billing object reference and the session number. Its value range is {0,1}, where 1 indicates consistency. This indicates that the overall verification has passed, and its value range is {0,1}. The version number is extracted from the settlement execution instruction and recorded as... The completeness of the execution parameters is extracted from the settlement execution instruction and recorded as follows: Session consistency is extracted from the billing object and recorded as The three together form the formula in ⑦. Formula ⑦ As an input item for formula ⑧.

[0122] Formula ⑧ is used to adjust the path identifier. Based on the verification pass index, it determines whether to overwrite the path identifier as the frozen review path. The path switching is achieved using a conditional expression.

[0123] in: The output is derived from formula ⑦ and has a range of {0,1}. This represents the original path identifier, which comes from the path identifier field in the settlement execution instruction. Its value range is an enumeration type {direct, limit, delay, freeze}. This represents the adjusted path identifier, with a value range of the enumeration type {direct, limit, delay, freeze}.

[0124] Obtained from formula ⑦ Path identifier in settlement execution instruction Together they form the formula in ⑧ Formula ⑧ As an input item in the transaction orchestration step of this process, it is used to generate the operation sequence of formula ⑨ in the subsequent process.

[0125] The output of this section is the adjusted path identifier. With verification and approval indicators These fields are used as inputs by the transaction orchestration unit of this main step for sub-operation assembly and sequence generation.

[0126] Following the aforementioned adjusted path identifiers With verification indicators Entering the transaction orchestration phase, the transaction orchestration unit is based on Sub-operations are assembled, including deduction, receipt, balance update, and bill fingerprint writing. For frozen review paths, only a freeze flag is registered. The assembly order of each sub-operation is fixed within the same transaction, identified by both the session number and the transaction sequence number. Transaction orchestration employs the resource conflict constraint principle from operations research to ensure mutual exclusion checks between sub-operation resource requirements and account status, avoiding concurrent conflicts.

[0127] Formula 9 is used to generate sub-operation sequences, which are mapped to predefined operation encoding sequences based on the adjusted path identifiers, and the path-type operation sequence allocation is achieved using an indicator function.

[0128]

[0129] in: The output is derived from formula ⑧, and its value range is an enumeration type {direct, limit, delay, freeze}. This represents a sequence of sub-operations, with a value range of an integer vector, where 1 represents a deduction operation, 2 represents a receipt operation, 3 represents a balance update operation, 4 represents a bill fingerprint write operation, and 5 represents a freeze operation; the mapping relationship is based on a predefined path type. This is obtained from formula ⑧. Directly form the formula in ⑨ Formula 9 As an input to formula ⑩, it is used for the balance snapshot calculation.

[0130] Formula 10 is used to calculate the actual deduction amount and balance snapshot. The actual deduction amount is determined based on path identifier and limit constraint, and the balance is updated by applying the flow balancing principle. The resource allocation model in linear programming is used to ensure that the amount is non-negative and the constraints are satisfied.

[0131] in: The output is derived from formula ⑧, and its value range is an enumeration type. This indicates the deduction granularity, which is derived from the execution parameters in the settlement execution instruction, and its value range is non-negative real numbers; This represents the path limit, which originates from the execution parameters in the settlement execution instruction, and its value range is non-negative real numbers. This represents the actual amount deducted, and its value range is non-negative real numbers. This represents the current payer's balance, derived from a set of fields in the bill object, and its value range is non-negative real numbers. This represents the current payee balance, derived from a set of fields in the bill object, and its value range is non-negative real numbers. This represents the updated payer balance, and its value range is non-negative real numbers; This represents the updated balance of the payee, and its value range is non-negative real numbers.

[0132] Obtained from Formula ⑧ With the settlement execution instruction and Joint calculation Then from the bill object and This forms the new balance in formula ⑩. Formula ⑩'s... and As an input item for formula ⑪.

[0133] The output of this section is a sequence of suboperations. With balance snapshot , These fields are used as input items by the receipt building unit of this main step for the generation of settlement transaction receipts.

[0134] Following the aforementioned sub-operation sequence With balance snapshot , The process then moves to the receipt construction stage. The receipt construction unit compiles the deduction records, receipt records, balance snapshots, and session numbers to form a draft settlement transaction receipt. For cases with delayed submissions or amounts not covered by the limit, pending amount tags and delayed submission tags are added. Receipt construction uses a hash function to ensure data integrity and generates tags based on anomaly classification rules. Formula 11 is used to generate the hash value of the settlement transaction receipt. A hash digest is calculated based on the session number, execution time scale, path identifier, actual deduction amount, and new balance. A cryptographic hash function is used to prevent tampering.

[0135]

[0136] in: This represents the session number, which is derived from the session number field in the settlement execution instruction. This indicates the execution time scale, which is derived from the time scale description field in the settlement execution instruction, and its value range is the timestamp value. The output is derived from formula ⑧, and its value range is an enumeration type. Derived from the output of formula ⑩; and Derived from the output of formula ⑩; Represents a hash function (such as SHA-256); This represents the receipt hash value, and its value range is a fixed-length string.

[0137] Obtained from Formula ⑧ Formula 10 yields , , With the settlement execution instruction , Together they form the formula in ⑪ Formula 11 As an input item for formula ⑫.

[0138] Formula 12 is used to generate abnormal tags and receipt structures. It calculates the pending amount, delayed submission and frozen tags based on path identifiers and deduction parameters, and assembles receipt vectors. It uses the scheduling result mapping principle in operations research to realize tag association.

[0139] in: The output is derived from formula ⑧, and its value range is an enumeration type. Derived from the deduction granularity in the settlement execution instruction; The path limit originates from the settlement execution instruction; This represents the quota tag to be processed, and its value range is non-negative real numbers; This indicates a delayed submission tag, with a value range of {0,1}; This indicates a freeze label, with a value range of {0,1}; Indicates an indicator function; Derived from the output of formula ⑪; This represents the settlement transaction receipt vector, with a value range of tuples.

[0140] Obtained from Formula ⑧ With the settlement execution instruction , Calculate the labels together, then combine them with formula 11. Forming formula ⑫ Formula 12 This is the output of this step.

[0141] The output of this section is a settlement transaction receipt. The receipt is used as an input item in step S420 to generate on-chain settlement vouchers and complete session archiving; at the same time, the settlement transaction receipt has cross-main step reference attributes and can be passively referenced as an execution credential description in the bill object generation and status replay stage of step S300.

[0142] This section summarizes the technical effects: strict settlement triggering conditions are ensured through entry verification and path adjustment; atomic operations are achieved through transaction orchestration and balance snapshot calculation; and verifiable receipts are generated based on hash functions and exception tags, forming a closed-loop auditable link from instruction to receipt.

[0143] S420. Extract the block height reference and bill fingerprint from the settlement transaction receipt, perform voucher generation and session archiving, and generate on-chain settlement vouchers.

[0144] Specifically, the input source for this step is the settlement transaction receipt output in step S410. The settlement transaction receipt includes deduction records, receipt records, balance snapshots, session numbers, transaction hashes, and block height reference placeholder fields. The processing chain is initiated by the voucher generation unit. The voucher generation unit first retrieves the actual block height and transaction index from the on-chain query module based on the transaction hash, and writes the retrieval results into the block height reference field and transaction index field. Then, it extracts the bill fingerprint field and version number reference field from the settlement transaction receipt, verifies whether the bill fingerprint field is consistent with the commitment fingerprint reference in the bill object in step S310, and verifies whether the version number reference field is consistent with the version number reference in the version mirror binding record in step S120. For inconsistent scenarios, no default repair is performed; only an inconsistency tag is recorded during the voucher generation process, and the voucher text continues to be generated. The voucher body is constructed by the voucher assembly unit. The voucher assembly unit describes the voucher fields in the order of predefined voucher fields, and writes the block height reference, transaction hash, transaction index, bill fingerprint, version number reference, deduction record, payment record and balance snapshot into the voucher body area, and writes the session number, path identifier and instruction verification label into the voucher header area. For receipts with delayed submission label and pending amount label, the voucher assembly unit writes pending description and delay description in the voucher notes area, which are used as known status records when the session is archived in the future.

[0145] Furthermore, session archiving is performed by the archiving unit. The archiving unit creates archived records according to the session number. These records store the full text of the document header, document body, and document notes areas, and establish indexes using block height references and transaction hashes. These indexes are used to directly locate the corresponding document during cross-session retrieval. The archiving unit annotates the access strategy for archived records, specifying the readable scope and retention period, and writes the archiving time scale and archiving channel identifier into the archived record header. For receipts with systemic anomaly tags, the archiving unit includes an anomaly description and marks the review entry point in the archived record. The review entry point provides location information for subsequent dispute resolution without altering the static content of the archived record. To maintain seamless cross-master step connections, the archiving unit generates an archived summary during the archiving process. The archived summary contains four core fields: session number, block height reference, transaction hash, and bill fingerprint. The archived summary can be passively referenced as an execution source description in the bill status replay step S300 without changing the field order of the bill status record. After archiving is completed, the voucher generation unit enters the voucher output stage. In the output stage, the voucher body area and the index information in the voucher header area are packaged into an on-chain settlement voucher, and a reference relationship is established between the on-chain settlement voucher and the archived summary. The on-chain settlement voucher, as the output product of this step, is explicitly recorded as the output field name. At the end of this section, it is specified that its subsequent input position is the input item of step S430, which is used to perform abnormal appeal detection and freeze suspension processing.

[0146] Understandably, after the generation of on-chain settlement vouchers and session archiving are completed, the voucher output stage writes the voucher output time scale and output channel identifier into the voucher header. The output channel identifier is used to quickly retrieve the corresponding session and block height in subsequent dispute resolution stages. For vouchers with inconsistent tags or abnormal descriptions, the voucher output stage does not overwrite them; instead, it retains the information only in the voucher notes area for subsequent processing units to read. On-chain settlement vouchers have read-only reference attributes across main steps and can be passively referenced in the source description of step S200 or the state replay of step S300 without changing the generation order of the peer verification package and billing status record.

[0147] S430. Perform abnormal appeal detection and freeze / suspend processing on the on-chain settlement voucher, and generate disputed vouchers and review list;

[0148] Specifically, the input source for this step is the on-chain settlement certificate output in step S420. This on-chain settlement certificate includes a certificate header area, a certificate body area, a certificate notes area, and an archived summary reference. The processing chain is initiated by the appeal detection unit. The appeal detection unit reads the inconsistency tag, exception description, pending amount tag, and delay description from the certificate notes area, and locates the issue by combining this information with the block height reference, transaction hash, and session number in the archived summary. Simultaneously, the appeal detection unit monitors dispute applications from external appeal portals. These external appeal portals record fields such as the appellant's identifier, appeal time scale, appeal reason category, and associated session number. For exceptions triggered by internal tags and exceptions submitted through external appeal portals, the appeal detection unit uniformly generates an appeal event record. This appeal event record does not change any fields of the on-chain settlement certificate; it only serves as input for subsequent freeze suspension and review orchestration. The process then proceeds to freeze / suspend, executed by the freezing unit. The freezing unit selects the freeze scope based on the cause category in the appeal event record and the path identifier in the on-chain settlement certificate. The freeze scope may include the pending release amount, delayed submission amount, or pending settlement amount related to the billing object pointed to by the certificate for both accounts in the transaction pair within that session. The freezing unit writes a freeze flag field upon freezing and records the freeze time scale and freeze reason in the freeze record. The freeze record establishes a mapping relationship with the session number, block height reference, and transaction hash. For freezes caused by systemic anomaly tags, the freezing unit additionally registers a systemic anomaly description for priority arrangement in subsequent review list compilation.

[0149] Furthermore, the review and orchestration are executed by the review unit. The review unit aggregates appeal event records and freeze records within the same session according to the session number, forming a review task set. The review task set is a structured task list, containing fields such as the voucher reference being reviewed, the bill object reference being reviewed, the version number reference involved, the source status marker, the time scale record, and the freeze range description. The review unit extracts the required comparison materials from the review task set. The comparison materials include the field comparison list from step S220 and the reference items of the bill consistency proof package from step S230. The review unit only performs pointer verification and index positioning on the reference items, without re-judging. In cases where source playback is required, the review unit records the playback entry and playback conditions on the session playback interface. The session playback interface generates a playback list in the background. The playback list does not change any historical records and is only used to verify the field order and path selection at that time. After collecting the materials, the review unit enters the list output stage. In the list output stage, the review task set and material reference items are compiled into a review list. The review list writes the list number, list generation time scale and list channel identifier in the header of each item, and writes the freeze mark field and freeze reason of the frozen record into the list notes area. At the same time, the list output stage writes the suggested processing path for unfreezing or maintaining the freeze into the processing suggestion area. The suggested processing path is only used as a reference in subsequent sessions and will not be automatically executed in this step.

[0150] Understandably, the dispute certificate is generated by the dispute certificate assembly unit. This unit combines the certificate body area of ​​the on-chain settlement certificate with the appeal event record, freeze record, and review list number to generate a structured dispute certificate that can be read by external arbitration or internal audit. The dispute certificate includes a session number, block height reference, and transaction hash in its header for easy cross-session and cross-block retrieval. The dispute certificate and review list are explicitly recorded as output field names at the end of this section, and their subsequent input positions are clearly defined in the statement as the input entry point for step S120. This serves as the review entry point for the version mirror binding record and the basis for revising the strategy library, forming a closed loop from dispute processing back to version mirror binding and caliber management. Simultaneously, the dispute certificate and review list possess cross-main-step reference attributes and can be passively referenced by the caliber consistency check in step S200 and the risk stratification strategy mapping in step S300. This allows them to explain the source status and path selection in subsequent sessions without altering the settlement transaction receipts and on-chain settlement certificates already completed in the current session.

[0151] In summary, the technical effects of this step are as follows: By completing deduction, receipt, balance update, and bill fingerprint registration within the same transaction, and conducting anomaly appeal detection and freeze / suspend processing after subsequent voucher generation and session archiving, receipts, vouchers, and disputed materials form a continuous submission link under the reference of session number and block height, supporting subsequent backflow review and reconfiguration of standards and strategies.

Claims

1. A blockchain settlement method for smart meter data, characterized in that, include: Acquire smart meters with safety elements, reading frames, and device signatures; register time anchors based on session IDs, including recording occurrence time, reception time, and registration time; perform term registration and definition, including establishing unique spelling entries and semantic descriptions for keywords; use version selectors and validity checkers to perform rate version mirror binding and apportionment table version mirror binding; and perform index key construction and commitment registration processing based on meter identifiers, time windows, and meter reading rounds to generate a minimal index key structure. Based on the minimum index key structure, source signature verification is performed using the key registration list and certificate registration list. Consistency checks are performed based on the rate version mirror and the allocation table version mirror. Time anchors are compared with rate versions and allocation ratios with dimensional standards. Consistency judgment and evidence encapsulation operations are performed using rule registration sub-units to generate bill consistency proof packages. Based on the bill consistency proof package, the same window details are aggregated using the primary key merging strategy, fields are compiled according to the predefined field mapping table, and risk stratification strategy mapping, settlement path selection and parameter assembly are performed using the rule registration sub-unit and strategy mapping unit to generate settlement execution instructions. Based on the settlement execution instruction, the instruction acceptance unit and transaction orchestration unit are used to perform single-transaction atomic settlement, including deduction operation, collection operation, balance update operation and bill fingerprint writing operation, balance snapshot writing, voucher generation using voucher generation unit, session archiving, anomaly appeal detection and freeze suspension operation, and generate dispute vouchers and review list.

2. The method according to claim 1, characterized in that, Smart meters with security elements, reading frames, and device signatures include: The smart meter with security element refers to an energy metering device with a built-in security element and local signature capability. The security element is used to complete the reading frame signing and key control on the device side. The reading frame includes meter identification, channel number, sampling time, meter reading round and channel status. The device signature refers to the local signature result of the smart meter with security element on the current reading frame and its ancillary fields.

3. The method according to claim 1, characterized in that, The rule registration sub-unit includes: The rule registration sub-unit includes rules for judging the order of time anchors, rules for matching rate versions, rules for matching apportionment ratios, rules for judging the consistency of units, and rules for prioritizing source status.

4. The method according to claim 1, characterized in that, The process of generating vouchers using the voucher generation unit includes: The processing chain is initiated by the credential generation unit. The credential generation unit first retrieves the actual block height and transaction index from the on-chain query module based on the transaction hash, and writes the retrieval results into the block height reference field and the transaction index field.

5. The method according to claim 1, characterized in that, The process of performing consistency checks based on the rate version mirror and the allocation table version mirror, comparing the time anchor with the rate version and the allocation ratio with the dimensional caliber, and using the rule registration sub-unit to perform consistency judgment and evidence encapsulation operations also includes: The field lookup list is matched with the peer verification package by session number and primary key field. If a primary key is found to have only a commitment fingerprint reference or only a digest reference during the matching process, the judgment unit does not perform inference merging, but only writes a missing tag on the primary key entry and retains the entry for subsequent judgment. Entering the consistency rule matching stage, the consistency rule set is maintained by the rule registration sub-unit. The rules maintained by the rule registration sub-unit include the time anchor chronology judgment rule, rate version matching rule, apportionment ratio matching rule, unit consistency judgment rule and source status priority rule. The three types of labels and source status markers for each record in the field comparison list are substituted into the corresponding rules for judgment. The judgment results are not recorded as pass rate or score, but are only applied to the corresponding fields in the form of pass label, difference label and conflict label, and the entry judgment results are formed at the entry level.

6. The method according to claim 1, characterized in that, The process of consistency assessment and evidence encapsulation also includes: Evidence encapsulation is performed by the encapsulation unit, which aggregates the judgment results of entries with the same primary key according to the session number, along with the corresponding commitment fingerprint reference and digest reference, to generate traceable proof entries; The proof entry contains field-level judgment labels, source status markers, time scale records, and mirror version number references. The proof entry does not contain plaintext readings or intermediate calculation quantities. The encapsulation unit assigns an entry number to each proof entry and establishes a mapping relationship with the session number. During the encapsulation process, it records the encapsulation time and encapsulation channel, and writes the rule version number used for judgment into the entry header. After encapsulation, the process moves to the packaging and output stage. In this stage, the proof entries are serialized in primary key order to form a bill consistency proof package.

7. The method according to claim 1, characterized in that, Based on the settlement execution instruction, the process of performing single-transaction atomic settlement and balance snapshot writing, which includes deduction operation, collection operation, balance update operation and bill fingerprint writing operation, using the instruction acceptance unit and transaction orchestration unit, also includes: Perform entry verification, which verifies whether the path identifier is within the effective range under the current session's policy version number, whether the execution parameters have the required items, and whether the bill object reference exists and is consistent with the session number; In cases where fields are missing or the effective range does not match, the entry verification does not make a default inference. Instead, an instruction verification label is added to the settlement execution instruction and the path identifier is set to the frozen review path. The process will still proceed to the subsequent transaction orchestration stage. The transaction orchestration unit assembles transactions based on path identifiers. Under the direct settlement path, it assembles deduction operations, collection operations, balance update operations, and bill fingerprint writing operations. Under the limit settlement path, it assembles limit deduction sub-operations and registers the uncovered balance as pending amount. Under the delayed settlement path, it records the delay window and assembles the delayed commit sub-operation. Under the freeze review path, it suspends deduction and collection and only registers the freeze flag. They are fixed in the same transaction and are identified by both the session number and the transaction sequence number.

8. The method according to claim 1, characterized in that, The process of using the instruction acceptance unit and the transaction orchestration unit also includes: The transaction orchestration unit adopts a single-transaction atomic settlement orchestration method, which incorporates each sub-operation into the same on-chain transaction for execution. The transaction includes references to bill object fields and version numbers, and the path identifier and session number are written in the on-chain transaction header.

9. The method according to claim 7, characterized in that, After the transaction orchestration is completed, the execution engine unit initiates a smart contract call. The smart contract reads the path identifier and execution parameters in the settlement execution instruction and executes the corresponding sub-operations in the orchestration order. During the deduction operation, the smart contract standardizes and verifies the payment asset identification and deduction granularity, and registers the deduction record when it meets the path limit; During the payment collection process, the smart contract verifies the identity of the asset to be collected against the same field and records the payment collection. In the balance update operation, the smart contract locates the account status of both parties based on the primary key field in the bill object field set, calculates the difference between the old and new balances, and writes it into the balance snapshot. In the bill fingerprint writing operation, the smart contract writes the commitment fingerprint reference and version number reference from the bill object into the credential field, and leaves the block height placeholder field to be filled by the on-chain return value after submission.

10. The method according to claim 9, characterized in that, The execution engine unit writes the execution time scale at the beginning of the transaction execution and the commit time scale at the end of the transaction execution, and records the execution time scale and the commit time scale together in the transaction context; The execution engine unit classifies and labels exceptions during execution: when a business exception occurs, it records the business exception label and branches according to the path rules; When a systemic anomaly occurs, the systemic anomaly label is recorded, and the transaction is suspended within the current session, with subsequent replays triggered by the transaction replay unit.

Images