Power market financial risk block chain monitoring method

Abstract

The invention relates to commercial data processing and management in the technical field of computers, in particular to an electricity market financial risk block chain monitoring method. The method comprises the steps of obtaining market clearing price, time-sharing matching, account position increment, margin occupation, cross-market linkage factors and supervision announcement metadata, performing naming specification, source signature binding and double-clock alignment, and minimizing fields to form verifiable input; constructing an index lattice based on a multi-dimensional base, assembling a scene template in combination with a sliding window sequence and policy key points, and completing fragment packaging and source pointer registration; fragment hash and time anchor serialization are executed on the chain, and the chain is solidified into a risk evidence chain through witness committee threshold check; and the contract engine generates a mark-leaving report and a visual board according to the threshold value, the change rate and the persistent trigger disposal script. According to the method, traceability and auditing links are enhanced, clock consistency and data aperture unification are optimized, the exposure range is reduced, and the early warning disposal collaboration and supervision adaptation degree is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer technology, and particularly relates to a power market financial risk blockchain monitoring method. BACKGROUND

[0002] In the field of computer technology, the existing scheme of power market financial risk monitoring generally constructs a risk engine around a matching system, a clearing system and an account / margin system, gathers market clearing prices, time-sharing transaction matching records, account position increments and cross-market linkage factors, and combines a rule library to complete early warning and report output on a centralized platform. However, there are limitations such as scattered data and untraceable sources, difficulty in aligning market clock / settlement clock, insufficient field caliber, high coupling degree of early warning triggering and disposal execution, and incomplete traceability link. The existing method relies on a single threshold or a fixed template, and in the scenario where batch clearing and asynchronous announcement coexist, it is difficult to meet the stable implementation of the three-dimensional trigger rule judgment and disposal script matching execution. For the joint processing of disposal script matching execution based on index slice package and risk evidence chain under the alignment of market clock / settlement clock, the existing technology generally has common shortcomings such as field minimization exposure, source pointer registration, slice hash and time anchor serialization, witness committee majority signature threshold review, solidification writing and pointer registration, report traceability and board rendering, which cannot form a consistent process of collection-alignment-judgment-execution-traceability in the application scenario of power market financial risk monitoring, resulting in the deficiencies of weak correlation between hierarchical early warning events and compliance traceability reports, high difficulty in review and audit, and weak correlation between visual board structure. SUMMARY

[0003] To solve the above technical problems, the present application provides a power market financial risk blockchain monitoring method, comprising:

[0004] Market clearing prices, time-sharing transaction matching records, account position increments, margin occupation, cross-market linkage factors and regulatory announcement metadata are obtained, and naming standard conversion and source signature binding processing are performed through a unified adaptation component, and double clock alignment and field screening processing are performed to generate a minimum verifiable input set structure;

[0005] Based on the minimum verifiable input set structure, five-dimensional base definition and index lattice construction are performed to generate hierarchical risk index clusters, scenario template assembly is performed to generate scenario labels, and based on the hierarchical risk index clusters and scenario labels, slice packaging and source pointer registration processing are performed to generate an index slice package;

[0006] The acquisition index slice package is subjected to slice hash and time anchor serialization processing to generate an on-chain evidence buffer entry, a witness request is extracted from the on-chain evidence buffer entry to perform a witness committee multi-signature threshold check to generate a risk evidence chain candidate, and solidification writing processing is performed to generate a risk evidence chain.

[0007] Based on the risk evidence chain, three-dimensional trigger rule judgment, disposition script matching and execution calling, and report leaving traces and board rendering processing are performed to generate compliance leaving trace reports and visual board structures.

[0008] Further, the market clearing price, the intraday trading matching record, the account position increment, the margin occupation, the cross-market linkage factor and the regulatory announcement metadata include:

[0009] The market clearing price refers to a single or multi-variety price sequence generated by the matching and clearing mechanism within a predetermined settlement period; the intraday trading matching record refers to the time label, the direction of declaration, the declared quantity and the traded quantity of each matching event; the account position increment refers to the difference record of the change of account position between adjacent time slices; the margin occupation refers to the balance and its change entry of the margin freeze and release of the account or the contract; the cross-market linkage factor refers to the measurable price difference, trading activity or trading proportion between cross-commodity and derivative products, cross-regional and cross-variety; the regulatory announcement metadata refers to the announcement title, announcement time, applicable scope, number index and associated rule points published by the regulatory platform or market operator.

[0010] Further, the minimum verifiable input set structure includes:

[0011] The minimum verifiable input set structure contains a matching window view, a settlement batch view and an announcement mounting view, a source pointer and a time scope identifier.

[0012] Further, the process of performing slice packaging and source pointer registration to generate the index slice package includes:

[0013] Taking the scenario label as the main line of slice demarcation, the corresponding time slice interval and account period interval are retrieved in the hierarchical risk index cluster according to the coverage range of each scenario label to form a slice candidate;

[0014] The source pointer of each slice candidate is collected, the source pointer is extracted from all node metadata contained in the candidate, and the source pointer is de-duplicated and sorted, and the sorting result is written to the source pointer table of the slice candidate;

[0015] The version numbers are merged to confirm the consistency of the version numbers of the slice candidate within the coverage range, and the inconsistent version numbers are recorded as version divergence entries;

[0016] The slice encapsulation is performed, the node set of the slice candidate, the source pointer table, the boundary version index, the boundary identification, and the template version number are uniformly encoded into an encapsulation record, and the encapsulation record is subjected to minimum verifiability checking;

[0017] The source pointer registration is performed on the encapsulation record, the source pointer table in the encapsulation record is bound to the index service of the permission chain to form a source index pointer;

[0018] The encapsulation record is serialized, and the serialization result, the coverage range of the scenario label, the template version number, and the account period information jointly constitute an index slice package.

[0019] Further, the ordering rule gives priority to the access time sequence and the permission chain node identification sequence.

[0020] Further, the minimum verifiability checking includes: checking whether the source pointer is complete, whether the node set is missing the label and the boundary identification, whether the template version number is valid, and whether the coverage range is consistent with the double-clock mapping.

[0021] Further, for a slice candidate that has a node or version to be reviewed or a version discrepancy item, the encapsulation record adds the to-be-reviewed state and the discrepancy list in the annotation, and retains the problem position pointer in the reference field of the record.

[0022] Further, the process of extracting the witness request from the on-chain evidence buffer entry to perform the witness committee majority signature threshold check to generate the risk evidence chain candidate also includes:

[0023] The witness scheduler scans the on-chain evidence buffer entry, and filters the entries that can immediately enter the witness according to the alignment result of the witness expected window and the on-chain time label;

[0024] Each witnessable entry is decomposed into a witness request, and is broadcasted to the witness committee, the witness request includes a slice digest, a time anchor sequence, a source merge list, a template version number, a scope version number, and a boundary strategy identification, and a session number and a session time window are assigned to the request;

[0025] After receiving the witness request, the witness committee checks the source index pointer according to the source merge list, checks whether the slice digest matches the consistent field sequence of the source entry, and performs anchor validity checking on each anchor point in the time anchor sequence;

[0026] After collecting the witness response, the witness scheduler enters the majority signature threshold check, counts the number of signatures of the agree opinion and the refuse opinion according to the preset threshold strategy, and when the number of signatures of the agree opinion reaches the threshold strategy requirement, it is determined that the witness request is passed, and a risk evidence chain candidate is generated.

[0027] Furthermore, the threshold policy supports policy versions for different business groups. The policy version is provided by the on-chain parameter management contract. Before initiating a witness request, the witness scheduler reads the currently effective version from the parameter management contract and broadcasts it with the request.

[0028] Furthermore, for witness requests that fail the majority signature threshold verification, the system returns the entry to the on-chain evidence buffer and maintains its buffer key value unchanged, incrementing the failure count and rejection reason number in the entry notes. If the failure count exceeds the upper limit, it is marked as permanently shelved.

[0029] The key innovations of this invention include:

[0030] (1) Construct the minimum verifiable input set structure on the data side: Obtain the original data package from the market clearing price, time-sharing transaction matching records, account position increment, margin usage, cross-market linkage factors and regulatory announcement metadata, adopt naming conventions and source signature binding, and form the minimum verifiable input set structure that can directly participate in subsequent judgment and confirmation by aligning the market clock / settlement clock and minimizing field exposure and filtering the list of required fields.

[0031] (2) On the analysis side, the indicator lattice and scenario template are assembled and the indicator fragment package is output: the five-dimensional basis is obtained from the minimum verifiable input set structure and the indicator lattice is constructed. The scenario template is assembled and the tag is bound based on the sliding window sequence and the key points of the policy announcement. The hierarchical risk indicator cluster and the scenario tag are processed by fragment encapsulation and source pointer registration to generate the indicator fragment package for on-chain confirmation and trigger judgment.

[0032] (3) Establish a two-stage evidence confirmation and closed-loop triggering link on the chain side: perform sharding hashing and time anchor serialization from the indicator sharding package, enter the majority signature threshold verification of the witness committee and complete the solidification writing and pointer registration processing to generate the risk evidence chain; then obtain the trigger input from the risk evidence chain, complete the threshold-rate-persistence three-dimensional triggering rule judgment and disposal script matching execution, and form a compliance trace report and visual dashboard structure through report trace and dashboard rendering.

[0033] The following are its main beneficial effects:

[0034] (1) The technical effect of the acquisition-alignment-screening link is reflected in the fact that the minimum verifiable input set structure provides a unified caliber and traceable input for subsequent indicator lattice and sharding under the joint constraints of source signature binding and dual clock alignment of market clock / settlement clock, reducing the cumulative impact of data dispersion, inconsistent caliber and clock mismatch in risk monitoring, and is suitable for the power market scenario where matching and clearing operate in parallel.

[0035] (2) The technical effect of the organization-assembly-packaging link is reflected in the fact that the indicator lattice and scenario template assembly maps the sliding window sequence and policy announcement key points into the indicator fragment package that can be fragmented input, and maintains the stability of the traceability path through the source pointer registration, reducing repeated access to the full data, and facilitating subsequent witnessing and triggering judgment under the conditions of multi-scenario parallelism and caliber version switching.

[0036] (3) The technical effect of the closed loop of confirmation of rights, judgment, disposal and record keeping is reflected in the fact that the fragmented hash and time anchor serialization are combined with the majority signature threshold verification of the witness committee to generate the risk evidence chain, and then the threshold-rate-persistence three-dimensional trigger rule judgment and disposal script matching execution are performed. Finally, the report record keeping and Kanban rendering form an auditable output, connecting the evidence, triggering and disposal links, and improving the process consistency and verification availability under the conditions of multi-system docking and asynchronous receipt. Attached Figure Description

[0037] Figure 1 This is a flowchart illustrating a blockchain-based method for monitoring financial risks in the power market, as provided in an embodiment of this application. Detailed Implementation

[0038] Example 1: Refer to Figure 1 This is a flowchart illustrating a blockchain-based method for monitoring financial risks in the power market, provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0039] S100: Obtain market clearing price, intraday trading matching records, account position increment, margin usage, cross-market linkage factors and regulatory announcement metadata, perform naming standard conversion and source signature binding through a unified adaptation component, and perform dual clock alignment and field filtering to generate the minimum verifiable input set structure.

[0040] S200: Based on the minimum verifiable input set structure, five-dimensional basis definition and indicator lattice construction are performed to generate hierarchical risk indicator clusters. Scenario template assembly is performed to generate scenario labels. Based on the hierarchical risk indicator clusters and scenario labels, segmented encapsulation and source pointer registration are performed to generate indicator segment packages.

[0041] S300: Obtain the indicator shard package, perform shard hashing and time anchor serialization processing to generate on-chain evidence buffer entries, extract witness requests from on-chain evidence buffer entries, perform majority signature threshold verification of the witness committee to generate risk evidence chain candidates, and perform solidification writing processing to generate risk evidence chain.

[0042] S400, based on the risk evidence chain, performs three-dimensional trigger rule judgment, disposal script matching and execution call, and report recording and dashboard rendering processing to generate compliance recording reports and visual dashboard structures.

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

[0044] S110: Obtain market clearing price, intraday trading matching records, account position increment, margin usage, cross-market linkage factors and regulatory announcement metadata, perform naming standardization and source signature binding processing to obtain the original data package;

[0045] The input source for this section is the data access configuration and permission link entry list established during the previous architecture initialization phase. The data access configuration specifies the sampling frequency and field scope of the market clearing price, the sharding batches and time granularity of the time-sharing transaction matching records, the readable scope and field anonymization strategy of account position increment and margin usage, the source address and refresh rhythm of cross-market linkage factors, and the capture channel and announcement number mapping table for regulatory announcement metadata. The market clearing price refers to the price sequence of a single or multiple commodities generated by the matching and clearing mechanism within the agreed settlement period. The time-sharing transaction matching record refers to the detailed entries such as the time tag, order direction, order quantity, and transaction quantity of each matching event. The account position increment refers to the differential record of account position changes between adjacent time slices. The margin usage refers to the balance and changes of the frozen and released margin for an account or contract. The cross-market linkage factor refers to the input of indicators such as measurable price difference, trading activity, or trading ratio between spot and derivatives, and between regions and commodities. The regulatory announcement metadata refers to the structured summary of the announcement title, announcement time, scope of application, number index, and related rule points issued by the regulatory platform or market operator. Specifically, the aforementioned data sources are written to the acquisition buffer at the access end via a unified adaptation component. This component converts the original field names into standard field names defined by an internal naming convention. In this invention, the naming convention is a set of rules including field paths, dimensional descriptions, numerical ranges, and default policies. The purpose of this naming convention is to ensure that only standard field names are used and consistent dimensional interpretations are maintained when referencing fields in subsequent steps. Further, after data enters the acquisition buffer, the source signature binding process is invoked for each batch of entries. In this invention, source signature binding is defined as attaching a source identifier, access node identifier, and time tag to each batch of data entering the system, and generating a verifiable signature digest. The signature digest is signed by the permission chain member nodes and backfilled into the entry's extended fields, thereby establishing a verifiable source trajectory without changing the business fields. Understandably, the source signature binding process also records exception information such as access failures or missing fields. The exception information includes the exception type and the corresponding entry number, and, provided the exception does not affect the subsequent construction of the minimum verifiable input set, the entry is tagged with "to be completed" to proceed to the subsequent filtering stage. After the naming conventions and source signature binding are completed, the system triggers data aggregation, combining price and transaction entries in chronological order, merging account position increases and margin usage by account identifier, and aligning cross-market linkage factors and regulatory announcement metadata along the timeline to form a parallel sequence. The aggregated data is then encapsulated into a raw data package. In this invention, the raw data package is a batch encapsulation structure containing standard field names, source signature digests, anomaly tags, and a collection time range. This structure explicitly holds a list of fields and source pointers required for subsequent steps.The raw data packet, as the output of this section, is recorded as the output field name raw data packet and declared in the process to be used as input for the subsequent step S120. S120 reads the timestamp, source pointer, and standard field name set from the raw data packet and performs dual clock alignment and field specification unification processing. Through the above acquisition, standardization, and signature binding process, this section completes the aggregation from multi-source data to a unified encapsulation without changing the semantics of the data content, laying the foundation for input consistency for subsequent mapping and filtering.

[0046] S120. Extract the market clock and settlement clock from the original data packet, perform dual clock alignment and field standardization of the market clock / settlement clock, and generate a dual clock mapping table.

[0047] The input to this section is the raw data packet output by S110. In this invention, the market clock is defined as the time sequence of matching events, recording the timestamp and sequence number of each matching record. The settlement clock is defined as the time sequence of clearing batch generation and accounting updates, recording the start and end timestamps, corresponding accounting period, and batch number of each settlement batch. Because the market clock and settlement clock have different granularities and alignment boundaries, the settlement affiliation corresponding to the same matching event sequence may span different settlement batches. Therefore, this section needs to construct a mapping relationship so that subsequent indicator calculations can be performed both at the matching granularity and at the settlement batch granularity for accounting period aggregation. Specifically, the system first extracts all time-related fields from the raw data packet, including timestamps on price and transaction entries, accounting period timestamps on account position increments and margin usage, refresh timestamps on cross-market linkage factors, and announcement release timestamps on regulatory announcement metadata. Subsequently, the system converts the timestamps to a unified internal time zone based on a preset time benchmark, and then reconstructs the matching index according to the time sequence of the market clock. During the reconstruction process, a continuous sequence number and a corresponding matching window identifier are assigned to each matching event. Furthermore, the system extracts the start and end times and batch numbers of each batch from the settlement records to construct a settlement interval index. This index is an ordered set of non-overlapping time intervals, with each element recording the payment period, batch number, and reconcilable account identifier covered by that interval. After obtaining the two time systems, the system performs an attribution determination for each matching event. In this invention, attribution determination is defined as finding the settlement interval into which the event's time tag falls and recording the corresponding batch number. If an event's time tag falls within the overlapping sample of the two interval boundaries, the upper or lower bound is selected according to preset boundary rules, and a boundary marker is added to the entry so that subsequent indicator calculations are processed according to the boundary sample strategy. For regulatory announcement metadata, the system maps the announcement release time to a binary coordinate system of the market clock and the settlement clock, forming a dual-clock position for the announcement event. This allows subsequent scenario template assembly to simultaneously reference both the matching window and the settlement interval for status annotation. After completing the time mapping, the system continues to perform field standardization. In this invention, field standardization is defined as mapping fields with the same name or synonyms from different sources to a unified field interpretation and unit of measurement. For example, transaction volume is standardized to a specified unit, margin usage is standardized to the same currency and the same measurement caliber, and cross-market linkage factors are standardized according to a unified sampling interval and numerical range. Field standardization also includes strategies for handling missing and outlier values. Missing values ​​are tagged and the reason for their absence is recorded in this step. No valuation substitution is performed, allowing them to be removed or retained in the subsequent exposure minimization phase based on whether they are necessary fields.After completing the dual-clock mapping and field standardization, the system generates a dual-clock mapping table. In this invention, the dual-clock mapping table is a structured table containing mappings from matching events to settlement batches, from announcement events to binary clock positions, and pointers to field standard conversion rules. Each row in the structure corresponds to a matching sequence number or announcement number, including its corresponding settlement batch number, boundary identifier, standard version number, and source pointer. The dual-clock mapping table, as an output of this section, is recorded as the output field name "Dual-Clock Mapping Table" and is specified in the process as input for subsequent step S130. S130 will use the dual-clock mapping table to minimize field exposure and filter the list of necessary fields in the original data packet, thereby forming a minimum verifiable input set structure. Simultaneously, to accommodate cross-main step calling requirements, the dual-clock mapping table will also serve as a time reference in the subsequent assembly of indicator lattices and scenario templates. When reading the minimum verifiable input set structure, S210 will synchronously reference its time mapping rules to guide sliding window generation and billing period aggregation.

[0048] S130. Perform field minimization exposure and required field list filtering on the original data packet and the dual clock mapping table to generate a minimum verifiable input set structure.

[0049] The inputs to this section include the raw data packet output from S110 and the dual-clock mapping table output from S120. Minimizing field exposure in this invention is defined as retaining only necessary fields and desensitizing or replacing sensitive fields with source pointers, while meeting the requirements of subsequent indicator calculations, scenario template assembly, and on-chain evidence construction. This avoids exposing personal identifiers or account details unrelated to risk calculations to subsequent processes. To achieve this, the system first loads a list of required fields. In this invention, the list of required fields is a set of rules-driven fields. The rules are derived from the field dependency descriptions of the claims and embodiments for subsequent processing, including the price value and time label that must exist in the price time series, the matching direction and transaction quantity that must exist in the transaction records, the account category and position change that must exist in the account records, the amount and currency of frozen or released funds that must exist in the margin records, the indicator identifier and sampling value that must exist in the cross-market linkage factor, and the announcement number, publication time, and policy summary that must exist in the regulatory announcement metadata. Subsequently, the system reads entries in the dual-clock mapping table regarding time attribution and field caliber version, binding the time attribution and caliber version number to each category of required fields. This ensures that the source of the caliber can be traced in subsequent indicator calculations across both sliding window and billing period dimensions. During the field minimization process, the system desensitizes account identifiers and counterparty identifiers, replacing them with source pointers and hashed external reference numbers. Here, the source pointer is defined in this invention as a read-only index that can be parsed by authorized nodes in the permissioned chain to the original entry, without containing original account or counterparty information. This allows the source association to still be established when writing to the evidence buffer on the subsequent chain. Simultaneously, for entries marked as abnormal or missing in the original data packet, the system follows a strategy of marking without valuing, preserving the anomaly cause and missing label as is to avoid introducing secondary processed values ​​into the minimum verifiable input set structure. The system continues to perform rule-driven field filtering. Fields not included in the required field list and not affecting subsequent indicator construction and evidence writing are uniformly removed, and a removal record is retained in the entry. This record includes the removed field name and the rule number at the time of removal. For regulatory announcement metadata, the system retains only three items: announcement number, release time, and a summary of policy key points. It also maintains the association between these items and their positions in the dual-clock mapping table, allowing scenario template assembly to accurately attach the announcement key points in both the sliding window and settlement period dimensions. After minimizing field exposure and filtering the list of required fields, the system restructures the remaining fields. Price and transaction sequences are constructed into matching window views and settlement batch views respectively, based on their affiliation in the dual-clock mapping table. Account position increments and margin usage are restructured into account views by account category, while retaining source pointers to support subsequent on-chain evidence construction.After structural reorganization, a minimum verifiable input set structure is generated. In this invention, the minimum verifiable input set structure is a unified data structure containing three types of views, a set of source pointers, and a time caliber identifier. The three types of views are the matching window view, the settlement batch view, and the announcement mounting view. The source pointer maintains a mapping to the original data packet in each entry, and the time caliber identifier indicates the caliber version and dual-clock attribution relationship followed by the entry. The minimum verifiable input set structure, as the output of this section, is recorded as the output field name "Minimum Verifiable Input Set Structure" and is explicitly used as the input for subsequent step S210. S210 constructs a five-dimensional basis around the matching window view and settlement batch view in this structure and generates a hierarchical risk indicator cluster. Simultaneously, during scenario template assembly, the mounting positions of policy key points and announcement numbers are obtained through the announcement mounting view. The output of this section will also be indirectly referenced as the source data set for subsequent on-chain evidence buffer sharding and time anchor serialization. Because it retains the source pointer and time caliber identifier, subsequent sharding and hash writing do not require re-accessing the original data packet, thus maintaining a unified data channel and permission boundaries. In summary, the technical effects of this step are as follows: By outputting data from multiple sources into a minimal verifiable input set structure through concatenated processing of standard naming, source signature, dual clock alignment, and minimal exposure, this invention establishes a unified input that can be consistently referenced in the business processing classification scenario, providing a verifiable and traceable stable data baseline for subsequent indicator construction, scenario assembly, and evidence on-chaining.

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

[0051] S210. Obtain the minimum verifiable input set structure, perform five-dimensional basis definition and index lattice construction processing to obtain a hierarchical risk index cluster;

[0052] The input source for this section is the minimum verifiable input set structure output in the preceding step S130. This minimum verifiable input set structure includes a matching window view, a settlement batch view, an announcement mounting view, a source pointer, and a time caliber identifier. Specifically, this minimum verifiable input set structure is used as the sole input carrier. The indicator construction component reads the matching window view and the settlement batch view from it, first completing the five-dimensional basis definition. This five-dimensional basis definition refers to clearly defining the constituent fields and value ranges of five dimensions—volatility, liquidity, concentration, leverage, and inter-market transmission—under the same time caliber, and binding the basic entries of each dimension according to the time caliber identifier. Further, after the five-dimensional basis definition is completed, the indicator construction component performs sliding aggregation on the matching window view based on the dual-clock mapping relationship, and during the aggregation process, unifies the numerical interpretation according to the caliber version, forming a time slice sequence that can be called upon in subsequent scenario assembly. Understandably, for boundary and missing entries, the indicator construction component only records boundary identifiers and missing labels on the entries, without performing substitution operations on missing values, and extends this record to the annotation fields of subsequent indicator nodes to ensure that subsequent processing can review the source and status of the entries. Subsequently, the system expands the five-dimensional basis into an indicator lattice along the time slice dimension. The indicator lattice refers to a hierarchical structure formed by arranging and combining the five dimensions across multiple time slices. Inter-layers are indexed by the time slice and dimension mapping, and intra-layers are annotated with the source pointer and caliber version. At each lattice node, the system writes the corresponding value entry, time slice identifier, source pointer, boundary identifier, and missing label together into the node metadata. The node metadata adopts a structured record format, which facilitates the matching and filtering of nodes by subsequent scenario templates. Specifically, for the cross-market transmission dimension, the system reads the cross-market linkage factor from the minimum verifiable input set structure, and after aligning it with the matching window view, establishes a joint marker for the transmission direction identifier and the price difference type identifier. In this invention, the joint marker is used to distinguish the status of different linkage paths under different time slices and is solidified in the lattice node as a searchable entry. Next, the indicator construction component performs account period aggregation on the leverage and concentration dimensions in the settlement batch view. Account period aggregation groups related items within the same settlement batch according to the caliber version and account category, and appends the grouping results to the account period layer nodes, so that the lattice has two observation surfaces: the matching window layer and the settlement batch layer. After the lattice construction is completed, the system starts the node verification process, checking whether the source pointer of each node is valid, whether the caliber version number is consistent with the dual clock mapping table, and whether the boundary identifier matches the boundary rules of the corresponding time slice. If any inconsistency is found, the verification anomaly is registered in the node metadata, and the node is retained but marked as pending review.After completing the above processing, the system aggregates all nodes according to their hierarchical structure to form a hierarchical risk indicator cluster. This cluster includes a set of nodes expanded by time slices and payment terms, a dimension mapping table, node metadata, and a caliber version index, which can be directly referenced in subsequent scenario template assembly processes. The hierarchical risk indicator cluster, as an output of this section, is recorded as the output field name "Hierarchical Risk Indicator Cluster" and is explicitly provided for reading in the next step, S220. S220 will extract sliding window sequences and key points of policy announcements from the hierarchical risk indicator cluster for scenario template assembly and tag binding. This output can also be called across main steps to serve the segmentation organization and source comparison during subsequent risk evidence chain generation.

[0053] S220. Extract sliding window sequences and key points of policy announcements from the hierarchical risk indicator cluster, assemble scenario templates and bind tags to generate scenario tags;

[0054] The input source for this section is the hierarchical risk indicator cluster output by S210 and the announcement mounting view formed by the previous steps. The hierarchical risk indicator cluster provides multi-dimensional nodes and their time slice indexes and payment period indexes, while the announcement mounting view provides the key points of the policy announcements and their mounting positions in the dual clock coordinates. Specifically, the hierarchical risk indicator cluster is used as the main data source. A sliding window sequence composed of several consecutive time slices is retrieved in the matching window layer according to a sliding window strategy. In this invention, the sliding window strategy is defined as combining time slices segment by segment according to a preset window length and step size to form a movable sequence view. Each position in the sequence view holds a reference to a five-dimensional node and node metadata. Further, the system reads the announcement mounting view, attaches the key points of the announcements within the sliding window coverage area to the corresponding sequence positions, and generates a policy key point reference number at the sequence position. The policy key point reference number is used to locate specific clause key points during the template assembly stage. Subsequently, the system enters the scenario template assembly stage. In this invention, scenario template assembly is defined as taking the sliding window sequence and key points of the policy announcement as input, performing pattern matching on the sequence positions within the template rules, and generating scenario labels. The template rules use the relative relationships of five-dimensional nodes, boundary markers and missing labels in node metadata, and the policy announcement citation number and settlement batch payment period information as matching conditions. When the template rules involve payment period conditions, the system simultaneously retrieves the payment period layer nodes of the hierarchical risk indicator cluster. The retrieval results are appended to the sequence positions as auxiliary decision items in the matching process. Understandably, to avoid irrelevant matching for periods not covered by the announcement, the template assembly first trims the sliding window sequence based on the announcement's coverage range, and then performs pattern matching on the trimmed sequence. When pattern matching conflicts occur, it follows template priority for adjudication. The adjudication result, together with the covered sequence position, forms a candidate label. For candidate tags, the system performs a consistency check. This check verifies whether the nodes referenced by the candidate tags have version conflicts, contradictory boundary identifiers, or invalid source pointers. If any anomaly is found, the candidate is marked as a candidate awaiting review and returned to the template assembly process for secondary matching. For candidates that pass the consistency check, the system generates a final scenario tag and writes the tag, its covered sliding window position, corresponding template version number, policy reference number, node reference set, and time-based identifier into the tag record. Further, the system performs coverage relationship parsing on multiple scenario tags that may appear within the same time frame. The coverage relationship is sorted according to template priority, coverage size, and billing period alignment, selecting one as the primary tag and registering the rest as secondary tags. This relationship is recorded in the annotations of the tag record. After completing the above assembly and binding, the system summarizes all tag records to form the output of this section. In this invention, a scenario tag is a type of status identifier object with template version and coverage, which can serve as a direct basis for scenario segmentation during subsequent fragmentation and encapsulation.The scenario tag, as an output product of this section, is recorded as the output field name scenario tag and is explicitly provided for the next step S230 to read in the process. After reading the hierarchical risk indicator cluster and scenario tag, S230 will perform fragmentation encapsulation and source pointer registration processing to form the indicator fragment package required for the on-chain evidence organization of this invention. At the same time, the scenario tag is also reserved as part of the warning trigger input in the cross-main step so that it can be referenced in the construction of the trigger conditions of the subsequent contractual warning and disposal script.

[0055] S230. Perform fragmentation and source pointer registration processing on the hierarchical risk indicator cluster and the scenario label to generate indicator fragmentation package;

[0056] The input sources for this section are the hierarchical risk indicator cluster output by S210 and the scenario tags output by S220. The hierarchical risk indicator cluster provides a set of nodes and node metadata organized by time slices and billing periods. The scenario tags provide the coverage range, template version number, and node reference set after template assembly and coverage parsing. Specifically, the scenario tags are used as the main line for segmentation. According to the coverage range of each scenario tag, the corresponding time slice interval and billing period interval are retrieved within the hierarchical risk indicator cluster to form segmentation candidates. In this invention, a segmentation candidate refers to a set of nodes to be encapsulated and their associated metadata set. Furthermore, the system performs source pointer aggregation for each shard candidate. This aggregation extracts source pointers from all node metadata included in the candidate, deduplicates and sorts them, prioritizing access time order and permitted chain node identifier order. The sorting result is written to the shard candidate's source pointer table. Simultaneously, the system merges caliber version numbers to confirm the consistency of caliber versions within the coverage area of ​​the shard candidate. Inconsistent version numbers are recorded as version divergence entries. These entries are not numerically merged but are only written to a note field during encapsulation for subsequent identification. Subsequently, the system performs shard encapsulation. In this invention, shard encapsulation is defined as uniformly encoding the shard candidate's node set, source pointer table, caliber version index, boundary identifier summary, and template version number into an encapsulation record. Before writing, the encapsulation record undergoes minimum verifiability verification by a verification module. Verification includes checking the completeness of source pointers, the presence of missing labels and boundary identifier contradictions in the node set, the validity of the template version number, and whether the coverage area is consistent with the dual-clock mapping. Understandably, for shard candidates with nodes awaiting review or version divergence entries, the encapsulated record includes a review status and divergence list in the notes, and retains a problem location pointer in the record's referable field. The on-chain evidence buffer can still receive this record, but will trigger a more stringent verification during the witnessing phase. After shard encapsulation, the system registers source pointers for the encapsulated record. In this invention, source pointer registration refers to binding the source pointer table in the encapsulated record to the permissioned chain's index service. The binding result forms a source index pointer in the encapsulated record, which is used to look up the original entry during subsequent on-chain evidence buffer writing and witnessing. After completing source pointer registration, the system serializes the encapsulated record. The serialization result, along with the coverage of the scenario tag, template version number, and billing information, constitutes a shard object. The set of all shard objects is the output of this section. The indicator shard package in this invention is a set of shard objects that can be directly received by the on-chain evidence buffer, possessing a source index pointer, a caliber version index, and a node set reference, which can serve as stable input during subsequent shard hashing and time anchor serialization.The indicator fragment package, as an output of this section, is recorded as the output field name "Indicator Fragment Package" and is explicitly provided for S310 to read in the next step. After reading the indicator fragment package, S310 will perform fragment hashing and time anchor serialization processing to obtain on-chain evidence buffer entries. Simultaneously, the indicator fragment package is also used across main steps for evidence fragment backtracking during subsequent alert triggering and node source display during Kanban rendering. In summary, the technical effect of this step is: by establishing a stable channel for fragment encapsulation and source pointer registration between the hierarchical risk indicator cluster and scenario tags, an indicator fragment package that can directly enter the on-chain evidence organization is formed, providing a feasible structural foundation for subsequent evidence buffering, witness solidification, and alert triggering in terms of input consistency and source replayability.

[0057] In one embodiment, the input sources for S230 are the hierarchical risk indicator cluster output by S210 and the scenario tags output by S220. The hierarchical risk indicator cluster provides a set of nodes and node metadata organized by time slices and payment terms. The scenario tags provide the coverage range, template version number, and node reference set after template assembly and coverage parsing. Specifically, the scenario tags are used as the main line for segmentation. According to the coverage range of each scenario tag, the corresponding time slice interval and payment term interval are retrieved within the hierarchical risk indicator cluster to form segmentation candidates. Formula ① is used to define the generation of segmentation candidates: for scenario tags... Its coverage includes time intervals. and payment period The set of nodes of the hierarchical risk indicator cluster is denoted as Each node With timestamp and payment terms Then the candidate pieces are divided into pieces. It consists of nodes that satisfy the time window constraint:

[0058]

[0059] in: It is a node The timestamp comes from the timestamp field in the node metadata of the hierarchical risk indicator cluster; It is a node The billing period number is derived from the billing period index field in the node metadata of the hierarchical risk indicator cluster; It is a context label The time coverage range is derived from the coverage range field of the scenario tag; It is a context label The billing period coverage is measured in units of billing period intervals, derived from the billing period range field of the scenario tag; It is a set of nodes for a hierarchical risk indicator cluster, derived from the output of S210; This is the set of candidate nodes for sharding; For node index variables; For context label indexing.

[0060] Data source → Indicator → Variable mapping: Extract node timestamps and payment terms from the hierarchical risk indicator cluster, and extract time and payment term coverage from the scenario tags to form sharded candidates. Formula ① This serves as input for subsequent source pointer aggregation. Further, the system performs source pointer aggregation for each shard candidate. Source pointer aggregation extracts source pointers from all node metadata contained in the candidate and then deduplicates and sorts the source pointers. Formula ② defines the sorting of source pointers: for shard candidates... Source pointer set ,in It is a node The source pointer set, after deduplication, yields a unique pointer set. ; Candidate for sharding The union of the source pointers of all nodes in the set; These are pointer variables. Each pointer... With access time and permissioned chain node identifier The sorting rules are as follows: Ascending order, then Ascending order, sorted pointer sequence Defined as:

[0061]

[0062] in: It is a pointer Access time; It is a pointer Permission chain node identifier; It is a node The set of source pointers; This is the number of unique pointers.

[0063] Data source → Indicator → Variable mapping: Source pointers are extracted from the node metadata of the hierarchical risk indicator cluster to form a sorted sequence. Formula ② As input for fragmentation and encapsulation. After the above processing is completed, the fragmentation candidate and sorting pointer sequence are used as intermediate outputs for subsequent fragmentation and encapsulation operations. The fragmentation candidate structure output in this part is input to the fragmentation and encapsulation stage of S230.

[0064] Following the aforementioned fragmentation candidates With sorted pointer sequence The system performs version merging and fragment encapsulation processing. Formula ③ is used for version consistency checking: for fragment candidates... Each node With caliber version number Version collection The consistency function uses the cardinality of the set for determination:

[0065]

[0066] in: For version consistency functions; It is a node The caliber version number comes from the version field in the node metadata; It is a fragment candidate A collection of caliber versions; It is the size of the set.

[0067] Data source → Indicator → Variable mapping: Extracting version numbers from the node metadata of the hierarchical risk indicator cluster to form consistent indicators. Formula ③ Annotation generation for fragmented packaging. Formula ④ is used for the structure definition of fragmented packaging: Package record. It consists of a node set, a pointer sequence, a version index, a summary of boundary identifiers, and a template version number. (Boundary identifier summary) It is a set of node boundary identifiers and template version number. Derived from context tags, the records are encapsulated and represented as tuples:

[0068]

[0069] in: To encapsulate record tuples; It is the set of candidate nodes for sharding, derived from formula ①; It is a sorting pointer sequence, derived from formula ②; It is a set of caliber versions, derived from the input of formula ③; It is a summary of boundary identifiers, derived from the boundary identifier field in the node metadata; It is the template version number, which comes from the template version number field of the scenario tag.

[0070] Data source → Metrics → Variable mapping: Extract relevant fields from sharded candidates and scenario tags to form encapsulated records. Formula ④ As an input for source pointer registration. After fragmentation and encapsulation are completed, the encapsulation record is used as an intermediate output for subsequent source pointer registration. The encapsulation record output in this part is input to the source pointer registration stage of S230.

[0071] Following the aforementioned packaging record The system performs source pointer registration and serialization. Formula ⑤ is used for source pointer registration: encapsulating records. pointer sequence Bind to the permissioned chain index service to generate source index pointers. Binding operations are denoted as functions. Its output is a pointer:

[0072]

[0073] in: It is the source index pointer, which comes from the return result of the permission chain index service; It is a binding function that registers the pointer sequence to the on-chain index service; It is a sorting pointer sequence, derived from formula ②.

[0074] Data source → Metric → Variable mapping: The source index pointer is generated from the pointer sequence in the encapsulated record through a binding operation. (Formula ⑤) As input for serialization. Formula ⑥ is used for serialization: the serialization operation encapsulates the record. With source index pointer Convert to a fragment object The serialization function is denoted as And add context labels to cover the scope. , and template version number :

[0075]

[0076] in: It is a fragment object, derived from the output of the serialization function; It is a serialization function that encodes input parameters into a uniform format; It refers to the time coverage area, which is derived from context tags; It refers to the coverage of payment terms, derived from context tags; It is the template version number, derived from the context tag.

[0077] Data source → Metrics → Variable mapping: Fields are extracted from encapsulated records, source index pointers, and context labels to form sharded objects. Formula 6 As a component of the indicator sharding package, the set of all sharded objects constitutes the indicator sharding package. This part outputs the indicator sharding package, which is input to the sharding hash and time anchor serialization processing in subsequent step S310 to generate on-chain evidence buffer entries.

[0078] This section summarizes the technical effects: By using scenario-driven sharding and source pointer registration, a verifiable sharding encapsulation structure is formed, ensuring the traceability of data sources and consistency of standards, and providing stable input for on-chain evidence processing.

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

[0080] S310. Obtain the indicator shard packet, perform shard hashing and time anchor serialization processing to obtain on-chain evidence buffer entries;

[0081] The input source for this section is the indicator fragment package output from the preceding step S230. This indicator fragment package has already summarized the node set, source index pointer, caliber version index, and boundary marker according to the scenario label coverage range, and is serialized in the form of encapsulated records for writing. This section first has the fragment access component load the indicator fragment package line by line, and read the encapsulated record and source index pointer of each fragment object. Specifically, the node set reference in the encapsulated record is expanded into a traversable list of nodes, and then the corresponding dimensional interpretation is located according to the caliber version index. Subsequently, the node order within the fragment is rearranged in chronological order. During the rearrangement process, nodes with boundary markers and nodes with missing labels are marked with their positions. In this invention, position marking is defined as adding a position category description to the node without changing the node order, used for anchor selection and layered docking of evidence association in subsequent time anchor processing. Further, the system enters the sharding hashing stage. In this invention, sharding hashing refers to forming an ordered field sequence from sharded objects through a stable traversal path of standard field names, and performing irreversible digest processing on this ordered field sequence. The digest input includes a node list, a source index pointer table, a caliber version index, a location label, and a template version number. The digest result is written to the digest field of the encapsulated record. Understandably, to prevent inconsistencies in the digest due to minor differences in the field order of different source nodes, sharding hashing has a set of field sorting rules in advance. The field sorting rules are based primarily on the lexicographical order of standard field names, time slice sequence number, and account period number, and secondarily on the source index pointer sorting, ensuring that the digest input can be reproduced under the same rules. After obtaining the shard summary, the system performs a duplicate check on the summary field. In this invention, duplicate check is defined as checking whether a shard summary with the same coverage and template version number already exists in the write-to-write pool or the write-to-write pool. If a duplicate summary exists and is already in the write-to-write pool, the current shard is marked as a duplicate candidate and enters the lightweight anchoring process. If a duplicate summary exists but is in the write-to-write pool, the two are merged into a single write-to-write entry, and the source merge list is recorded. Subsequently, the system initiates time anchor serialization processing. In this invention, a time anchor refers to connecting the shard object with the dual-clock mapping relationship to generate an anchor sequence within the coverage area. Each anchor records the shard summary, the corresponding matching window position and settlement batch number, the boundary marker position set, the policy reference number, and the caliber version number. When processing nodes with boundary markers, the time anchor selects an upper or lower bound anchor position according to boundary rules and records the boundary policy identifier, without replacing or estimating the data content.To ensure that the anchor sequence remains consistent with the time baseline within the permissioned chain during subsequent on-chain writes, the system calls a time base aligner after anchor generation to map local timestamps to on-chain timestamps. These on-chain timestamps are provided by the permissioned chain time service and are consistent with the witness expectation window configuration. For anchors that fail to align within the witness expectation window, the system includes them in a delay queue. In this invention, the delay queue refers to a set of entries waiting for the next round of time service alignment before attempting to write. Delayed entries retain their original local timestamps and the reason for alignment failure. After completing the time anchor serialization, the system constructs a write entry from the digest field, anchor sequence, source merge list, and delay queue identifier for each shard, and submits it in batches to the on-chain evidence buffer via a buffer writer. The buffer writer supports a segmented submission strategy and a failure retry strategy. The segmented submission strategy segments the write entry according to its coverage and template version number. The failure retry strategy only initiates a limited number of re-submissions for on-chain recoverable errors. All failures and re-submissions are recorded in the entry's annotation. After the batch submission is completed, the on-chain evidence buffer generates a readable write receipt. The write receipt contains the alignment result of the buffer key value and on-chain timestamp for each entry to be written. The system bidirectionally binds the receipt to the corresponding shard encapsulated record and generates an on-chain evidence buffer entry. In this invention, an on-chain evidence buffer entry is defined as a set of on-chain evidence records that have not yet been witnessed, holding an index key and time anchor information that can be used in the witnessing phase. The on-chain evidence buffer entry is recorded as the output field name "On-chain Evidence Buffer Entry" in this section and is explicitly provided for the next step S320 to read in the process. S320 will extract the witness request based on the on-chain evidence buffer entry and perform majority signature threshold verification of the witness committee. At the same time, this output will also serve as the source of evidence for cross-main steps and will be referenced for tracing back when S400 constructs the warning basis.

[0082] S320. Extract witness requests from the entries in the on-chain evidence buffer, perform majority signature threshold verification of the witness committee, and generate risk evidence chain candidates.

[0083] This section takes as input the on-chain evidence buffer entries output by S310. These entries hold buffer key values, shard summaries, time anchor sequences, source merging lists, and delay queue identifiers. First, the witness scheduler scans the on-chain evidence buffer entries, filtering entries that can be immediately witnessed based on the alignment of the witness expectation window with the on-chain timestamp. The filtering rule prioritizes entries without delay queue identifiers and with complete time anchor coverage. Entries containing delay queue identifiers are not immediately witnessed; only a rotation indicator is added to the notes. Specifically, the witness scheduler breaks down each witnessable entry into a witness request. In this invention, a witness request is defined as a verification unit broadcast to the witness committee, containing a shard summary, time anchor sequence, source merging list, template version number, caliber version number, and boundary policy identifier. A session number and session time window are assigned to this request. The session number is used to associate multiple interaction records during the witnessing process, and the session time window is used to limit the on-chain confirmation span for witness completion. Subsequently, the system submits the witness request to the Witness Committee, which consists of witness nodes within the permissioned chain. In this invention, witness nodes are a set of nodes with read-only access and signing permissions. Upon receiving the witness request, the Witness Committee first checks the source index pointer against the source merge list to verify whether the shard digest matches the consistent field sequence of the source entry. It then performs anchor validity verification on each anchor point in the time anchor sequence, which includes verification of the legality of the on-chain time tag and verification of the anchor point coverage. If any witness node finds that the source index pointer cannot be checked back, or that the anchor point has issues such as inconsistencies between the time tag and the on-chain time service, the node will issue a rejection opinion in the witness response, along with a rejection reason number. After collecting witness responses, the witness scheduler proceeds to majority signature threshold verification. In this invention, majority signature threshold verification is defined as counting the number of signatures for both agreement and rejection according to a preset threshold policy. When the number of signatures for agreement reaches the threshold policy requirement, the witness request is deemed successful. When the number of rejections reaches another threshold or the session time window expires without reaching the agreement threshold, the witness request is deemed unsuccessful, and the reason for failure is recorded. Understandably, the threshold policy supports different policy versions for different business groups. The policy version is provided by the on-chain parameter management contract. Before initiating a witness request, the witness scheduler reads the currently effective version from the parameter management contract and broadcasts it with the request, preventing witness nodes from using expired policies for statistics.For witness requests that pass the majority signature threshold verification, the system generates risk evidence chain candidates. In this invention, the risk evidence chain candidate is the evidence structure to be solidified, including the fragment digest of the witnessed request, time anchor sequence, signature summary, policy version number, session number, and an index of interaction records during the witnessing period. For witness requests that fail, the system returns the entry to the on-chain evidence buffer while maintaining its buffer key value. Simultaneously, it increments the failure count and rejection reason number in the entry's annotation. If the failure count exceeds the upper limit, it is marked as permanently shelved. Permanently shelved entries can only be re-encapsulated and re-enter S310 after being triggered by business review. After generating the risk evidence chain candidates, the witness scheduler submits the candidates to the solidification write channel and assigns a solidification batch number and a solidification sequence number to each candidate. The solidification write channel in this invention is the queuing mechanism for the final on-chain data writing. The solidification batch number is used to align with the on-chain block production rhythm, and the solidification sequence number is used to ensure the stable ordering of candidates within the same batch. The risk evidence chain candidate is recorded as the output field name "risk evidence chain candidate" as an output product of this section, and is explicitly provided for the next step S330 to read in the process. S330 will perform solidification writing and pointer registration processing on the risk evidence chain candidate. At the same time, this output can also be referenced across main steps, and serves as the starting point for the reference of evidence fragments when constructing graded early warning events in S400.

[0084] In one embodiment, the input source for S320 is the on-chain evidence buffer entries output by S310. This set of entries holds buffer key values, fragment digests, time anchor sequences, source merging lists, and delay queue identifiers. This section first has the witness scheduler scan the on-chain evidence buffer entries and filter entries that can immediately proceed to witnessing based on the alignment result between the witness expectation window and the on-chain timestamp. Formula ⑦ is used to define the generation of witness requests: for on-chain evidence buffer entries... Its fragmented summary is denoted as The time anchor sequence is denoted as The source merged list is denoted as The template version number is denoted as The caliber version number is recorded as The boundary policy identifier is denoted as Then witness request Defined as a tuple:

[0085]

[0086] in, It is a fragment digest, derived from the fragment digest field of the on-chain evidence buffer entry; It is a time anchor sequence, derived from the time anchor sequence field of the entry; It is the source merge list, derived from the source merge list field of the entry; It is the template version number, derived from the template version number field of the entry; It is the caliber version number, which comes from the caliber version number field of the entry; It is the boundary policy identifier, derived from the boundary policy field of the entry; It is a session number, assigned by the witness scheduler; It is the session time window, set by the witness scheduler.

[0087] Data source → Metrics → Variable mapping: Extracting fields such as shard summaries and time anchor sequences from on-chain evidence buffer entries to form witness requests. Formula ⑦ As input for the witness committee's verification. Formula ⑧ is used to define the verification function for the witness node: Witness Node Request received Then, execute the verification function. The function first looks up the source index pointer to verify the validity of the fragment digest and time anchor, and outputs a binary response:

[0088]

[0089] in: It is a witness node index, derived from the witness committee node list; It is a node The verification function represents the verification operation on the request; the output 1 indicates approval and 0 indicates rejection.

[0090] Data Source → Metric → Variable Mapping: The witness request generates a response value through a verification function. The verification result of Formula ⑧ serves as the input for the majority signature threshold verification. After witness request generation and broadcasting are completed, the system enters the response collection phase. This part outputs the witness request set, which is then input to the majority signature threshold verification process of S320.

[0091] Accepting the aforementioned witness request Based on the verification results with the witness nodes, the system collects witness responses and verifies the majority signature threshold. Formula 9 is used to define the response set: for a request... The Witness Committee has a total of Each node, response set Verification results including all nodes:

[0092]

[0093] in: This is the total number of witness nodes, derived from the configuration of the Witness Committee; It is a set of responses, and its dimension is a set of binary values.

[0094] Data source → Metrics → Variable mapping: The response set is formed by the verification results of each witness node. Formula 9 As input for threshold verification. Formula 10 is used to define the majority signature threshold verification: Let the number of agreeing opinions be... The number of dissenting opinions was The threshold policy requires that the agreed threshold be... The rejection threshold is Then it is determined as follows:

[0095]

[0096] in: It is the number of agreeing opinions; It is the number of rejections; It is an agreement threshold, derived from the on-chain parameter management contract; It is a rejection threshold, derived from the on-chain parameter management contract; The function outputs 1 to indicate success and 0 to indicate failure.

[0097] Data source → Metric → Variable mapping: The pass / fail result is generated from the response set using a threshold strategy. Formula 10... This serves as a criterion for generating candidate risk evidence chains. After completing the verification of most signature thresholds, the system performs subsequent processing based on the judgment results. The output of this part, which passes the judgment result, is input into the risk evidence chain candidate generation stage of S320.

[0098] Following the aforementioned pass / fail result The system generates and queues candidate risk evidence chains. Formula 11 defines the generation of candidate risk evidence chains: if Then candidate , including fragmented summaries Time anchor sequence Signature Summary Strategy version number Session number With Interaction Record Index :

[0099]

[0100] in, Candidate for risk evidence chain; It is a signature aggregation, derived from the digital signatures of the nodes that agree; It is the policy version number, derived from the threshold policy version; It is an interaction record index, derived from the interaction logs during the witnessing process.

[0101] Data source → Indicator → Variable mapping: Risk evidence chain candidates are generated from the witnessed requests that pass the judgment. (Formula 11) As input for the solidified writing process. Formula 12 is used to define the candidate queue: candidate Assigned curing batch number With curing sequence number Queue position is determined by batch number:

[0102]

[0103] in: It is the batch number that is cured, which is assigned by the curing write channel; It is the curing sequence number, assigned by the curing write channel; It is a queuing function that outputs batch and sequence number pairs.

[0104] Data Source → Indicator → Variable Mapping: The risk evidence chain candidates are queued through a queuing mechanism. The queuing result of Formula 12 serves as the input for the solidification and writing channel. After candidate generation and queuing are completed, the system outputs the risk evidence chain candidates, which are then input to the subsequent step S330's "solidification and writing and pointer registration processing". This section summarizes the technical effect: Through majority signature threshold verification by the witness committee, a traceable witnessing result is formed, providing verifiable input for evidence solidification.

[0105] S330. Perform solidification writing and pointer registration processing on the candidate risk evidence chain to generate a risk evidence chain;

[0106] This section takes as input the risk evidence chain candidates output by S320. These candidates include a witnessed shard summary, time anchor sequence, signature summary, policy version number, session number, and interaction record index. First, the solidification coordinator pulls the candidate queue according to the solidification batch number and sorts the queue by the solidification sequence number of each candidate. After sorting, the solidification preparation stage begins. In this stage, the shard summary and time anchor sequence of the candidates are reconstructed into a solidified record skeleton. In this invention, the solidified record skeleton is the record carrier to be written to on-chain storage. The skeleton reserves evidence pointer bits, signature summary bits, policy version bits, and session number bits. Specifically, the solidification coordinator calls the write interface of the on-chain storage contract to register the solidified record skeleton to the block memory pool, embedding the signature summary and policy version number during registration. After the write interface returns the block position reservation information, the solidification coordinator obtains the reserved position indication and saves this indication along with the candidate's interaction record index in the solidification context. The solidification context is used for index generation and reverse binding in the subsequent pointer registration stage. Subsequently, the system enters the pointer registration process. In this invention, pointer registration refers to generating on-chain evidence pointers for registered solidified records and establishing reverse resolution relationships. The evidence pointer generator calculates record location entries based on block location reservation information and solidification sequence numbers, and establishes a mapping with session numbers. The mapping relationship is written into the pointer index table, which is an on-chain queryable index structure used to reference the evidence record across steps. After generating the evidence pointer, the system performs reverse binding on the source index pointer. Reverse binding writes the evidence pointer of the solidified record back to the extension field of the source shard object. The extension field records the on-chain position of the shard that can be traced after solidification. At the same time, the evidence pointer is also written into the reference list of the scenario tag. In this invention, the reference list is a bridge between the scenario tag and the evidence chain, allowing subsequent warning triggering and Kanban rendering to directly jump from the scenario layer to the evidence layer. Understandably, if an anomaly occurs during the solidification process, such as a failure to write the on-chain storage contract or the invalidation of the block position reservation information, the solidification coordinator will roll back the candidate to the solidification queue and increase the failure count. If the failure count reaches a threshold, the item will be marked as a solidification anomaly, and the anomaly number and diagnostic summary will be recorded in the candidate's notes. Solidification anomalies must be reviewed by the operations and maintenance side before they can re-enter the solidification process. For solidified records that have been successfully written and whose pointer registration has been completed, the system performs final signature confirmation. The solidification confirmer calls the confirmation interface of the witness committee to collect confirmation receipts. The confirmation receipts, along with the block identifier, evidence pointer, and session number of the solidified record, together form the final evidence entry. The final evidence entries are connected according to a time anchor sequence, with the connection rules following the chronological order and the adjacency of the coverage area. After the connection is completed, a risk evidence chain is formed. In this invention, the risk evidence chain is a set of evidence entries organized in chronological order, holding complete witnessing process, solidification position information, and index relationships.After constructing the risk evidence chain, the system registers the head and tail pointers of the chain in the evidence directory table. In this invention, the evidence directory table is a aggregated index for querying and visualization, and its entries will be read by S410 as input for early warning judgment. Simultaneously, the system writes a solidified summary to the report logging contract. The solidified summary records the number of candidates, successes, failures, and anomaly numbers solidified in this batch, and binds the summary to the solidified batch number so that subsequent audits can review the solidification process of the same batch. At this point, the risk evidence chain, as an output of this section, is recorded as the output field name "Risk Evidence Chain" and is explicitly provided for S410 to read in the next step. S410 will execute three-dimensional triggering rules based on the risk evidence chain, including threshold, rate, and persistence, to obtain graded early warning events. This output is also used in cross-main-step scenarios for displaying evidence trajectories in Kanban rendering and for citing evidence in the handling script. In summary, the technical effects of this step are as follows: by connecting the on-chain evidence buffer, the majority signature threshold verification of the witness committee, the solidification writing, and the pointer registration sequence, a stable path is formed from the entry to be written to the queryable evidence chain, so that subsequent early warning triggers and report logging can directly reference consistent and traceable evidence entries and maintain the reverse parsing relationship with the source data.

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

[0108] S410. Obtain the risk evidence chain, perform threshold-rate-persistence three-dimensional triggering rule processing, and obtain graded early warning events;

[0109] The input source for this section is the risk evidence chain output from the preceding step S330. This risk evidence chain is composed of evidence entries that have been witnessed, verified, and solidified, linked together in chronological order. Each evidence entry contains fields such as a fragment summary, time anchor, signature summary, policy version, session number, and evidence pointer, and is registered in the evidence catalog table at the head and tail of the chain. Specifically, the risk evidence chain is introduced into a contractual early warning engine. In this invention, the contractual early warning engine is defined as a rule execution component running on a permissioned blockchain. Its rule set is issued by a parameter management contract and includes three categories: threshold rules, rate rules, and persistence rules, which are used to determine the same evidence sequence from different observation dimensions. First, the contract-based early warning engine determines the observation window based on the time anchor range given in the evidence catalog table and calls the on-chain time service to obtain a time reference consistent with the current block rhythm, dividing the evidence entries into several sequence segments according to the window. Within each sequence segment, the contract-based early warning engine retrieves the node reference set of the indicator shard package from the evidence pointer. In this invention, the node reference set is the set of nodes passed from the scenario tag and indicator shard package and reverse-bound in the solidification stage, which can provide the dimension value, source pointer, and caliber version index corresponding to each evidence entry. Further, the contract-based early warning engine performs threshold rule processing on each sequence segment. In this invention, threshold rule processing is defined as comparing and judging the same dimension value with the threshold configuration contained in the rule set. The threshold configuration is segmented and managed according to the scenario template version, caliber version, and market clock or settlement clock dimensions. When there are evidence entries with boundary markers within a sequence segment, the threshold rule processing does not replace the values, but only records the boundary markers as notes in the threshold judgment and marks the boundary participation in the sequence segment judgment result. Subsequently, the contractual early warning engine performs rate rule processing. In this invention, rate rule processing is defined as determining the magnitude and rhythm of changes in the dimensional values ​​of adjacent or spanning evidence items. Specifically, this involves constructing change paths within the same caliber version and rule segment, and calculating the relative strength of changes in adjacent items. For evidence items with a source merging list, rate rule processing uses the earliest access time in the source merging list as a comparison benchmark when constructing the change path, and records other sources as parallel references to reduce interference from rhythm differences in different access paths. Next, the contractual early warning engine performs persistence rule processing. In this invention, persistence rule processing is defined as retrieving continuous segments within a specified time span or settlement batch span where both the threshold and rate determination are triggered, and determining whether their length meets the minimum coverage standard required by the rule. If there is a gap in the sequence segment marked by the delay queue identifier, persistence rule processing records it as an interruption of the continuous segment without filling the gap, and includes the gap position in the determination annotation.After the above three types of rule processing are completed, the contractual early warning engine synthesizes the judgment results at the sequence segment level. The synthesis process follows a priority structure of threshold hit, rate significance, and persistence satisfaction. The priority structure and strategy version are written into the synthesis record. When multiple dimensions meet the trigger conditions and overlap in the same sequence segment, the synthesis process selects the dimensions according to the priority in the scenario template. The selected result is used as the early warning dimension, and the remaining dimensions are registered as auxiliary notes. Understandably, the generation of the synthesis record does not affect any field of the evidence chain ontology, but only forms an auditable execution record within the contract state space. After obtaining the synthesis record, the contractual early warning engine generates early warning entries and classifies them. The classification rules are provided by the rule set, usually scoring based on dimensions such as trigger strength, coverage, and recurrence, and finally mapping to different levels such as L1, L2, or L3. When an early warning entry is generated, it carries the evidence pointer set, synthesis record summary, strategy version, template version, and time range, and is written into the early warning buffer table. Subsequently, the contractual early warning engine performs conflict resolution on the early warning buffer table. Conflict resolution, in this invention, is defined as the merging of levels caused by differences in coverage or dimensions of different entries within the same time frame. After merging, the main early warning entry is output, while secondary early warning entries are retained as reference items. After conflict resolution, the system encapsulates the main early warning entry and its secondary items into a hierarchical early warning event. In this invention, the hierarchical early warning event is a direct input to the handling process, containing fields such as level, evidence pointer set, synthetic record summary, strategy version, template version, and time anchor range. The hierarchical early warning event, as an output of this section, is recorded as the output field name "Hierarchical Early Warning Event" and is explicitly provided for the next step, S420, to read. S420 extracts the handling level and evidence pointer from the hierarchical early warning event, performs handling script matching and execution invocation; simultaneously, the hierarchical early warning event can be used across main steps for event stream rendering in the Kanban real-time layer and rule review in the strategy replay layer.

[0110] S420. Extract the handling level and evidence pointer from the graded early warning event, perform handling script matching and execution invocation, and generate a handling script execution receipt;

[0111] The input for this section is the tiered warning event output by S410. This tiered warning event includes fields such as warning level, evidence pointer set, synthetic record summary, strategy version, template version, and time anchor range. Specifically, the disposal orchestrator first reads the level field of the tiered warning event and queries the disposal script directory under the constraint of the strategy version. In this invention, the disposal script directory is defined as a set of on-chain searchable disposal processes, organized hierarchically by level, scenario template, and market status. Each disposal script has a parameterizable action sequence, dependency check conditions, and rollback path. After identifying a matching disposal script, the disposal orchestrator injects the evidence pointer set from the tiered warning event into the script's dependency check module. The dependency check module verifies whether the context required to start the script is sufficient, including whether the account type is within the intervention range, whether the settlement batch is in an operable window, whether there are policy restrictions with the announcement mounting view, and whether the source merging list contains restricted nodes. When the dependency check finds unmet requirements, the disposal orchestrator selects an alternative script of the same level or enables a downgraded action sequence within the same script without changing the original warning entry, and registers the reason for the substitution or downgrade in the disposal call record. Furthermore, the disposal orchestrator enters the action orchestration stage. In this invention, the action orchestration stage is defined as scheduling calls according to a parameterized action sequence within a defined disposal script. The action sequence may include parameters such as increasing margin requirements, restricting high-frequency reporting, suggesting temporary suspension, and accelerating information disclosure. The specific parameters are determined by the level of the graded warning event, the coverage of the evidence pointer, and the trigger strength in the synthetic record summary. The action orchestration stage generates an action call unit for each action. The action call unit holds a subset of action parameters, dependency check conclusions, and evidence pointers, and is invoked on-chain through the action gateway contract. In this invention, the action gateway contract is an interface layer connecting to the market operation system, clearing system, or information disclosure system, supporting asynchronous receipts and fault retries. Understandably, to adapt to the feedback rhythm of different systems, the action invocation unit enters a waiting state after invocation. The waiting state is managed by session number and time window. Actions that have not received a response after the time window are marked as timed out and trigger a rollback path. The rollback path has a clear order and parameters in the action sequence and is uniformly scheduled by the handling orchestrator after execution failure or timeout. During the rollback process, the association between the evidence pointer and the session number is also maintained to facilitate subsequent auditing and review. After receiving the asynchronous responses from each action, the handling orchestrator enters the response aggregation stage. In this invention, the response aggregation stage is defined as merging the scattered action responses to form a unified handling result for the same graded early warning event. During the merging, the handling orchestrator sorts the actions according to their criticality and triggering order, using the success or failure of critical actions as the main criterion for the handling result, and recording the status of non-critical actions in the notes section. For cases with partial success and partial failure, the handling orchestrator will mark the segmented status in the handling result and present the differences when generating subsequent reports.After the receipts are aggregated, the disposal orchestrator generates disposal script execution receipts. In this invention, the disposal script execution receipt is a structured summary of a single disposal script execution process, including fields such as disposal level, script version, action sequence status, session number, evidence pointer set, dependency check conclusion, rollback execution trajectory, and external system receipt number, forming a readable record on the chain. The disposal script execution receipt, as an output product of this section, is recorded as the output field name "Disposal Script Execution Receipt" and is explicitly provided for reading by the next step, S430, which will perform report logging and dashboard rendering based on the disposal script execution receipt. Simultaneously, in cross-main-step scenarios, the disposal script execution receipt will also be read by S110 as a supplementary source of regulatory announcement metadata, guiding the incremental assembly of announcement key points in subsequent scenario template versions through write-back pointers.

[0112] S430. Perform report logging and dashboard rendering on the execution receipt of the disposal script to generate a compliance logging report and a visual dashboard structure.

[0113] The input source for this section is the execution receipt of the disposal script output by S420. This receipt records fields such as disposal level, script version, action sequence status, session number, evidence pointer set, dependency check conclusion, rollback execution trajectory, and external system receipt number. Specifically, the report tracking engine first receives the disposal script execution receipt and obtains the current report template version from the on-chain parameter management contract. In this invention, the report template version is defined as a versioned description of the field layout and presentation structure of the compliant report, including the necessary field set, field order, field grouping, and display rules. After loading the template, the report tracking engine repositions the disposal level, script version, and action sequence status, and retrieves the on-chain position and head / tail pointers of the risk evidence chain from the evidence pointer set to construct the evidence trajectory section of the report. During the construction process, the report tracking engine does not rewrite the content of the evidence entries; it only associates them with evidence pointers and displays the mapping relationship between the evidence pointers and the time anchor range in the report. Furthermore, the report logging engine categorizes the dependency check conclusions and rollback execution trajectories into the preconditions and constraints and disposal trajectory sections, respectively. The former records whether the context conditions for script execution are met, while the latter records the rollback paths triggered during execution and their execution order. For actions with external system receipt numbers, the report logging engine establishes bidirectional references in the external interaction section, enabling the report to access the read-only credentials or interface query pages of external systems via the receipt number. Understandably, after generating the report body, the report logging engine calls the write interface of the report logging contract to write the report summary entries onto the chain and obtain the report record pointer. In this invention, the report record pointer is used as an index key to identify a complete disposal process and can be referenced by the audit end and the dashboard end. At the same time, the report logging engine binds the report record pointer to the session number of the disposal script execution receipt to enable cross-component association retrieval within the same session. Subsequently, the system enters the Kanban rendering stage. In this invention, Kanban rendering is defined as visually presenting the execution receipts of the handling script and related evidence items in the risk evidence chain. The presentation module loads the layout definition based on the Kanban configuration version. The layout definition includes four visualization areas: a timeline, an event layer, an evidence layer, and an action layer. The system maps the evidence pointer set to the evidence layer, arranging items with a time anchor as the horizontal axis. The level of the graded warning event is presented in the event layer using color or markers, and the action sequence status is presented in the action layer according to the calling order and status identifier. The timeline is used for alignment across the three layers. To reduce data access pressure during visualization rendering, the Kanban rendering stage first reads the evidence index and report summary of the most recent time period from the chain cache, then incrementally retrieves evidence items not in the cache, and writes the incremental results back to the cache component. After Kanban rendering is completed, the system registers the metadata of the rendering snapshot as a Kanban record. The metadata includes the rendering time period, layout version, participating evidence pointer range, event identifier, and action identifier set.After completing report recording and dashboard rendering, the system generates the structured output for this section. In this invention, the compliance record report and the visual dashboard structure are a unified object. This unified object contains report record pointers, dashboard records, and write-back pointers. The write-back pointers are used to feed back the summary information of this action to the regulatory announcement metadata channel on the data side, facilitating its use as an incremental source for the announcement mounting view during subsequent S110 data collection. When the unified object is generated, the system simultaneously registers a reference record in the evidence catalog table, allowing subsequent S410 to directly review the corresponding report when constructing the basis section for the warning event. The compliance record report and the visual dashboard structure, as output products of this section, are recorded as the output field name "Compliance Record Report and Visual Dashboard Structure," and are used for presentation and audit calls across main steps in the process. The write-back pointers will be included in the collection buffer by the data side in the next round of S110 as clues for capturing regulatory announcement metadata. In summary, the technical effects of this step are as follows: By structurally recording and visually presenting the handling process driven by graded early warning events, a closed-loop expression is formed, from evidence items to handling receipts to reports and dashboards, enabling subsequent rule reviews and version governance to be connected and integrated within the same on-chain index system.

Claims

1. A blockchain-based method for monitoring financial risks in the electricity market, characterized in that, include: Obtain market clearing price, intraday trading matching records, account position increment, margin usage, cross-market linkage factors and regulatory announcement metadata, perform naming standard conversion and source signature binding through a unified adaptation component, and perform dual clock alignment and field filtering to generate a minimum verifiable input set structure; Based on the minimum verifiable input set structure, five-dimensional basis definition and indicator lattice construction are performed to generate hierarchical risk indicator clusters. Scenario template assembly is performed to generate scenario labels. Based on the hierarchical risk indicator clusters and scenario labels, fragmented encapsulation and source pointer registration are performed to generate indicator fragment packages. Obtain the indicator shard package, perform shard hashing and time anchor serialization processing to generate on-chain evidence buffer entries, extract witness requests from on-chain evidence buffer entries, perform majority signature threshold verification of the witness committee to generate risk evidence chain candidates, and perform solidification writing processing to generate risk evidence chain; Based on the risk evidence chain, the system performs three-dimensional trigger rule judgment, disposal script matching and execution call, and report recording and dashboard rendering to generate compliance recording reports and visual dashboard structures.

2. The method according to claim 1, characterized in that, Market clearing price, intraday trading matching records, account position increases, margin requirements, cross-market linkage factors, and regulatory announcement metadata include: The market clearing price refers to a price sequence of one or more commodities generated by the matching and clearing mechanism within the agreed settlement period; the time-sharing trading matching record refers to the time tag, order direction, order quantity, and transaction quantity of each matching event; the account position increment refers to the differential record of account position changes between adjacent time slices; the margin usage refers to the balance and changes of margin frozen and released relative to an account or contract; the cross-market linkage factor refers to the measurable price difference, trading activity, or trading percentage between spot and derivatives, and between regions and commodities; the regulatory announcement metadata refers to the announcement title, announcement time, scope of application, number index, and related rule points issued by the regulatory platform or market operator.

3. The method according to claim 1, characterized in that, The minimum verifiable input set structure includes: The minimum verifiable input set structure includes a matching window view, a settlement batch view and an announcement mounting view, a source pointer and a time caliber identifier.

4. The method according to claim 1, characterized in that, The process of generating indicator fragment packets by performing fragment encapsulation and source pointer registration includes: Using scenario tags as the main line for segmentation and delineation, the corresponding time slice interval and payment period interval are retrieved within the hierarchical risk indicator cluster according to the coverage of each scenario tag to form segmentation candidates. For each shard candidate, source pointer aggregation is performed. Source pointers are extracted from all node metadata contained in the candidate, and the source pointers are deduplicated and sorted. The sorting result is written to the source pointer table of the shard candidate. Merge the caliber version numbers to confirm the consistency of the caliber version within the coverage area for the candidate shard, and record the inconsistent version numbers as version divergence entries. Perform sharding encapsulation, and encode the node set, source pointer table, caliber version index, boundary identifier summary and template version number of the sharding candidate into an encapsulation record, and perform minimum verifiability verification on the encapsulation record; Register the source pointer for the encapsulation record, and bind the source pointer table in the encapsulation record to the index service of the permission chain to form the source index pointer; The encapsulated records are serialized, and the serialization result, together with the coverage of the scenario label, the template version number, and the billing information, forms an indicator fragment package.

5. The method according to claim 4, characterized in that, The sorting rules prioritize access time order and permission chain node identification order.

6. The method according to claim 4, characterized in that, Minimum verifiability checks include: checking whether the source pointer is complete, whether there are contradictions between missing labels and boundary markers in the node set, and whether the template version number is valid and whether the coverage is consistent with the dual clock mapping.

7. The method according to claim 4, characterized in that, For shard candidates with nodes pending review or version divergence entries, the encapsulated record includes a list of pending review status and divergence in the notes, and retains a pointer to the problem location in the record's referenceable fields.

8. The method according to claim 1, characterized in that, The process of extracting witness requests from on-chain evidence buffer entries, performing witness committee majority signature threshold verification to generate risky evidence chain candidates also includes: The witness scheduler scans the entries in the on-chain evidence buffer and filters the entries that can be immediately witnessed based on the alignment result between the witness expectation window and the on-chain timestamp. Each witnessable entry is broken down into a witness request and broadcast to the witness committee. The witness request includes a fragment summary, a time anchor sequence, a source merge list, a template version number, a caliber version number, and a boundary policy identifier. A session number and a session time window are assigned to the request. Upon receiving a witnessing request, the Witness Committee checks the source index pointers against the source merge list to verify whether the fragmented summary matches the consistent field sequence of the source entries, and performs anchoring validity checks on each anchor point in the time anchor sequence. After collecting witness responses, the witness scheduler enters the majority signature threshold verification. It counts the number of signatures for agreement and rejection according to the preset threshold strategy. When the number of signatures for agreement reaches the threshold strategy requirement, the witness request is deemed to be approved, and a candidate risk evidence chain is generated.

9. The method according to claim 8, characterized in that, The threshold policy supports different policy versions for different business groups. The policy version is provided by the on-chain parameter management contract. Before initiating a witness request, the witness scheduler reads the currently effective version from the parameter management contract and broadcasts it with the request.

10. The method according to claim 8, characterized in that, For witness requests that fail the majority signature threshold verification, the system returns the entry to the on-chain evidence buffer and maintains its buffer key value unchanged. The failure count and rejection reason number are accumulated in the entry notes. If the failure count exceeds the upper limit, it is marked as permanently shelved.

Images