Blockchain power data security sharing method

Abstract

The application relates to the field of computer information security and access control, and discloses a blockchain electric power data security sharing method.The method comprises the following steps: acquiring a data domain list, a measuring point list and a configuration mapping table, performing naming specification, time anchor registration and de-identification processing, forming a fixed field sequence and a chain index record structure; based on context legality verification and strategy mapping, generating an access constraint strategy, and completing generation and binding of a one-time session token, solidifying the strategy snapshot on the contract side and registering the valid period; constructing zero-knowledge proof and assembling witness materials, performing double-channel checking, event settlement and failure evidence registration through a verifiable session smart contract; establishing end-to-end key negotiation and control channels, and realizing safe data minimization and result sealing.The application realizes trusted sharing and traceable access of electric power data among multiple subjects, and improves data security, compliance and on-chain governance capability.

Description

Technical Field

[0001] This invention relates to the field of computer information security and access control, and in particular to a blockchain-based method for securely sharing power data. Background Technology

[0002] In the field of computer information security and access control, existing solutions for cross-entity sharing and access control of power data typically rely on blockchain to record data-related information, manage data off-chain, and implement access control through smart contracts. Common practices include writing raw data or summaries onto the chain, using preset access lists and static policies for authorization, employing symmetric encryption or gateway encryption during transmission, and supplementing with log registration and auditing interfaces. However, these solutions suffer from limitations such as inconsistencies between data domains and measurement point standards leading to alignment difficulties, lack of versioned association between access constraints and session states, and fragmented evidence retention and failure handling processes. Existing methods often revolve around on-chain evidence storage and encryption / decryption transmission processes, relying on fixed field mappings, static time windows, and manually configured policy mappings. When faced with time window constraints and cross-domain collaboration, these methods are prone to unclear field pruning boundaries, distortion of call frequency and validity period write-back, and difficulty in achieving stable implementation that minimizes data retrieval and seals results. Regarding the joint processing of on-chain index record structure, one-time session tokens, and time window constraints, existing technologies generally have common shortcomings in the synchronization of naming specifications and time anchor registration, the determination of access field masks and load channel pruning, and the control linkage between event accounting and failure evidence tables. These shortcomings make it difficult to form a continuous process of acquisition—specification—registration—verification—channel—data retrieval—sealing—archiving in power data sharing application scenarios. As a result, there is a lack of integrated constraints between source matching verification, link consistency verification, and transaction log registration in the access process of verification before retrieval, which affects the traceability and controllability of production operation and data management processes. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a blockchain-based method for secure sharing of electricity data, comprising:

[0004] Obtain the data domain list, measurement point list and configuration mapping table, perform naming standardization, time anchor registration and de-identification, commitment value and hash digest calculation, and unified field encoding. Form a fixed field sequence with unified field name / dimension / caliber, generate the minimum retrieval index key and submission batch unit according to domain identifier / measurement point identifier / time range, and generate on-chain index record structure.

[0005] Perform context legality verification, policy mapping and access constraint policy version number registration, extract role / purpose / time window constraints from access constraint policies, execute one-time session token generation and token value binding with session number and evidence preservation policy pointer association, and complete policy snapshot solidification and validity period writing on the contract side to obtain session registration records;

[0006] Perform source matching verification, time anchor alignment and link consistency verification, construct zero-knowledge proof and assemble witness materials, verify and generate events in the verifiable session smart contract according to the commitment value and hash digest dual channels, register failure evidence in the failure evidence table for failed entries and create blacklist placeholders for associated tokens, and generate verification result records.

[0007] Perform end-to-end key negotiation and control channel establishment, distribute policies according to access field masks and time window constraints, establish payload channels and minimize data retrieval, return only digest metadata for abnormal fragments and seal the results with session keys, register transaction logs and token consumption records, and output a governance archive structure containing policy tightening recommendations.

[0008] Furthermore, the data domain list, measurement point list, and configuration mapping table include:

[0009] The data domain list includes the data domain name, data management unit, data residence location, and data access boundary; the measurement point list includes the measurement point identifier, acquisition frequency, channel number, and sampling time range; the configuration mapping table includes the field units, value scope, and value domain boundary.

[0010] Furthermore, the process of generating a one-time session token also includes:

[0011] Before generating a one-time session token, the version number of the access constraint policy is compared with the policy library snapshot number for consistency. If the version number is earlier than the current effective version number of the policy library, a fast synchronization path is triggered and token generation is paused to ensure policy consistency.

[0012] Furthermore, the process of generating a one-time session token, binding the token value to the session number, associating it with the evidence preservation strategy pointer, and completing the policy snapshot fixation and validity period writing on the contract side to obtain the session registration record includes:

[0013] The token binding process includes binding the access field set, evidence storage policy pointer, version number, session number and token value, and establishing an access field mask; the access field mask is formed by encoding uniform field names in a fixed order, and is used to control channel distribution and payload channel field pruning.

[0014] Furthermore, the process of evidence preservation strategies also includes:

[0015] The evidence preservation policy association is used to dereference the evidence preservation policy pointer in the access constraint policy to the three elements of evidence retention scope, retention duration and retention location, and to suspend token registration when dereferencing fails, so as to ensure that the evidence policy is traceable.

[0016] Furthermore, the process of generating a one-time session token, binding the token value to the session number, associating it with the evidence preservation strategy pointer, and completing the policy snapshot fixation and validity period writing on the contract side to obtain the session registration record also includes:

[0017] When importing the session token package to verify the smart contract registration entry, the token value and session number are first checked for uniqueness. After the check is passed, the token is written to the session table and the call frequency counter and call window counter are initialized.

[0018] Furthermore, policy snapshot persistence includes:

[0019] Policy snapshot solidification involves writing the access constraint policy version number, evidence preservation policy version number, and access field mask into the policy snapshot table of the contract, and establishing a one-to-one mapping with the session table through the session number for subsequent traceability and governance archiving.

[0020] Furthermore, the process of constructing zero-knowledge proofs and assembling witness materials, verifying them using both commitment values ​​and hash digests within a verifiable session smart contract, and generating events also includes:

[0021] The system executes two parallel paths: commitment consistency verification and time anchor consistency verification, and generates a verification summary, which includes a list of passed items, a list of rejected items, and a list of abnormal items.

[0022] Furthermore, the process of registering failure evidence in the failure evidence table for failed entries and creating a blacklist placeholder for the associated token, and generating a verification result record, also includes:

[0023] The failure evidence generation path is used to read structural evidence from the witness material set of the evidence material package, bind the failed items with the structural evidence information to generate failure evidence units, and register them in the contract failure evidence table.

[0024] Furthermore, the process of generating verification result records also includes:

[0025] The verification results record includes the count of passed entries, the count of rejected entries, and the count of abnormal entries, and is bound to the session number, contract version, and policy version metadata, which serve as inputs for subsequent end-to-end key negotiation and control channel establishment.

[0026] The key innovations of this invention include:

[0027] (1) Based on the process of verification before acquisition, the commitment value and hash digest are used to verify and generate events in the verifiable session smart contract. For the failed entries, failure evidence is registered in the failure evidence table and a blacklist is created for the associated tokens, forming a contract-side governance closed loop after source matching verification, time anchor alignment and link consistency verification.

[0028] (2) Based on context legality verification and policy mapping, register the access constraint policy version number, extract role, purpose and time window constraints from the access constraint policy, execute one-time session token generation and token value binding with session number and evidence preservation policy pointer association, and complete policy snapshot solidification and validity period writing on the contract side to form a session-level integrated carrier of token and access constraint policy.

[0029] (3) Naming, time anchor registration and de-identification, commitment value and hash digest calculation, and unified field encoding are performed on the obtained data domain list, test point list and configuration mapping table. The minimum retrieval index key and submission batch unit are generated according to the domain identifier, test point identifier and time range. Only the on-chain index record structure is generated. After the end-to-end key negotiation and control channel is established, the payload channel is established according to the access field mask and time window constraint and the data is minimized. Only the digest metadata is returned for abnormal fragments and the result is sealed with the session key. The transaction log and token consumption record are registered and the governance archive structure containing policy tightening suggestions is output.

[0030] The following are its main beneficial effects:

[0031] (1) In response to the problem of the disconnect between evidence retention and failure handling in the background technology, the verification results after source matching verification, time anchor alignment and link consistency verification are directly recorded and traced through dual-channel verification of commitment value and hash digest and event generation. The failure evidence of the failed items and the blacklist are recorded in the same contract. The operation link forms a continuous process from verification to governance, which is suitable for cross-entity sharing and controlled access scenarios.

[0032] (2) To address the issue of the lack of versioned association between access constraints and session states, the system binds one-time session tokens to access constraint policies and evidence preservation policy pointers under the session number. Combined with policy snapshot solidification and validity period writing, authorization, invocation, and auditing are linked within the same session carrier. The system can maintain the correspondence between policies and tokens under time window constraints and invocation frequency constraints, and is suitable for fine-grained access management for multiple roles and purposes.

[0033] (3) To address the issues of inconsistent data domain and measurement point caliber and unclear plaintext exposure boundaries, the minimum on-chain data is achieved by generating only the on-chain index record structure. Under the architecture of separating the control channel and the load channel, the minimum data retrieval and result sealing are implemented according to the access field mask and time window constraints. Abnormal fragments are replaced with plaintext return using digest metadata. Transaction logs and token consumption records are registered synchronously and form a governance archive structure, so that the collection-alignment-registration-data retrieval-sealing-archiving form a consistent link, which is suitable for controlled transmission and auditing scenarios of power data sharing. Attached Figure Description

[0034] Figure 1 A flowchart illustrating a blockchain-based secure sharing method for power data, provided as an embodiment of this application;

[0035] Figure 2 A flowchart illustrating step S100 provided in an embodiment of this application;

[0036] Figure 3 A flowchart illustrating step S200 provided in an embodiment of this application;

[0037] Figure 4 A flowchart illustrating step S300 provided in an embodiment of this application;

[0038] Figure 5 This is a flowchart illustrating step S400 provided in an embodiment of this application. Detailed Implementation

[0039] Example 1: Refer to Figure 1 This is a flowchart illustrating a blockchain-based method for secure sharing of electricity data, provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0040] S100: Obtain the data domain list, measurement point list and configuration mapping table, perform naming standardization, time anchor registration and de-identification, commitment value and hash digest calculation, field unified encoding processing, and form a fixed field sequence with unified field name / dimension / caliber. Generate the minimum retrieval index key and submission batch unit according to domain identifier / measurement point identifier / time range, and generate on-chain index record structure.

[0041] S200: Perform context legality verification, policy mapping and access constraint policy version number registration, extract role / purpose / time window constraints from access constraint policy, execute one-time session token generation and token value binding with session number and evidence preservation policy pointer association, and complete policy snapshot solidification and validity period writing on the contract side to obtain session registration record;

[0042] S300: Perform source matching verification, time anchor alignment and link consistency verification, construct zero-knowledge proof and assemble witness materials, verify and generate events in the verifiable session smart contract according to the commitment value and hash digest dual channels, register failure evidence in the failure evidence table for failed entries and create a blacklist placeholder for associated tokens, and generate verification result records.

[0043] S400: Perform end-to-end key negotiation and control channel establishment, issue policies according to access field mask and time window constraints, establish payload channels and minimize data retrieval, return only digest metadata for abnormal fragments and seal the results with session keys, register transaction logs and token consumption records, and output a governance archive structure containing policy tightening suggestions.

[0044] like Figure 2 As shown, Figure 2 This is a flowchart illustrating step S100 provided in an embodiment of this application. Step S100 includes at least steps S110-S130:

[0045] S110. Obtain the data domain list, measurement point list and configuration mapping table, perform naming standardization processing, time anchor point registration processing and de-identification processing to obtain the preprocessed data packet;

[0046] During implementation, the data domain list, measurement point list, and configuration mapping table are first retrieved from the pre-configuration. The data domain list lists the names of the data domains participating in the sharing, the data management unit, the data residence location, and the data access boundaries. The measurement point list lists the acquisition measurement point identifiers, acquisition frequencies, channel numbers, and sampling time ranges on the power business side. The configuration mapping table lists the correspondence between the field names of each business system and the unified field names, including the field dimensions, value scope, and value range boundaries. Specifically, the aforementioned three inputs are used as the initial inputs for the same session, and the session number and trigger time are registered when the data access thread is created. The data domain list is scanned domain by domain, and the connection parameters and access methods of each data domain are read. Combined with the measurement point entries bound to the data domain in the measurement point list, a set of measurement points to be processed is formed. When the set is generated, duplicate measurement points are deduplicated and merged, and the duplicate entry number and its source data domain identifier are recorded in the log area. The naming convention process then proceeds to the naming standardization stage. This stage maps field names from different systems to unified field names. Specifically, for each measurement point to be processed, the target field name is retrieved from the configuration mapping table. If a mapping is missing, the missing record registration and manual supplementation channel is triggered, and subsequent actions for that measurement point are paused and suspended in the error queue. After the field mapping is completed, the field units are standardized. For fields with multiple measurement standards, the values ​​are converted and labeled according to the standard priority recorded in the configuration mapping table.

[0047] The time anchor registration process begins after the naming convention processing is completed. Time anchor registration aligns time stamps from different sources to a unified time base. During implementation, the sampling time range and sampling frequency are read from the measurement point list to generate a time scale sequence. Time zone conversion and accuracy unification are performed on the timestamps reported by the data domain. When a discrepancy is detected between the timestamp accuracy and the configured mapping table, the time completion branch is initiated. Time interpolation is performed using the time difference between adjacent samples and sampling frequency constraints, and the interpolation interval is registered in the session exception segment record. After time anchor registration is complete, a session number, domain identifier, measurement point identifier, and time base identifier are appended to each record, forming an aligned record unit.

[0048] Following this, de-identification is performed. De-identification desensitizes identifiers that directly point to individuals or organizations without altering their business meaning. Specifically, irreversible replacement and definition retention are performed on record units containing sensitive fields such as user identifiers, device serial numbers, and organization codes. For fields requiring association in subsequent processes, a mapping table is used to generate derived identifiers, and the mapping relationships are stored in a controlled area; these mapping relationships are not entered into the on-chain record. During de-identification, if any sensitive fields are not explicitly defined in the configuration mapping table, these fields are added to a temporary sensitive field table and output to the configuration review queue at the end of the session. After de-identification, the field order of the record unit is standardized, unifying field names, units, definitions, time anchors, and derived identifiers to form a fixed field sequence.

[0049] At the end of the above processing chain, all processed record units are packaged at the session level to form a preprocessing data packet. The preprocessing data packet includes a unified field record area, an abnormal fragment record area, a mapping relationship controlled area, and a session metadata area; the unified field record area carries the direct input for subsequent digests and commitments. To maintain chain continuity, an output pointer is written at the session end hook, explicitly specifying the preprocessing data packet as the output field name for use in the next step, and noting in the process that this output field name enters the preprocessing data packet in S120. Simultaneously, in the cross-main step prompt, the domain identifier and time base identifier in the session metadata area are registered to the context cache that subsequent main steps need to reference, for retrieval in the access constraint mapping and session registration in S200, without changing the output boundary of this step.

[0050] S120. Extract the metadata field set and content digest from the preprocessed data packet, perform commitment value calculation, hash digest calculation and field unified encoding, and generate on-chain index candidates;

[0051] During implementation, the processing thread reads the preprocessed data packet, parses the first segment of the unified field record area, and extracts the metadata field set and content summary related to the on-chain index. The metadata field set includes the unified field name, unit identifier, caliber identifier, domain identifier, measurement point identifier, time range, and session number. The content summary is a set of summary entries after segmenting, sampling, and dividing the recorded content into segments. Specifically, the preprocessed data packet is loaded into the summary generator, which generates summary entries according to a fixed window or event boundary. The start and end times of the segment, the number of samples, and the field coverage range are recorded within the summary entries. When an imputation or missing marker is detected in the abnormal segment record area, the marker is written into the extended field of the summary entry for subsequent commitment and structured input.

[0052] After the metadata field set and content digest extraction are completed, the commitment value calculation and hash digest calculation stages begin. Commitment value calculation is the process of generating an irreversible commitment for a digest entry without exposing its original value. To ensure the stability of the processing chain, digest entries are first uniformly encoded. This encoding combines uniform field names with information such as units, scope, and time anchors into a stable sequence representation; this sequence representation serves as the standard order for commitment input. Next, the commitment value is calculated for the uniformly encoded digest entries, and a commitment list is generated at the session level. This list includes the entry number, commitment value, and digest entry location information. Hash digest calculations are performed on the digest entries in parallel. The hash digest calculation uses a digest algorithm family number and rotation strategy number consistent with those registered in the platform's security domain. These two numbers are registered in the session metadata area and are not publicly accessible on-chain fields. A one-to-one correspondence verification is performed between the hash digest obtained for each digest entry and its corresponding commitment value. Inconsistencies are recorded in the verification sub-area of ​​the session anomaly fragment recording area, and the entry is paused from proceeding to the next step.

[0053] The unified field encoding maintains consistency before and after the commitment and hashing phases. The encoding includes unified field names, unit identifiers, caliber identifiers, domain identifiers, measurement point identifiers, and time anchors, providing a stable encoding prefix for subsequent on-chain index candidate generation. After all digest entries have completed commitment value and hash digest calculations, entry-level commitment-digest pairs are generated, and the session-wide commitment and digest lists are merged into a precursor set for on-chain index candidates. The candidate generator then performs entry sorting, cross-segment merging, and boundary pruning on the precursor set, removing duplicate entries with overlapping time ranges and identical field coverage. The merged entries are then written into the on-chain index candidates. For entries with anomaly segment markers, anomaly marker bits and a brief description of the anomaly reason are appended to the candidate; the anomaly reason description comes from the session's anomaly segment record area.

[0054] At the end of the candidate generation phase, a session-level index header is added to the on-chain index candidates. This header records the session number, domain identifier, index generation time, and the number of candidate entries. This index header, along with the candidate entries, forms the structured payload of the on-chain index candidates. To maintain a single exit point in the processing chain, the output field name for this step is explicitly defined as "on-chain index candidate" at the session-level output stage. At the end of processing, the on-chain index candidates are submitted to the next step's processing queue, serving as the sole input source for the on-chain index candidates of S130. Simultaneously, in the cross-main step hint, the session number and domain identifier are overwritten into the context cache for use during context validity verification and policy mapping in S200, without altering the output set boundaries of this step.

[0055] S130. Generate a minimum search index for the on-chain index candidates, format and prepare the on-chain index record for submission, and generate the on-chain index record structure.

[0056] During implementation, on-chain index candidates are read from the pending queue. The process begins with a minimum retrieval index generation sub-process, which compresses publicly available on-chain fields while meeting the information requirements for retrieval and verification. Specifically, each candidate entry is read for its unique encoding prefix, commitment value, hash digest, time range, and domain identifier. A minimum retrieval index key is generated according to the platform's index design specifications. This key contains a compressed representation of the domain identifier, test point identifier, and time range, and establishes a reference relationship with the commitment value and hash digest. If a candidate entry contains an anomaly flag, the flag is recorded in the extended segment of the index key, pointing to the location of the session anomaly fragment record area, without disclosing specific anomaly details on-chain. Subsequently, window-level aggregation is performed on mergeable entries within adjacent time ranges for the same test point. Entries without consecutive anomaly flags and with consistent field coverage are merged into a single index unit, reducing the number of on-chain index keys. The merging process records a list of entry numbers before merging in the submission preparation information area.

[0057] After generating the minimum retrieval index, the on-chain index record formatting stage begins. This stage assembles the minimum retrieval index key, commitment value, and hash digest into a writable on-chain data structure. During implementation, a record container is created according to the on-chain data structure definition. For each index unit, the index key, commitment value, hash digest, and session number are written. Domain identifiers and test point identifiers are placed into the structured retrieval domain to support subsequent contract-side retrieval. For index units containing anomaly flags, an anomaly flag bit and a controlled area reference pointer are additionally written. After formatting, a consistency check is performed on the record container, including field existence, value range verification, and encoding consistency verification. Records that do not meet the checks are returned to the candidate generator reconstruction queue and recorded in the error log area of ​​the current session.

[0058] During the submission preparation phase, submission batch units are generated for the verified record containers. Each submission batch unit records the batch number, number of records, generation time, and submission target, along with a submission digest. When there are multiple record containers, batches are divided according to the link strategy of the submission target, prioritizing record containers with the same domain identifier and the same time range into the same batch. To avoid inconsistencies at the submission boundaries, a batch-level verification digest is calculated for each batch and recorded in the submission digest. Subsequently, the submission batch units are placed into the submission waiting queue, ready for consumption by on-chain write services.

[0059] After the three-stage processing of this step is completed, an on-chain index record structure is constructed. The on-chain index record structure consists of a minimum set of search indexes, a set of record containers, and a submission batch unit. The session number and domain identifier are written to the structure header, forming a complete structure that can be written on the chain. At the process exit, the output field name of this step is explicitly stated as the on-chain index record structure, and its input position in subsequent main steps is marked. Specifically, the on-chain index record structure is directly consumed by the on-chain index record structure of S210 for context validity verification, policy mapping, and version number registration. To maintain continuity across main steps, the batch number and generation time of the submission batch unit are synchronously registered in the context cache during output, serving as a source of reference information in subsequent session registration records and verification result records, without changing the output field name and data boundaries of this step.

[0060] In summary, the technical effects of this step are as follows: by transforming preprocessed data packets into on-chain index candidates and generating on-chain index record structures step by step, the data is standardized and compressed from within the domain to the on-chain index, and standardized input that can be retrieved, verified and submitted is provided to subsequent steps without exposing the original data content.

[0061] like Figure 3 As shown, Figure 3 This is a flowchart illustrating step S200 provided in an embodiment of this application. Step S200 includes at least steps S210-S230:

[0062] S210. Obtain the on-chain index record structure, perform context validity verification, policy mapping, and version number registration to obtain the access constraint policy.

[0063] The inputs for this step are the on-chain index record structure and the context cache established in the previous main step. The on-chain index record structure consists of a minimum set of search indexes, a set of record containers, and submission batch units. The context cache contains session metadata such as session number, domain identifier, test point identifier range, and generation time. Specifically, the on-chain index record structure is loaded into the session view of the policy orchestration engine. During loading, the structural integrity of the record containers is statically checked, and the batch number and generation time of the submission batch units are compared for time sequence compliance. If a record container is missing a required search domain or the submission batch unit has a time reversal, the non-compliant container number and abnormal batch number are registered in the error log area of ​​this session, and the batch is removed from the subsequent mapping path. The context validity verification process in this step first revolves around the request context provided by the caller. The request context consists of role identifier, purpose description, call frequency request, and time window request, all submitted in a structured field format. The strategy orchestration engine retrieves the session number and domain identifier from the context cache, performs a consistency match between the role identifier in the request context and the platform's role dictionary. If the role dictionary is missing or the role status is frozen, the role identifier is added to the pending review list and a rejection branch record is generated in the session view. If the purpose description field contains an unregistered purpose enumeration value, a purpose supplementation prompt is generated and the process is blocked from entering the mapping processing link. Furthermore, a boundary comparison is performed between call frequency requests and time window requests. This boundary comparison is based on the platform's call frequency upper limit table and time window upper limit table. If an out-of-bounds error occurs, the out-of-bounds item is recorded and the process is rolled back to the requester's parameter revision channel. After completing the above verification, the strategy orchestration engine enters the strategy mapping processing, which maps valid roles, purposes, time windows, and call frequencies to a set of access constraint items. During mapping, the domain identifier, measurement point identifier range, and minimum retrieval index key are used as constraints to limit the space. The access field set is pruned according to the priority order: domain-level constraints first, measurement point-level constraints second, and session-level constraints last. Fields not within the constraint space are removed from the candidate set, and the removal record is marked with a unified field name and reason for removal. Policy mapping also includes matching evidence preservation policies. Evidence preservation policies specify the scope, duration, and location of evidence retention in subsequent links of this session. During mapping, the purpose category in the purpose description is matched with the platform's evidence preservation policy library. If multiple evidence preservation policies exist for the same purpose category, the priority policy is selected based on role-level priority, and the unselected policy number is written to the redundant policy list. The redundant policy list is not included in downstream session registration. After the policy mapping process is completed, the version number registration process begins. The version number registration process generates a unique version number for the set of access constraint items and establishes a pointing relationship with the version number of the evidence preservation policy. When generating the version number, the generation time, generation node, and the snapshot number of the policy library participating in the mapping are recorded simultaneously to form a traceable versioned registration entry.For removed and rejected branches, the version number registration process does not perform version number allocation; it only registers the rejection reason and rejection time. After the above processing, the policy orchestration engine outputs an access constraint policy. This access constraint policy consists of role constraints, usage constraints, time window constraints, call frequency constraints, access field sets, and evidence preservation policy pointers, along with version number, generation time, and session number as metadata. The output field name for this step is "Access Constraint Policy." This access constraint policy is directly read by the access constraint policy in the next step, S220, for one-time session token generation, token binding, and evidence preservation policy association. Simultaneously, the version number in the access constraint policy is cross-referenced in the control channel distribution and governance archiving of subsequent main steps, without changing the output boundaries of this step.

[0064] S220. Extract role constraints, purpose constraints, and time window constraints from the access constraint policy, perform one-time session token generation, token binding, and association with the evidence preservation policy to generate a session token package.

[0065] The inputs for this step are the access constraint policy and the platform's token issuance parameter library. The token issuance parameter library records the token generation algorithm family number, token validity period construction rules, conflict handling rules, and revocation list synchronization rules. Specifically, before entering the one-time session token generation, the token service submodule checks the consistency between the access constraint policy version number and the policy library snapshot number. If it detects that the access constraint policy version number is earlier than the current effective version number of the policy library, it marks the access constraint policy as needing backtracking verification and returns to the policy orchestration engine to trigger the fast synchronization path. The token generation action does not proceed until the fast synchronization is completed. The token generation action retrieves the role identifier and role-level permission set from the role constraint item, the usage category and usage description from the usage constraint item, and the start time and end time from the time window constraint item, and links them with the call frequency constraint item to determine the maximum number of calls for this session. The token generation action calculates the validity period according to the validity period construction rules of the token issuance parameter library, and maps the time window constraint item and the maximum number of calls to the session attribute segment of the token, forming a session attribute description bound to the session number. Following this, token uniqueness allocation is performed. Candidate token values ​​are created according to the token generation algorithm family number, and conflict retrieval and revocation list verification are conducted on these candidate token values. In cases of conflict or revocation, new candidates are continuously generated and verified until a conflict-free and unrevoked token value is generated. After token value allocation, token binding processing begins. This process binds the access field set, evidence storage policy pointer, version number, session number, and token value to form a complete token binding description. During binding, an access field mask is created for the token. This mask is generated by encoding the uniform field names in the access field set in a fixed order and is directly referenced during subsequent control channel distribution and payload channel pruning. The token binding process also writes to the call frequency counter and call window counter. The call frequency counter is written back by the contract side each time a request is received, and the call window counter is reset to zero when the time window expires, without cross-session accumulation. The evidence preservation policy association is initiated after the token binding process is completed. This association dereferences the evidence preservation policy pointer in the access constraint policy to the three elements of evidence retention scope, retention duration, and retention location, and writes them into the token's evidence segment. If the dereferencing of the evidence preservation policy pointer fails, the token is marked as pending evidence policy backfilling, and its entry into subsequent contract registration is suspended, awaiting recovery and re-association from the policy library side. To support subsequent traceability, the token service submodule performs session-level accounting of the token value and session number after token generation, recording the accounting time, accounting node, and the issue parameter library usage number. After the above processing, a session token package is generated. The session token package consists of the token value, session attribute description, access field mask, evidence segment, call frequency counter, call window counter, and version number, and is written to the pending registration cache along with the session number and domain identifier.The output field of this step is named Session Token Packet. The Session Token Packet is directly consumed by the Session Token Packet in the next step S230 and is used for contract registration, validity period writing, and policy snapshot fixing. At the same time, the access field mask in the Session Token Packet is used in the field pruning stage of the control channel distribution and payload channel of the subsequent main steps, without changing the output set of this step.

[0066] S230. Register the session token package under a contract, write its validity period, and solidify the policy snapshot to generate a session registration record.

[0067] The inputs for this step are a session token package and a verifiable session smart contract. The verifiable session smart contract has registered its contract address, contract version, and log topic during the deployment phase, and has functions such as session registration, policy query, token verification, and revocation recording. Specifically, the session token package is imported into the registration entry point of the contract interaction layer. The registration entry point first performs a uniqueness check on the token value and session number within the contract. If the token value has already been registered in this contract version, the registration entry point returns a duplicate identifier and terminates the current write operation. After the uniqueness check is passed, the registration entry point reads the start and end dates of the time window from the session attribute description, writes the validity period into the contract's session table, and initializes the call frequency counter and call window counter to zero. The initialization action also binds the call frequency limit and time window constraint so that counting and expiration processing can be performed in subsequent calls. The second stage of the contract registration process is policy snapshot solidification. Policy snapshot solidification is used to write the version numbers of the access constraint policy, the evidence preservation policy, and the access field mask into the contract's policy snapshot table. The policy snapshot table and the session table are mapped one-to-one through the session number. Before writing to the policy snapshot table, the registration entry point checks the pending status of the evidence policy in the session token package. If this status exists, the token is redirected to the backfill queue and a waiting flag is returned in this contract registration, without generating a session registration record. After policy snapshot solidification is completed, the registration entry point enters the event posting stage. The event posting stage generates an event log for this registration. The event log includes the registration time, registration node, contract version, token value, and session number, and is published to the on-chain event stream through the log topic for subsequent governance archiving and traceability. For successfully registered sessions, the registration entry point writes the initial status of the token value to "not listed" in the contract's blacklist table and creates a revocation record placeholder to support subsequent failed branch governance write-back. The third stage of the registration process is writing the session's searchable items. This involves combining the digest of the access field mask with the session number and domain identifier as the search key, and writing it into the contract's search index table. This allows the control channel to quickly locate the session using the search key when the policy is issued. The search index table includes references to the submission batch number and generation time, both derived from information registered in the context cache in the preceding main step. After completing these three stages, the contract interaction layer returns the session registration result and generates a structured record containing the registration result as the session registration record. This record includes the session number, token value, validity period, policy snapshot reference, search key, and event log location information. For tokens in the backfill queue, the contract interaction layer maintains a status polling logic. After successful backfilling of the evidence preservation policy, it automatically retryes registration and generates a session registration record in the same format. To ensure seamless connection, the session registration record is synchronously registered in the context cache when written back to the application side, serving as input for subsequent proof and verification processes.The output field of this step is named Session Registration Record. This record is directly read by the Session Registration Record in the next main step, S310, for source matching verification, time anchor alignment, and link consistency checking. It also serves as the base session reference during subsequent control channel establishment and policy issuance. The technical effects of steps S210-S230 can be summarized as follows: By verifying the contextual legality of the on-chain index record structure and mapping refined policies, combined with version number registration and the generation and binding of one-time session tokens, and then through contract-side registration, validity period writing, and policy snapshot solidification, a session-level entry point and policy carrier that can be directly consumed by subsequent proof and data retrieval links are formed, achieving a stable connection and controlled call starting point from the index to the session.

[0068] In one embodiment, the first part is the input source, which is an on-chain index record structure from S100. This structure includes a minimum set of search indexes, a set of record containers, and a submission batch unit, combined with session metadata such as session number, domain identifier, test point identifier range, and generation time from the context cache. The processing chain first loads the on-chain index record structure into the session view of the policy orchestration engine, performs a static check on the structural integrity of the record containers, and compares the temporal compliance of the submission batch units. If a record container is missing a required search domain or the submission batch unit has a time reversal, the non-compliant container number and abnormal batch number are registered in the error log area of ​​this session, and the batch is removed from the subsequent mapping path. Subsequently, context legality verification is performed, focusing on the request context provided by the caller. The request context consists of role identifier, purpose description, call frequency request, and time window request, all submitted in a structured field format. The strategy orchestration engine retrieves the session number and domain identifier from the context cache, performs a consistency match between the role identifier in the request context and the platform's role dictionary. If the role dictionary is missing or the role status is frozen, the role identifier is added to the pending review list and a rejection branch record is generated in the session view. If the purpose description field contains an unregistered purpose enumeration value, a purpose supplementation prompt is generated and the process is blocked from entering the mapping processing link. Furthermore, a boundary comparison is performed between call frequency requests and time window requests. This boundary comparison is based on the platform's call frequency upper limit table and time window upper limit table. If an out-of-bounds error occurs, the out-of-bounds item is recorded and the process is rolled back to the requester's parameter revision channel. After completing the above verification, the strategy orchestration engine enters the strategy mapping processing, which maps valid roles, purposes, time windows, and call frequencies to a set of access constraint items. During mapping, the domain identifier, measurement point identifier range, and minimum retrieval index key are used as constraints to limit the space. The access field set is pruned according to the priority order: domain-level constraints first, measurement point-level constraints second, and session-level constraints last. Fields not within the constraint space are removed from the candidate set, and the removal record is marked with a unified field name and reason for removal. Policy mapping also includes matching evidence preservation policies. Evidence preservation policies specify the scope, duration, and location of evidence retention in subsequent links of this session. During mapping, the purpose category in the purpose description is matched with the platform's evidence preservation policy library. If multiple evidence preservation policies exist for the same purpose category, the priority policy is selected based on role-level priority, and the unselected policy number is written to the redundant policy list. The redundant policy list is not included in downstream session registration. After the policy mapping process is completed, the version number registration process begins. The version number registration process generates a unique version number for the set of access constraint items and establishes a pointing relationship with the version number of the evidence preservation policy. When generating the version number, the generation time, generation node, and the snapshot number of the policy library participating in the mapping are recorded simultaneously to form a traceable versioned registration entry.Formula ① is used to calculate the context validity verification score, which is based on the comparison between the request context and the platform's upper limit table. Formula ①:

[0069]

[0070] in: This represents the role verification score, which can be either 0 or 1. It is derived from the matching result between the role identifier in the request context and the platform's role dictionary. This represents the purpose verification score, which can be 0 or 1, and is derived from the matching results between the purpose description in the request context and the platform's purpose dictionary. This represents the call frequency verification score, with a value of 0 or 1, derived from the comparison result between the call frequency requests and the call frequency upper limit table; This represents the verification score for the time window, with a value of 0 or 1, derived from the comparison result between the time window request and the time window upper limit table; This represents the overall verification score, with a value of 0 or 1.

[0071] Extract the role identifier from the data source request context and record it as The platform extracts the character status from the character dictionary and uses it for calculation. Similarly, other verification scores are calculated from other data sources, ultimately forming Formula ①. Formula ① This is used as an intermediate quantity in Formula ②. Formula ② is used to calculate the number of access fields, which is based on the product of the verification score and the number of constraint space fields. Formula ②:

[0072]

[0073] in: Representing the constrained space The number of fields in the data, which takes positive integer values, comes from the constraint space defined by the domain identifier, the range of the measurement point identifier, and the minimum retrieval index key; Indicates the number of accessible fields; the value is a non-negative integer.

[0074] The number of fields extracted from the data source constraint space and denoted as From formula ① Calculated Formula ② As one of the output metrics, the output field of this step is named "Access Constraint Policy," which is input to the access constraint policy in the next step, S220.

[0075] Part Two: Building upon the aforementioned access constraint policies, this section extracts role constraints, purpose constraints, and time window constraints, and performs one-time session token generation, token binding, and evidence storage policy association. The token service submodule performs a consistency check between the version number of the access constraint policy and the policy library snapshot number. If the version number of the access constraint policy is detected to be earlier than the current effective version number of the policy library, the access constraint policy is marked as requiring backtracking verification, and the system returns to the policy orchestration engine to trigger a fast synchronization path. The token generation action is not initiated until the fast synchronization is complete. The token generation action extracts the role identifier and set of role-level permissions from the role constraints, the purpose category and purpose description from the purpose constraints, and the start and end times from the time window constraints. It also links these with the call frequency constraints to determine the maximum number of calls allowed in this session. The token generation action calculates the validity period according to the validity period construction rules of the token issuance parameter library, and simultaneously maps the time window constraints and the maximum number of calls to the session attribute segment of the token, forming a session attribute description bound to the session number. Following this, token uniqueness allocation is performed. Candidate token values ​​are created according to the token generation algorithm family number, and conflict retrieval and revocation list verification are conducted on these candidate token values. In cases of conflict or revocation, new candidates are continuously generated and verified until a conflict-free and unrevoked token value is generated. After token value allocation, token binding processing begins. This process binds the access field set, evidence storage policy pointer, version number, session number, and token value to form a complete token binding description. During binding, an access field mask is created for the token. This mask is generated by encoding the uniform field names in the access field set in a fixed order and is directly referenced during subsequent control channel distribution and payload channel pruning. The token binding process also writes to the call frequency counter and call window counter. The call frequency counter is written back by the contract side each time a request is received, and the call window counter is reset to zero when the time window expires, without cross-session accumulation. The evidence preservation strategy association is initiated after the token binding process is completed. This association dereferences the evidence preservation strategy pointer in the access constraint policy to the three elements of evidence retention scope, retention duration, and retention location, and writes them into the token's evidence segment. If the evidence preservation strategy pointer dereferencing fails, the token is marked as awaiting evidence policy backfilling, and its entry into subsequent contract registration is suspended, pending recovery and re-association from the strategy library side. Formula ③ is used to calculate the token's validity period, which is based on the start and end time difference of the time window constraint item. Formula ③:

[0076]

[0077] in: This represents the start time of the time window, and its value is a real number derived from the start time in the time window constraint. This represents the end time of the time window, and its value is a real number derived from the end time in the time window constraint. This indicates the token's validity period and can be a non-negative real number.

[0078] Extract start and end times from the data source time window constraints and calculate Formula ③ Used in Formula ④. Formula ④ generates the token value, which is based on a linear congruent algorithm using the session number and the token issuance parameter library. Formula ④:

[0079]

[0080] in: This represents the session ID, which is an integer derived from the session ID in the context cache. and It is a constant, taking integer values, and is derived from parameters in the token issuance parameter library; It is a large prime number, and its value is an integer, which comes from the token issuance parameter library; This represents the token value, which can be an integer.

[0081] Calculated from the data source session number and token issuance parameter library Formula ④ Used in formula ⑤. The output field name of this step is Session Token Packet, which is input to the Session Token Packet in the next step S230.

[0082] Part Three: Following the aforementioned session token package, contract registration, validity period writing, and policy snapshot solidification are performed. The session token package is imported into the registration entry point of the contract interaction layer. The registration entry point first performs a uniqueness check on the token value and session number within the contract. If the token value has already been registered in this contract version, the registration entry point returns a duplicate flag and terminates the writing process. After the uniqueness check is passed, the registration entry point reads the start and end dates of the time window from the session attribute description, writes the validity period into the contract's session table, and initializes the call frequency counter and call window counter to zero. The initialization action also binds the call frequency limit and time window constraint for counting and expiration handling during subsequent calls. The second stage of the contract registration process is policy snapshot solidification. Policy snapshot solidification is used to write the version number of the access constraint policy, the version number of the evidence preservation policy, and the access field mask into the contract's policy snapshot table. The policy snapshot table and the session table establish a one-to-one mapping through the session number. Before writing to the policy snapshot table, the registration entry point checks the pending status of the evidence policy in the session token package. If the pending status exists, the token is redirected to the backfill queue and a waiting flag is returned in this contract registration, without generating a session registration record. After the strategy snapshot is finalized, the registration entry point enters the event posting stage. This stage generates an event log for this registration, containing the registration time, registration node, contract version, token value, and session number. This log is then published to the on-chain event stream via a log topic for subsequent governance archiving and traceability. For successfully registered sessions, the registration entry point writes the initial status of the token value to "not listed" in the contract's blacklist table and creates a revocation record placeholder to support subsequent failed branch governance write-backs. The third stage of the registration process is writing session searchable items. This involves combining the digest of the access field mask with the session number and domain identifier as the search key and writing it to the contract's search index table. This allows the control channel to quickly locate sessions using the search key when the strategy is issued. The search index table includes references to the submission batch number and generation time, which are derived from information registered in the context cache in the preceding main step. Formula ⑤ is used to calculate the uniqueness metric, which is based on whether the token value has been registered. Formula ⑤:

[0083]

[0084] in: This represents the set of registered token values, which is derived from the session table in the verifiable session smart contract. It is an indicator function; This indicates a uniqueness indicator, with a value of 0 or 1.

[0085] Retrieve the registered token from the data source session table and record it as From formula ④ calculate Formula ⑤ Used in Formula 6. Formula 6 is used to calculate the policy snapshot summary, which is based on the sum of the policy version number and the number of access fields. Formula 6:

[0086]

[0087] in: This represents the access constraint policy version number, which is an integer derived from the version number registration process. This represents the version number of the evidence preservation strategy. It is an integer and is derived from the version number matched by the evidence preservation strategy. This indicates the number of fields accessed, and the value is an integer, derived from formula ②. ; Represents a policy snapshot summary, with values ​​that are integers.

[0088] Calculated from the data source version number and the number of accessed fields Formula 6 Used for policy snapshot solidification. The output field of this step is named Session Registration Record, which is input to the Session Registration Record in the next main step S310. Technical effect summary: By verifying the contextual legality of the on-chain index record structure and fine-grained policy mapping, combined with version number registration and the generation and binding of one-time session tokens, and then through contract-side registration, expiration date writing, and policy snapshot solidification, a session-level entry point and policy carrier that can be directly consumed by subsequent proof and data retrieval links is formed, achieving a stable connection and controlled call starting point from the index to the session.

[0089] like Figure 4 As shown, Figure 4 This is a flowchart illustrating step S300 provided in an embodiment of this application. Step S300 includes at least steps S310-S330:

[0090] S310. Obtain the session registration record, perform source matching verification, time anchor alignment, and link consistency verification to obtain the proof input set;

[0091] This step is initiated when the main process enters the proof phase. Input sources include the domain identifier, session number, search key, policy snapshot reference, and event log location information from the session registration record and context cache. Specifically, the aforementioned session registration record is loaded into the session view of the proof preparer. The role identifier, purpose category, time window start and end, call frequency limit, and access field mask from the session attribute description are read. The version numbers of the access constraint policy and evidence preservation policy are retrieved from the policy snapshot reference, forming the policy-side baseline for this phase. The source matching and verification process first matches the search key in the session registration record. The search key consists of an access field mask summary, session number, and domain identifier. The proof preparer uses this search key to locate the set of items to be verified in the metadata area of ​​the controlled data domain. For each set of items, the access field mask summary is compared with the access field mask in the session registration record. If an inconsistency is found, the item is added to the inconsistency list and suspended in the session view, not proceeding to the subsequent proof construction path. Subsequently, the event log is used to locate the session registration event from the on-chain event stream. The registration time and the current request time are checked to see if they fall within the session time window. If not, an out-of-bounds record is generated and transferred to the governance queue. After source matching, time anchor alignment is performed. This alignment process aligns the timestamps in the entry set with the time reference identifiers generated in the preceding main step. Specifically, the timestamps of each record in the entry set are read, time zone conversion and precision unification are performed, a time scale sequence is generated based on the start and end timestamps in the session attribute description, missing or abnormal timestamps are interpolated or pruned, and the interpolation and pruning intervals are registered in the abnormal fragment area of ​​the proof preparer. After alignment, aligned record fragments are formed. These fragments are bound to the session number, domain identifier, test point identifier, and unified field name, serving as input for subsequent commitment list mapping. Link consistency verification is triggered after time anchor alignment. The verification scope covers the set of access fields, the minimum retrieval index key, and the policy snapshot reference. The proof preparer compares the set of access fields recorded in the policy snapshot table with the field coverage of the local record fragment. Fields exceeding the set are generated as unauthorized entries and removed from the proof path. Then, the domain and test point range of the entry are verified according to the minimum retrieval index key. If a domain mismatch or test point out-of-bounds occurs, the mismatch entry is registered and transferred to the governance queue. At the same time, version consistency is compared with the policy snapshot reference. If the version number of the access constraint policy is earlier than the current effective version number of the policy library, a fast synchronization request is sent to the policy orchestration engine. Before synchronization is completed, the corresponding entry is temporarily stored in the list to be synchronized. After source matching verification, time anchor alignment, and link consistency verification, the proof preparer generates a standardized input set. This set contains the entry index required for commitment mapping, the aligned record fragment, the subset of the access field set, the time window boundary, policy version metadata, and abnormal fragment identifiers, and writes it into a session-level container.The aforementioned container is named the proof input set at the exit of this step, and enters the next step as the output field name of this step. It is directly consumed by the proof input set of S320 to construct zero-knowledge proof materials. The proof input set also registers the session number and policy version metadata in the cross-main step prompt for subsequent control channel distribution and governance archiving reference, without changing the boundary of the output set of this step.

[0092] S320. Extract commitment values, hash digests and time anchors from the proof input set, construct zero-knowledge proofs, assemble proof parameters and encapsulate witness materials to generate proof material packages.

[0093] The inputs for this step are the proof input set and the on-chain index record structure written on-chain in the previous main step. Additionally, it includes metadata descriptions of the proof interface from the verifiable session smart contract (SC). Specifically, the proof builder first performs a commitment mapping between the entry index corresponding to the proof input set and the on-chain index record structure. The commitment mapping reads the commitment value and hash digest registered on-chain for each entry and establishes a one-to-one correspondence with the locally aligned record fragments. If a aligned record fragment is found to lack a corresponding commitment value or hash digest, the entry is registered in the proof builder's gap list, and entry into the proof path is temporarily suspended. After completing the commitment mapping, the proof builder extracts the time window boundaries and time anchors from the proof input set. It combines the time anchors with the start and end times of the record fragments to form a time constraint description. This time constraint description describes the time range covered by the proof, fragment boundaries, and the location of abnormal fragments. The proof parameter assembly begins after the commitment mapping and time constraint description are formed. This assembly process follows the interface conventions of Zero-Knowledge Proof (ZKP), registering the commitment value, hash digest, time constraint description, and a subset of access fields to the parameter set. The parameter set also records policy version metadata and session number for contract-side accounting and traceability. Witness material encapsulation and proof construction proceed in parallel. Witness material encapsulation packages the locally aligned record fragment's summary evidence, anomalous fragment identifier, alignment description, and partial prefix of the search key into a witness material set. The witness material set does not carry the plaintext of the records, only the structural evidence used for contract-side verification. Based on this, the proof builder generates an interactive proof object. The proof object contains a dual-channel verification substructure covering commitment consistency and time anchor consistency, corresponding to the commitment mapping path and the time constraint path, respectively. After construction, the proof object and the witness material set are paired and assembled to form a committable proof unit. For any missing items in the assembly process, the proof builder creates a submission unit to be supplemented and registers a retry plan within the session view. The retry plan records the item index, supplementation window, and replay position. After all proof units are assembled, the proof builder generates a submission description based on the interface metadata description of the verifiable session smart contract. The submission description includes the contract address, function entry point, parameter order, and log topic, and is bound to the session number, forming the structured output of this step. The above output is named "Proof Material Package" at the exit of this step, serving as the output field name for the next step. It is directly consumed by the S330's Proof Material Package for contract-side verification, result accounting, and failure evidence generation. The submission description in the Proof Material Package is referenced by the control channel in the cross-main step prompt, used to record the proof source and proof scope in the subsequent policy issuance phase, without changing the boundary of the output set of this step.

[0094] S330, Verify the supporting materials package using a verifiable smart contract, record the results and generate failure evidence, and generate a verification result record;

[0095] The input for this step is a proof package and a verifiable session smart contract. During the deployment phase, the contract has registered its version, session table, policy snapshot table, retrieval index table, and event log topics, and has exposed the verification entry point. Specifically, the proof package is imported into the verification entry point of the contract interaction layer. The verification entry point first locates the contract address and function entry point based on the submission description, and then performs static verification on the parameter order and type. If the static verification fails, a format error is returned, and a format error ticket is generated on the application side. After the static verification passes, the contract executes two parallel paths on-chain: commitment consistency verification and time anchor consistency verification. The commitment consistency verification starts with the commitment value and hash digest in the proof package and matches them with the corresponding fields in the on-chain index record structure to determine the consistency of the commitment value and hash digest for each entry. The time anchor consistency verification reads the time constraint description in the proof package, compares it with the start and end times of the time window in the session table, and combines it with the set of access fields in the policy snapshot table to determine the match between the proof coverage and the field coverage. The results of the two paths are used to generate a verification summary within the contract. This summary includes a list of passed entries, a list of rejected entries, and a list of abnormal entries. Abnormal entries typically arise from failed retry attempts on the gap list or mismatches between time constraints and policy snapshots. For the passed entries list, the contract publishes a passed event under the event log topic, recording the session number, entry index range, policy version metadata, and contract version. For the rejected entries list, the contract generates a rejected event and writes the rejection reason and policy reference. For the abnormal entries list, the contract enters the failure evidence generation path. The failure evidence generation path reads structured evidence from the witness material set in the evidence material package, bundles the failed entries with the structured evidence information to generate failure evidence units, and registers the location information and session number of the failure evidence units in the contract's failure evidence table. It also creates a blacklist placeholder for the associated token, specifically by creating a status change placeholder for the associated token in the blacklist table for subsequent governance branches to write back. After the contract completes the publication of the three types of events, it enters the result posting stage. Result posting writes the verification summary into the verification field of the session table and registers the version number and timestamp associated with this verification in the policy snapshot table, forming a traceable verification trajectory. If, during the verification process, a session registration record is found to be expired or revoked, the contract directly generates an expiration or revocation event and terminates subsequent posting. Such events trigger revocation record write-back and alarm dispatch in the governance queue. Upon receiving the on-chain execution return, the contract interaction layer generates a structured receipt containing the pass / fail count, rejection count, exception count, event location information, and failure evidence location information, and writes it back to the application side. Upon receiving the structured receipt, the application side constructs a unified result record object. This result record object binds the session number, contract version, policy version metadata, and event location information, forming the output of this step.The outputs described above are named "Verification Result Record" at the exit point of this step. This record serves as the output field name for the subsequent main steps and is directly consumed by the verification result record in S410 for end-to-end key negotiation, control channel establishment, and policy distribution. The failure evidence location information and blacklist status in the verification result record are written into the governance archive structure during the governance archiving phase, without changing the boundaries of the output set for this step. The technical effects of steps S310-S330 can be summarized as follows: After triple verification of source, time, and link, a proof input set is constructed. Then, through zero-knowledge proof construction and witness material encapsulation, submitable proof materials are generated. Finally, parallel verification, event publication, and result accounting are completed on the contract side, outputting a verification result record that can be directly referenced by downstream channels.

[0096] In one embodiment, the first part involves inputting session registration records from S200 and domain identifiers, session numbers, search keys, policy snapshot references, and event log location information from the context cache. The processing chain first loads the session registration records into the session view of the proof preparer, reads the role identifier, purpose category, time window start and end, call frequency limit, and access field mask from the session attribute description, and retrieves the version numbers of the access constraint policy and the evidence preservation policy from the policy snapshot reference to form a policy-side baseline. The source matching and verification process matches the search keys in the session registration records. The search key consists of an access field mask summary, session number, and domain identifier. The proof preparer uses this search key to locate the set of items to be verified in the metadata area of ​​the controlled data domain. For each set of items, the access field mask summary is compared with the access field mask in the session registration record. If an inconsistency is found, the item is written to the inconsistency list and suspended. Subsequently, the event log is used to locate the session registration event from the on-chain event stream. The registration time and the current request time are checked to see if they fall within the session time window. If not, an out-of-bounds record is generated and transferred to the governance queue. After source matching, time anchor alignment is performed. This alignment process aligns the timestamps in the entry set with the time reference identifiers generated in the preceding main step. The timestamps of each record in the entry set are read, time zone conversion and precision unification are performed, and a time scale sequence is generated based on the start and end timestamps in the session attribute description. Missing or abnormal timestamps are interpolated or pruned, and the interpolation and pruning intervals are registered in the abnormal fragment area of ​​the proof preparer. After alignment, aligned record fragments are formed, and each fragment is bound to a session number, domain identifier, measurement point identifier, and unified field name. Link consistency verification is triggered after time anchor alignment. The verification scope covers the access field set, the minimum retrieval index key, and the policy snapshot reference. The proof preparer compares the access field set recorded in the policy snapshot table with the field coverage of the local record fragment. Fields exceeding the set are generated as unauthorized entries and removed from the proof path. Then, the domain and test point range of the entry are verified based on the minimum retrieval index key. If a domain mismatch or test point out-of-bounds occurs, the mismatch entry is registered and transferred to the governance queue. Simultaneously, version consistency is compared with the policy snapshot reference. If the version number of the access constraint policy is earlier than the current effective version number of the policy library, a fast synchronization request is sent to the policy orchestration engine. Before synchronization is complete, the corresponding entry is temporarily stored in the synchronization list. After source matching verification, time anchor alignment, and link consistency verification, the proof preparer generates a standardized input set. Formula ⑦ is used to calculate the source matching score, which is based on the consistency of the retrieval key matching. Formula ⑦:

[0097]

[0098] in: This represents the local search key set, with values ​​being a set of strings derived from the search keys extracted by the proof preparer from the session registration record; This represents a set of reference search keys, with values ​​being a set of strings derived from the search keys of the set of entries to be verified in the metadata area of ​​the controlled data domain. The cardinality of a set, which represents the number of elements, is a mathematical operator. This represents the source matching score, and its value is a real number between [0, 1].

[0099] Extract the search key from the data source session registration record and record it as The reference retrieval key is extracted from the controlled data domain metadata area of ​​the data source and recorded as... Together, they form the formula in ⑦. Formula ⑦ This is used as input to S320 for the proof construction. Formula ⑧ is used to calculate the time anchor alignment error, which is based on the maximum difference between the time tag and the reference time. Formula ⑧:

[0100]

[0101] in: This represents the entry index, which is a positive integer derived from the index number in the entry set. This represents the timestamp of the i-th entry, and its value is a real number derived from the timestamps recorded in the entry set. Represents the base time of the i-th entry, with a real value derived from the time base identifier generated by the preceding main step; This represents the time anchor alignment error, and its value is a non-negative real number. : This represents the function that takes the maximum value.

[0102] Extract time tags from the data source entry set and denote them as follows: The reference time is extracted from the data source time reference identifier and recorded as . Formula ⑧ is calculated. Formula ⑧ Used for formula ⑨. The output field name for this step is the proof input set, which is input into the proof input set of the next step S320.

[0103] Part Two: Building upon the aforementioned proof input set, this part extracts the commitment value, hash digest, and time anchor, and performs zero-knowledge proof construction, proof parameter assembly, and witness material encapsulation. The proof constructor first performs a commitment mapping between the entry index corresponding to the proof input set and the on-chain index record structure. The commitment mapping reads the commitment value and hash digest registered on-chain for each entry and establishes a one-to-one correspondence with the locally aligned record fragments. If a aligned record fragment is found to lack a corresponding commitment value or hash digest, the entry is registered in the proof constructor's gap list, and entry into the proof path is temporarily suspended. After completing the commitment mapping, the proof constructor extracts the time window boundaries and time anchors from the proof input set, combining the time anchors with the fragment start and end times to form a time constraint description. Proof parameter assembly begins after the commitment mapping and time constraint description are formed. This assembly process follows the interface conventions of zero-knowledge proofs, registering the commitment value, hash digest, time constraint description, and a subset of the access field set to the parameter set; the parameter set also records policy version metadata and session number. Witness material encapsulation and proof construction proceed in parallel. Witness material encapsulation packages the locally aligned record fragments' summary evidence, anomalous fragment identifiers, alignment instructions, and partial prefixes of the search key into a witness material set. The proof builder then generates an interactive proof object, containing a dual-channel verification substructure covering commitment consistency and time anchor consistency. After construction, the proof object is paired and assembled with the witness material set to form a submitable proof unit. For any gaps in the assembly process, the proof builder creates supplementary submission units and registers retry plans. Formula 9 is used to calculate the commitment consistency score, which is based on the degree of matching of commitment values. Formula 9:

[0104]

[0105] in: This represents the index of the commitment entry, and its value is a positive integer derived from the index number in the commitment mapping. Represents the j-th local commitment value, which is a real number derived from the commitment value of the record fragment after the proof input set is aligned; This represents the j-th on-chain commitment value, which is a real number derived from the commitment value in the on-chain index record structure. This represents the tolerance error threshold, which is a positive real number derived from system parameters. It is an indicator function that takes the value 1 when the condition is true and 0 otherwise; This represents the commitment consistency score, with a value of 0 or 1.

[0106] The local commitment value is extracted from the input set by the data source and denoted as... The on-chain commitment value is extracted from the on-chain index record structure of the data source and recorded as... Formula 9 is calculated. Formula 9 Use formula ⑧ directly This represents the attenuation coefficient, which is a positive real number derived from system parameters. Formula 10:

[0107]

[0108] in: : Commitment consistency score, with a value of 0 or 1, derived from the calculation result of formula ⑨; Time anchor alignment error, a non-negative real number, derived from the calculation result of formula ⑧; Attenuation coefficient, a positive real number derived from system parameters; : Represents an exponential function; : Prove the parameter weights, which take values ​​of real numbers between [0,1];

[0109] Formula 10 uses Formula 9 And formula ⑧ The weights are calculated using an exponential decay function. (Formula 10) This step is used to verify the parameter assembly. The output field name of this step is "Verification Material Package," which is input to the "Verification Material Package" in the next step, S330.

[0110] Part Three: Building upon the aforementioned proof material package, this part verifies the session smart contract, records the results, and generates failure evidence. The proof material package is imported into the verification entry point of the contract interaction layer. The verification entry point first locates the contract address and function entry point based on the submission description, then performs static verification of the parameter order and type. If the static verification fails, a format error is returned. After the static verification passes, the contract executes two parallel paths on-chain: commitment consistency verification and time anchor consistency verification. Commitment consistency verification starts with the commitment value and hash digest in the proof material package and matches them with the corresponding fields in the on-chain index record structure, determining consistency for the commitment value and hash digest of each entry. Time anchor consistency verification reads the time constraint description within the proof material package, compares it with the start and end times of the time window in the session table, and combines it with the access field set in the policy snapshot table to determine the match between the proof coverage and the field coverage. The results of the two paths generate a verification summary within the contract, including a list of passed entries, a list of rejected entries, and a list of abnormal entries. For the list of passed entries, the contract publishes a passed event under the event log topic; for the list of rejected entries, the contract generates a rejected event; for the list of abnormal entries, the contract enters the failure evidence generation path. The failure evidence generation path reads structured evidence from the witness material set in the evidence material package, bundles the failed entries with the structured evidence information to generate failure evidence units, and registers these units in the contract's failure evidence table; it also creates a blacklist placeholder for the associated token. After publishing the three types of events, the contract enters the result posting stage. Result posting writes the verification summary summary into the verification field of the session table and registers the version number and timestamp associated with this verification in the policy snapshot table. Formula 11 is used to calculate the number of passed entries, which is based on the passed list in the verification summary. Formula 11:

[0111]

[0112] in: This represents the entry index, which takes a positive integer value and is derived from the entry index in the verification summary. This represents the k-th entry, and its value is an entry object derived from the set of entries in the supporting materials package. This indicates a list of approved items, with the value being a collection of items derived from the approved list in the contract verification summary. This indicates counting by entries, with values ​​being non-negative integers; Indicator function.

[0113] The data source is used to verify and summarize the extracted list of items and record them as follows: Formula 11 is calculated. Formula 11 We directly use the intermediate results of formulas ⑨ and ⑩, but here we primarily rely on contract-based judgment. Formula ⑫ is used to generate a failure evidence score, which is based on the weights of rejection and anomalous entries. Formula ⑫:

[0114]

[0115] in: This represents the count of rejected entries, and its value is a non-negative integer derived from the rejection list count in the verification summary. This represents the count of abnormal entries, and its value is a non-negative integer, derived from the abnormal list count in the verification summary. This represents the total number of items, and its value is a positive integer derived from the total number of items in the supporting materials package. The score represents the failure evidence score, and its value is a real number between [0,1].

[0116] Formula 12 uses a similar counting logic to Formula 11, but it applies to failed entries. The data source verifies and summarizes the counts of rejected and abnormal entries, and then calculates the result for Formula 12. Formula 12 Used for generating and archiving failure evidence. The output field of this step is named "Verification Result Record," which is input to the verification result record in subsequent step S410. In summary, the technical effect of this section is as follows: A proof input set is constructed through source matching, time anchor alignment, and link consistency verification. Then, a proof material package is generated through zero-knowledge proof construction and parameter assembly. Finally, parallel verification and result recording are completed on the contract side, forming a traceable verification result record.

[0117] like Figure 5 As shown, Figure 5 This is a flowchart illustrating step S400 provided in an embodiment of this application. Step S400 includes at least steps S410-S430:

[0118] S410. Obtain the verification result record, perform end-to-end key negotiation processing, control channel establishment processing and policy distribution processing to obtain the encrypted control channel;

[0119] The inputs for this step are the verification result record, session registration record, and session ID, domain identifier, search key, and policy snapshot reference from the context cache. The verification result record includes a list of passed entries, a list of rejected entries, a list of abnormal entries, event location information, and failure evidence location information. Specifically, the verification result record is loaded into the session view of the channel orchestrator. First, the list of passed entries is filtered and sorted, with the filtering rule using the session ID and entry index range as the grouping key. Entries in the rejected entry list and the abnormal entry list are removed, forming a channel candidate entry set. After the entry set is constructed, the access field mask and call frequency counter are read from the session registration record. Then, the version number of the access constraint policy and the version number of the evidence preservation policy are obtained from the policy snapshot reference, forming the policy-side baseline required for channel orchestration. End-to-end key negotiation processing starts after the channel candidate entry set is prepared. The negotiation initiator is the platform-side channel management submodule, and the responding end is the requesting session client. The negotiation content includes the key material generation method, session key validity parameters, and renegotiation trigger conditions. Specifically, the channel management submodule generates a negotiation session identifier based on the session number, writes the negotiation session identifier and the policy-side baseline into the negotiation context, and performs validity verification and revocation list lookup on the token value in the session registration record. If successful, a negotiation request is issued. When the responding end returns negotiation acceptance, both parties record the timing marker and node identifier of this negotiation in the negotiation context, and then proceed to the key material generation stage. In the key material generation stage, the key material generation parameter number is read from the security domain of the channel management submodule and matched with the parameter number of the responding end. If the numbers do not match, a parameter degradation loop is triggered. The parameter degradation loop selects a consistent parameter number within an acceptable range and writes the degradation record to the negotiation record area of ​​the session view. When a timeout or retry threshold is reached during the negotiation process, the channel management submodule registers a negotiation failure entry in the error log area of ​​this session and suspends subsequent channel establishment actions. After negotiation is completed, the control channel establishment process begins. The control channel establishment is used to create an instruction path for policy issuance, count write-back, and audit linkage. Specifically, the channel management submodule generates a control channel identifier based on the session number, domain identifier, and channel candidate item set, binds the session key to the control channel identifier, and registers this binding relationship in the channel index table. Next, it initializes the searchable items for the control channel, which include a search key, session number, and a summary of the policy snapshot reference, used for subsequent policy queries and quick location. After the control channel is established, the policy distribution process begins. This process reads the access field set, call frequency limit, time window constraint, and evidence preservation policy parameters from the policy snapshot table, converts the access field set into a control instruction sequence, and distributes this sequence within the control channel. Simultaneously, it writes write-back rules for the call frequency counter and time window counter into the control channel. These write-back rules constrain the calling end to report count changes with each incoming request and automatically generate an expiration event when the time window expires.During the policy issuance process, if there are non-overlapping fields between the access field set and the channel candidate item set, the channel management submodule adds the non-overlapping fields to the removal list and issues a removal instruction within the control channel. The removal list is simultaneously written back to the policy difference area of ​​the session view for reference in subsequent governance branches. After completing the above processing, this step constructs an encrypted control channel object at the session view exit. The encrypted control channel object contains a control channel identifier, session key, searchable item digest, policy instruction sequence, and write-back rules. This object is named "Encrypted Control Channel" at the process exit and is used as the output field name for the next step. It is also directly consumed by the S420's encrypted control channel for payload channel establishment, minimizing data retrieval, and result sealing. The write-back rules and searchable item digest in the encrypted control channel are referenced in the subsequent main step's transaction log registration and governance archiving, without changing the output set boundaries of this step.

[0120] S420. Extract the access constraint policy and the location of the controlled data domain from the encryption control channel, establish the payload channel, minimize the data acquisition and seal the result, and generate the sealed result.

[0121] The inputs for this step are the domain identifier, search key, and submission batch number from the encrypted control channel, session registration record, and context cache. The encrypted control channel includes a control channel identifier, session key, searchable item summary, policy instruction sequence, and write-back rules. Specifically, payload channel establishment begins with reading the control channel identifier. The channel orchestrator retrieves the corresponding session key and policy instruction sequence from the channel index table and parses the controlled data domain location using the domain identifier. The controlled data domain location consists of the data domain access point, accessible partition, and minimum search index key. After parsing the controlled data domain location, the channel orchestrator assigns a payload channel identifier to this request and binds the payload channel identifier to the session key, writing the binding record to the payload branch of the channel index table. During the payload channel handshake phase, the channel orchestrator sends the set of access fields and time window constraints from the policy instruction sequence to the interface proxy module of the controlled data domain and waits for the interface proxy module to return the fragment boundaries and field reachability descriptions of the available data. When there is a discrepancy between the field reachability description and the set of access fields, the channel orchestrator generates a field difference list and writes it back to the control channel to trigger the linkage of upstream counting and governance logic. After the handshake is complete, the minimum data retrieval process begins. This process uses the minimum retrieval index key as the entry point, employing time window constraints and field masks as pruning conditions to retrieve a set of segments that meet the criteria from the controlled data domain. During retrieval, if a segment boundary is detected to be inconsistent with the boundary defined by the policy instruction sequence, a boundary pruning branch is initiated. This branch adjusts the segments to the policy-allowed start and end ranges and records the adjustment in the session buffer of the payload channel. For segments with anomaly markers, the minimum data retrieval process only returns summary metadata and location information, not plaintext values. After the minimum data retrieval process is complete, the result sealing process begins, using the session key. Specifically, the result sealing uses the session key as the sealing key, serializes the segment set according to the field mask order, and appends summary information including segment start and end times, segment quantity, and field coverage. During sealing, the session number, payload channel identifier, and submission batch number reference are written to the encapsulation header, and an integrity summary and count snapshot are written to the encapsulation tail. After sealing is completed, the load channel sends count changes and expiration status information back to the control channel. The control channel updates the call frequency counter and time window counter according to the write-back rules, and issues a stop command to the channel orchestrator when the upper limit is reached or the expiration date is reached. To maintain output availability, the load channel performs an integrity self-check on the sealed load after sealing. Loads that pass the self-check are written to the return buffer, and result location information is generated in the session view. The result location information includes the load channel identifier, sealing time, and integrity summary.The aforementioned encapsulated payload is named "Sealed Result" at the output of this step. It is provided as the output field name for the next step and is directly consumed by the Sealed Result of S430 for transaction log registration, token consumption record writing, and failure branch governance. The result location information and integrity summary in the Sealed Result are referenced by the governance archive structure in the cross-main step prompt, without changing the output set boundary of this step.

[0122] S430. Register the transaction log for the sealing result, write the token consumption record and manage the failure branch, and generate a governance archive structure.

[0123] The inputs for this step are the sealing result, the encryption control channel, the session registration record, and the verification result record. The sealing result includes the payload channel identifier, encapsulation time, integrity summary, fragment start and end times, and field coverage summary. The encryption control channel includes the control channel identifier, a searchable item summary, and write-back rules. The session registration record includes the token value, validity period, and policy snapshot reference. The verification result record includes a list of passed entries, a list of rejected entries, a list of abnormal entries, and event location information. Specifically, transaction log registration begins with collecting the result location information from the sealing result. The registrar generates a transaction log entry for each sealed payload. The transaction log entry records the session number, domain identifier, control channel identifier, payload channel identifier, encapsulation time, and integrity summary, and associates them with the submission batch number. The registrar then writes the field coverage summary and fragment start and end times for retrieval and cross-comparison during auditing. After transaction log registration is complete, the token consumption record writing process begins. This process uses the token value in the session registration record as the index key and initiates a count write-back request to the contract-side session table. The request includes the number of data retrieval calls and the remaining duration of the time window. When the contract returns a write success event, the registrar records a count snapshot and expiration status in the local session view. Upon reaching the call frequency limit or the time window expires, a stop instruction is written to the control channel. When the contract returns a write failure event, the registrar registers the write failure entry in the session view and creates a retry plan. The retry plan includes the maximum number of retries and the retry interval. After the token consumption record writing is complete, the process moves to failure branch governance. Failure branch governance is used to mark and handle session risks caused by the rejected entry list and the abnormal entry list. The governance unit first reads the list of rejected entries and the list of abnormal entries from the verification result record, and cross-matches them with the entries registered in the transaction log. If an intersection is found between the entries involved in the current sealing result and the list of rejected entries, a handling task is created in the governance unit's handling queue. The handling task may include writing the corresponding token value into a blacklist placeholder, issuing a revocation command to the control channel, and sending an alarm to the requesting end. For the list of abnormal entries, the governance unit pulls structural evidence from the contract's failure evidence table based on the failure evidence location information, and writes the evidence location reference and the description of the abnormal cause into the governance archive. During the governance process, if a session registration record is detected to be in an expired or revoked state, the governance unit will directly write a stop command into the control channel and mark the closed state in the channel index table. For sessions that are still valid, the governance unit creates a policy tightening suggestion based on the policy snapshot reference and the version number of the access constraint policy. The policy tightening suggestion is registered in the governance archive structure for the policy orchestration engine to read during subsequent version registration.After completing the transaction log registration, token consumption record writing, and failure branch governance, the governance engine constructs a governance archive structure. This archive structure includes a transaction log set, a count snapshot set, a failure evidence reference set, blacklist status change placeholders, and policy tightening suggestions. The session number, domain identifier, and generation time are written in the structure header. This governance archive structure is returned as the output field name of this step at the process exit, used for audit queries and policy evolution across main steps. Simultaneously, it registers references to configuration mapping table update items in the context cache of the preceding main step, used for dynamic supplementation of sensitive fields, abnormal fragments, and policy differences in subsequent sessions without changing the output boundaries of this step. The technical effects of steps S410-S430 can be summarized as follows: through end-to-end key negotiation driven by verification result records, control channel establishment, and policy distribution, combined with minimized data retrieval and result sealing of the payload channel, and the formation of a governance archive structure after transaction log registration, token consumption record writing, and failure branch governance, a unified archive carrier that can be directly referenced is provided for subsequent auditing and policy evolution.

Claims

1. A blockchain-based method for securely sharing electricity data, characterized in that, include: Obtain the data domain list, measurement point list and configuration mapping table, perform naming standardization, time anchor registration and de-identification, commitment value and hash digest calculation, and unified field encoding. Form a fixed field sequence with unified field names, dimensions and calibers, generate the minimum retrieval index key and submission batch unit according to domain identifier, measurement point identifier and time range, and generate on-chain index record structure. Perform context validity verification, policy mapping, and access constraint policy version number registration; extract role, purpose, and time window constraints from the access constraint policy; generate a one-time session token, bind the token value to the session number, and associate the evidence preservation policy pointer; and complete the policy snapshot fixation and validity period writing on the contract side to obtain the session registration record; specifically including: The binding of the token value to the session number includes binding the access field set, evidence preservation policy pointer, version number, session number, and token value, and establishing an access field mask; the access field mask is formed by encoding uniform field names in a fixed order; The evidence preservation policy pointer association is used to dereference the evidence preservation policy pointer in the access constraint policy to the three elements of evidence retention scope, retention duration and retention location, and to suspend token registration when dereferencing fails. The policy snapshot solidification includes writing the access constraint policy version number, evidence preservation policy version number, and access field mask into the policy snapshot table of the contract, and establishing a one-to-one mapping with the session table through the session number for subsequent traceability and governance archiving. Perform source matching verification, time anchor alignment and link consistency verification, construct zero-knowledge proof and assemble witness materials, verify and generate events in the verifiable session smart contract according to the commitment value and hash digest dual channels, register failure evidence in the failure evidence table for failed entries and create blacklist placeholders for associated tokens, and generate verification result records. Perform end-to-end key negotiation and control channel establishment, distribute policies according to access field masks and time window constraints, establish payload channels and minimize data retrieval, return only digest metadata for abnormal fragments and seal the results with session keys, register transaction logs and token consumption records, and output a governance archive structure containing policy tightening recommendations.

2. The method according to claim 1, characterized in that, The data domain list, measurement point list, and configuration mapping table include: The data domain list includes the data domain name, data management unit, data residence location, and data access boundary; the measurement point list includes the measurement point identifier, acquisition frequency, channel number, and sampling time range; the configuration mapping table includes the field units, value scope, and value domain boundary.

3. The method according to claim 1, characterized in that, The process of generating a one-time session token includes: Before generating a one-time session token, the version number of the access constraint policy is compared with the policy library snapshot number for consistency. If the version number is earlier than the current effective version number of the policy library, a fast synchronization path is triggered and token generation is paused to ensure policy consistency.

4. The method according to claim 1, characterized in that, The process of generating a one-time session token, binding the token value to the session number, associating it with the evidence preservation strategy pointer, and completing the policy snapshot fixation and validity period writing on the contract side to obtain the session registration record includes: When importing the session token package to verify the smart contract registration entry, the token value and session number are first checked for uniqueness. After the check is passed, the token is written to the session table and the call frequency counter and call window counter are initialized.

5. The method according to claim 1, characterized in that, The process of constructing zero-knowledge proofs and assembling witness materials, verifying them using both commitment values ​​and hash digests within a verifiable session smart contract, and generating events includes: The system executes two parallel paths: commitment consistency verification and time anchor consistency verification, and generates a verification summary, which includes a list of passed items, a list of rejected items, and a list of abnormal items.

6. The method according to claim 1, characterized in that, The process of registering failure evidence in the failure evidence table for failed entries, creating a blacklist placeholder for the associated token, and generating a verification result record includes: The failure evidence generation path is used to read structural evidence from the witness material set of the evidence material package, bind the failed items with the structural evidence information to generate failure evidence units, and register them in the contract failure evidence table.

7. The method according to claim 1, characterized in that, The process of generating verification result records includes: The verification results record includes the count of passed entries, the count of rejected entries, and the count of abnormal entries, and is bound to the session number, contract version, and policy version metadata, which serve as inputs for subsequent end-to-end key negotiation and control channel establishment.

Images