Trusted traffic data distributed storage system based on main side chain

Abstract

The invention provides a trusted traffic data distributed storage system based on a main side chain, and the system comprises a traffic collection module which is used for carrying out the real-time collection of encrypted traffic data generated in a network, and carrying out the preliminary standardization processing of the encrypted traffic data, and obtaining the standardized encrypted traffic data; the traffic side chain certification module is used for carrying out integrity verification and authenticity construction on the standardized encrypted traffic data to prevent the data from being tampered or forged, so as to form verified encrypted traffic data; the traffic side chain data module is used for carrying out structured storage on the verified encrypted traffic data and reserving queriable records in a side chain; and the trusted main chain module is used for recording data abstracts, verification records, access behaviors and model voting result information on the side chain. According to the method, a block chain decentration trust mechanism and an encryption index mechanism are combined, encryption state organization and rapid retrieval of the data are achieved, and confidentiality and controllability of the data in the storage and circulation process are guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain storage for heterogeneous traffic data, and particularly to a trusted traffic data distributed storage system based on a main side chain. Background Art

[0002] With the increasingly severe network security situation, the detection and governance of encrypted traffic have become an important research direction in the current network security field. Traditional network monitoring means mostly rely on plaintext feature extraction and rule matching. When facing increasingly common encrypted communication protocols, they face problems such as insufficient visibility, difficult identification, and inability to cross-validate data.

[0003] There are a large number of heterogeneous data sources in the current network environment. Devices for collecting traffic are distributed in different network boundaries, different business scenarios, and different permission levels. The generated traffic data has significant differences in protocol format, data structure, collection frequency, etc., bringing great challenges to subsequent data integration, verification, and analysis. Especially in the scenario of multi-party collaborative governance, how to ensure the authenticity and integrity of the data provided by all parties and complete cross-verification and unified modeling under the premise of privacy protection is an urgent problem to be solved currently.

[0004] In the prior art, some solutions attempt to improve the processing ability of encrypted traffic by deploying edge intelligent models, or introducing means such as federated learning and trusted execution environments, but still generally have the following problems: First, there is a lack of a unified data authenticity verification mechanism, and the system is vulnerable to attacks by forged data or polluted inputs; second, it is difficult to effectively trace and audit the data source and access behavior, and the governance process lacks interpretability and accountability; third, the integration ability for cross-network and cross-domain heterogeneous traffic data is weak, and the cost of data standardization and collaborative utilization is high; fourth, there is a lack of a trusted data sharing and incentive mechanism, and it is difficult to encourage multiple parties to participate and provide real and high-quality data. Summary of the Invention

[0005] In order to overcome the deficiencies of the prior art, the purpose of the present invention is to provide a trusted traffic data distributed storage system based on a main side chain.

[0006] To achieve the above purpose, the present invention provides the following solutions:

[0007] A trusted traffic data distributed storage system based on a main side chain, comprising:

[0008] A traffic collection module, configured to collect encrypted traffic data generated in the network in real time, and perform preliminary standardization processing on the encrypted traffic data to obtain standardized encrypted traffic data;

[0009] The traffic side-chain proof module is used to verify the integrity and construct the authenticity of the standardized encrypted traffic data to prevent data from being tampered with or forged, and form the verified encrypted traffic data;

[0010] The traffic side-chain data module is used to structurally store the verified encrypted traffic data and retain queryable records in the side chain;

[0011] The trusted main-chain module is used to record the data summary, verification records, access behaviors, and model voting result information on the side chain.

[0012] Preferably, the traffic collection module includes:

[0013] The task allocation and data collection unit is used to use the distributed traffic probe nodes to select the collection tasks according to their own status, and submit the task acceptance commitment through the main-chain smart contract. After being authenticated by the main chain, the node starts the traffic capture module to collect the encrypted traffic data. After the collection is completed, the traffic probe node conducts a preliminary screening of the encrypted traffic data, judges the traffic category according to the task template parameters in the task, filters out the non-target traffic data and classifies and stores it in the local buffer pool;

[0014] The data format standardization unit is used to convert the collected encrypted traffic data using structured fields to form the standardized encrypted traffic data, and organize and index it locally using the block and sub-task structure.

[0015] Preferably, the traffic side-chain proof module includes:

[0016] The governance committee unit is used to complete the threshold key generation and update of the unified inference key in the system;

[0017] The deduplication proof unit is used to check for duplicates in the standardized encrypted traffic data and remove the duplicate encrypted traffic data;

[0018] The validity proof unit is used to perform trusted reasoning and on-chain verification on the collected encrypted traffic data using the homomorphic encryption and proxy re-encryption algorithms.

[0019] Preferably, in the member election process of the governance committee unit, first, the governance contract on the main chain evaluates the qualifications of the candidate nodes; the main chain synchronously triggers the side-chain nodes to conduct weighted voting on the candidate nodes that have passed the qualification assessment, and screens the top k nodes with the most votes as the new round of governance committee members, and broadcasts them to all listeners; when the new round of governance committee member list is synchronized to the side-chain consensus nodes, the threshold generation process of this round of inference key will be immediately started; the specific process is executed by the committee's trusted distributed key unit, and the steps are as follows:

[0020] First, each committee member captures the trigger of the CommitteeElected(event) event in the side-chain contract event listening module and enters the key initialization phase;

[0021] The committee members negotiate a common seed as the shared parameter for generating keys, and jointly generate the secret private key items by combining the pseudo-random generation algorithm and the indexsharing protocol;

[0022] The key commitments and verification proofs are exchanged among the nodes to mutually verify the honesty of the private key generation process;

[0023] If it is found that a certain node has malicious behavior, the node will be excluded from the current round of the process and its malicious state will be recorded;

[0024] After merging all the key commitment items of the verified committee nodes, the unified public inference public key pk is calculated agg , and each committee member locally stores its corresponding private key shard sk i , without sharing or broadcasting with other nodes, and keeping it in a secret state.

[0025] Preferably, in the deduplication proof unit, the single encrypted traffic data collected is set as F i , and the local node first executes the standard hash function H(·) on the single encrypted traffic data to calculate its complete data hash value:

[0026] hashOfFullData:=H(F i )

[0027] In the formula, H(·) represents a preset hash function, which is used to generate a hash digest of a fixed length from the input original traffic data F i ;

[0028] The local node maintains a "registered hash table" to record all the traffic hash values that have been packaged or submitted by the current node, and the hash value of each new traffic data will be matched with the existing items in it:

[0029] If , the system considers that the data has a "possibility of duplication" and terminates the subsequent transaction packaging process;

[0030] If , it is allowed to enter the transaction packaging stage and wait for submission on the chain;

[0031] When the user or the collection node initiates a traffic registration transaction Tx Reg , the system enters the on-chain duplicate checking process; the transaction structure includes the following fields:

[0032] Tx Reg (flowId, hashOfFullData, accessURL, protocol, label, timeRang, …)

[0033] The side - chain contract layer maintains an independent global hash mapping table for each task T k Its mapping relationship is defined as:

[0034]

[0035] Among them, represents the hash registration index table corresponding to task T k

[0036] Before the contract processes the Tx Reg transaction, it first verifies the signature sig Owner of the data submitter. This signature is encrypted by the data owner using the private key sk Owner to generate the hash value of the traffic:

[0037]

[0038] Subsequently, the contract uses its corresponding public key pk Owner to verify the signature:

[0039] Verify(sig Owner , hashOfFullData, pk Owner ) = True

[0040] In the formula, represents the private - key signature operation based on the elliptic - curve encryption algorithm, and Verify(·) represents the corresponding public - key signature - verification operation;

[0041] If the signature verification fails, that is, Verify = False, the contract immediately rejects the transaction to prevent forged or tampered data from entering the system;

[0042] If the signature verification passes, then it enters the duplicate - check determination: If there exists it indicates that the current data has been registered by other nodes, and the system will reject this transaction:

[0043] If then the contract regards it as the first registration, continues to complete the transaction process, and updates the traffic hash value and its transaction metadata to

[0044] ​​Preferably, in the validity proof unit, the governance committee issues a task template TaskTemplate through the main chain contract, binds the side chain document, task ID, and model identifier, and completes the deposit operation through the following function:

[0045] updateDID(sideChainDocument(taskTemplate,modelID))

[0046] Among them, updateDID(·) is the task definition deposit interface, and sideChainDocument(·) is the specified side chain task document;

[0047] The model service provider trains the model using a deep learning structure based on the dataset provided by the governance committee and exports the standard format ONNX;

[0048] In the encrypted model execution stage, the model side first encrypts the original model weights according to the aggregated public key pk agg of the governance committee to generate an encrypted inference model that can run in the homomorphic encryption domain; the user side encrypts the traffic sample F i using the same key system or local conversion mechanism and uploads it; the encrypted inference model directly performs convolution and activation operations in the ciphertext space and outputs the inference ciphertext result:

[0049]

[0050] Among them, represents the encrypted inference model encrypted with the aggregated key pk agg , and Enc(F i ) is the ciphertext input uploaded by the user;

[0051] The governance committee collaborates to generate a threshold re-encryption key under the authorization condition, and each committee member has a private key shard:

[0052] {sk1,sk2,…,sk n}

[0053] As long as any subset that meets the threshold condition agg can restore the equivalent structure of the aggregated private key sk

[0054]

[0055] Among them, λ i is the Lagrange interpolation coefficient, and sk i is the private key shard of the i-th committee member;

[0056] On this basis, the system calls the threshold re-encryption function:

[0057]

[0058] Among them, rk agg→v is the proxy re-encryption key from the aggregated key domain pk agg to the verification end public key pk v , and g is the public generator set by the system;

[0059] The re-encryption unit is executed at the model end. First, the received key rk agg→v is verified:

[0060] Verify(rk agg→v , pk v , sig GC ) = True

[0061] Among them, sig GC is the joint signature or zero-knowledge proof of the governance committee;

[0062] The inference output structure is denoted as:

[0063]

[0064] Among them, y i is the inference output result, and h i is the traffic identifier hash; the re-encryption process is as follows:

[0065]

[0066] The final ciphertext C' out can be decrypted by the verification end using the private key sk v :

[0067]

[0068] After the verification end obtains the ciphertext from the model end, it performs local decryption to obtain the inference result.

[0069] Preferably, the traffic side chain data module includes:

[0070] A traffic registration and registration unit for realizing the trustworthy registration, index management and verification traceability of encrypted traffic data in combination with the side chain and main chain collaborative structure;

[0071] A side chain storage unit, adopting a multi-layer nested storage architecture, including a traffic status table FlowState, a distributed dynamic storage engine DASE, and a heterogeneous Merkle audit structure, for supporting the structured storage, index retrieval and distributed audit verification of encrypted traffic data;

[0072] The multi-keyword complex query unit is used to implement the multi-field combined query of the off-chain stored data on the premise of ensuring the immutability of the on-chain index information.

[0073] Preferably, in the traffic registration unit, the collection node obtains the original encrypted traffic data from the network, denoted as Flow, and generates the corresponding validity verification structure through the model inference module to form a verification structure body in the following format:

[0074] FlowProof := {y i , Hash(Flow), sig, metadata}

[0075] In the formula, y i represents the model inference output, Hash(Flow) is the original data hash, sig is the signature of the uploader or the verification end, and metadata represents additional information.

[0076] The original traffic data body is not directly uploaded to the chain, but is stored in the flow_main table of the distributed dynamic storage engine; only the data hash and reference pointer are recorded on the chain to decouple the evidence storage and access; the validity verification task is executed by the specified verification node verifier, and the verification result and timestamp information will be written into the consensus structure as part of the on-chain registration content;

[0077] After receiving the traffic registration transaction Tx Reg , the blockchain system calls the verification function:

[0078] ProveAndVerify(FlowProof)

[0079] Check the verification structure; after the verification passes, enter the transaction initialization process, broadcast the consensus and write it into the state database, and the recorded fields include:

[0080] verifier: The node address that executes the verification task;

[0081] resultHash = H(y i ||txHash): The non-repudiation hash calculated by concatenating the inference output result y i and the transaction hash txHash;

[0082] verifyTimestamp: The on-chain timestamp when this verification task is completed;

[0083] The system then broadcasts an event:

[0084] emitFlowRegistered(flowId, resultHash, verifier, verifyTimestamp) ensures that each node on the side chain receives the registration synchronization signal;

[0085] Registration transaction Tx Reg The structure definition is as follows:

[0086]

[0087] Among them, flowId represents the unique flow identifier, accessURL represents the pointer to the off-chain data location, protocol, label, and timeRange represent the flow classification and indexing identifiers, sideChainId represents the ID of the side chain where it is located, which can be regarded as the task template number, ownerList represents the list of current legitimate owner addresses, verifier represents the verification node address, resultHash represents the verification result hash, and verifyTimestamp represents the verification timestamp;

[0088] After successful registration, the DASE data index engine will establish a multi-dimensional inverted index structure based on the fields protocol, label, timeRange, and sideChainId to support field-level retrieval queries;

[0089] In the state storage layer, the blockchain maintains the core meta-information structure FlowState, and its format is as follows:

[0090]

[0091] In the formula, all fields are consistent with Tx Reg and are completed by the consensus node for disk writing and distributed storage to ensure that any node can quickly retrieve based on flowId;

[0092] If it is necessary to verify the integrity of the off-chain data, the client can request the hash Hash(·) of the original data from the accessURL and compare it with the hash field in the FlowState. If they are the same, it means that the data has not been tampered with; if it is necessary to verify the reasoning validity, resultHash = H(y i ||txHash) can be taken, and combined with the verification end signature and the model logic for recalculation verification, which is used for liability audit and data tradability management.

[0093] Preferably, in the traffic registration unit, in the multi-keyword complex query unit, the query process includes:

[0094] The user constructs a logical expression according to the query target, and the structured form is as follows:

[0095]

[0096] Wherein, represents a primary query logic request, including a keyword set, a logical connective, and a range limit, for the query engine to parse;

[0097] The system calls the DASE query engine to convert it into a query plan, match the corresponding inverted or combined index structure, and return an initial result set:

[0098]

[0099] The flowId corresponding to each query returns the main chain storage structure:

[0100] FlowState(flowId):={Hash(Flow),ownerList,sideChainId,…}

[0101] The querier recalculates Hash(Flow) based on off-chain data, compares it with the on-chain record to ensure that the data has not been tampered with, or calls the contract ProveAndVerify(flowId) to complete the status verification;

[0102] If the user has a decentralized identity (DID), the system will use the permission contract AuthMod to execute the judgment:

[0103] IsOwner(flowId,userId,sideChainId)→{true,false}

[0104] If the result is true, the system will return the data access path accessURL, which includes the requesterDID and its signature field, for off-chain nodes to perform identity and permission verification;

[0105] A successful query will generate a behavior log FlowQueryLog, and the structure is:

[0106]

[0107] Write the log record into the MBT AccessLog structure, whose root hash rootHash AccessLog is periodically submitted to the main chain contract AuditRootMapping to achieve traceable auditing.

[0108] Preferably, the trusted main chain module includes:

[0109] Model management and multi-role identity registration mechanism unit, which is used to manage users, nodes, side chain governance parties and model service providers, and realize unified registration and tamper-proof identity binding through the main chain to support trusted model calls and identity audits in cross-side chain environments;

[0110] Sidechain anchoring and state summary recording unit, used to generate state digest on the sidechain k , and periodically submit it to the main chain contract to complete the anchoring, so as to form an unalterable network-wide consensus record in the main chain ledger, and realize the credible record of the side chain operation status and cross-chain verifiability;

[0111] The full-chain management unit and the cross-chain scheduling mechanism unit are used to complete the lifecycle management of governance committee members and ordinary users under the coordination mechanism of the main chain and side chain.

[0112] The beneficial effect of the main-side chain-based trusted traffic data distributed storage system provided by the present invention is that: compared with the prior art, the present invention combines the blockchain decentralized trust mechanism and the encrypted index mechanism to achieve encrypted organization and rapid retrieval of data, and ensure the confidentiality and controllability of data during storage and circulation. BRIEF DESCRIPTION OF THE DRAWINGS

[0113] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0114] Figure 1 It is a schematic diagram of a trusted traffic data distributed storage system based on a main-side chain provided by the present invention;

[0115] Figure 2 An internal system framework diagram of the flow collection module provided by the present invention;

[0116] Figure 3 This is an internal system framework diagram of the traffic side chain certification module provided by the present invention;

[0117] Figure 4 An internal system framework diagram of the traffic side chain data module provided by the present invention;

[0118] Figure 5 This is an internal system framework diagram of the trusted main chain module provided by the present invention. DETAILED DESCRIPTION

[0119] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0120] Reference to "embodiments" in this context means that a particular feature, structure, or characteristic described in connection with the embodiments can be included in at least one embodiment of the present application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0121] The terms "first", "second", "third", "fourth", etc. in the specification and claims of the present application and the accompanying drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a series of steps, processes, methods, etc. included do not limit to the listed steps, but optionally further include steps not listed, or optionally further include other step elements inherent to these processes, methods, products, or devices.

[0122] To make the above objects, features, and advantages of the present invention more obvious and understandable, the present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0123] Please refer to Figures 1-5 , a trusted traffic data distributed storage system based on the main side chain, including:

[0124] A traffic collection module for real-time collecting the encrypted traffic data generated in the network and performing preliminary standardization processing on the encrypted traffic data to obtain standardized encrypted traffic data;

[0125] The traffic collection module is responsible for collecting traffic data in different encrypted or non-encrypted communication environments (VPN, Tor, public WiFi networks, cloud services, etc.) and generating a standardized traffic data format for subsequent trusted storage, analysis, and authenticated upload.

[0126] A traffic side chain proof module, which can be applied to an encrypted traffic data processing system based on blockchain, for realizing the real and effective proof of traffic data in a multi-task scenario. This module works in cooperation with the aforementioned traffic collection module: the collected traffic data is first de-duplicated and checked in the local private storage, and then confirmed on the chain and traceable management is performed through the side chain proof module.

[0127] The traffic side-chain data module is used to structurally store the verified encrypted traffic data and retain queryable records in the side-chain. An encrypted index mechanism is adopted inside the module to realize the encrypted organization and rapid retrieval of data, support the provision of data access interfaces with privacy protection, and ensure the confidentiality and controllability of data during storage and circulation.

[0128] The trusted main-chain module, as the core trusted infrastructure of the entire system, is used to record key information such as data summaries, verification records, access behaviors, and model voting results on the side-chain. The main-chain adopts an immutable distributed ledger structure to ensure the openness and audibility of data submission, verification processes, and access control in the system, providing a unified trusted basis for multiple participants.

[0129] Refer to Figure 2 As shown, the traffic collection module specifically includes a task allocation and data collection unit and a data format standardization unit, as follows:

[0130] The task allocation and data collection unit: realizes the orderly collection, task distribution, and preliminary screening of multi-source heterogeneous encrypted traffic data. This unit consists of a task allocation mechanism and a data collection process.

[0131] Specifically, in terms of the task allocation mechanism, the task is initiated and filed by the side-chain to the main-chain, and the task information is published and recorded through the smart contract deployed on the main-chain. The task parameters include, but are not limited to:

[0132] The collection type field, used to specify the target traffic category, supports encrypted communication protocols such as VPN (Virtual Private Network), Tor (Onion Router), and HTTPS / TLS (Hypertext Transfer Protocol Secure / Transport Layer Security Protocol); the collection range field, including the time interval and geographical area, used to define the spatio-temporal boundaries of task execution; the data requirement field, such as the expected collection duration and target bandwidth; the encryption policy field, used to indicate the encryption method adopted for data submission.

[0133] When the task is completed, the collected data will be subject to integrity verification and on-chain encapsulation by the traffic side-chain module, and finally transmitted to the trusted main-chain module to achieve immutable evidence storage and supervision.

[0134] In terms of the data collection process, first, each distributed traffic probe node selects tasks according to its own status (including indicators such as bandwidth resources, computing power, network reachability, etc.), and submits a task acceptance commitment through the main chain smart contract. After being authenticated by the main chain, the data collection officially starts. After accepting the task, the node starts the traffic capture module. The traffic capture is implemented based on mainstream network traffic collection protocols, including: NetFlow (Network Traffic Statistics Protocol); IPFIX (Internet Protocol Flow Information Export); sFlow (sampled Flow, Sampling Traffic Analysis Protocol).

[0135] At the same time, in cooperation with DPI (Deep Packet Inspection) technology, the encrypted communication features in the captured traffic are identified and extracted. The extracted fields include: encrypted handshake features; SNI (Server Name Indication); encrypted flow duration; first packet size and direction, etc.

[0136] After the traffic is captured, the probe node conducts a preliminary screening of the traffic data, determines the category of the traffic according to the task template parameters in the task, filters out non-target traffic, classifies and stores it, and generates protocol tags and preliminary data summaries. The pre-screened data is structurally stored in the local buffer pool for use by the subsequent side chain verification and main chain submission modules.

[0137] Data format standardization unit: This unit is responsible for converting the collected encrypted traffic data into a unified format structure, and organizing and indexing it locally using a block-by-block and task-by-task structure to adapt to subsequent side chain storage and on-chain operations.

[0138] First of all, the objectives of the data format standardization unit include the following three points: First, to achieve the unified structure format of encrypted traffic data under the same side chain, ensuring the format consistency of the data collected by each task node; second, to adopt a multi-level block storage strategy, splitting and storing the collected data at the task level and block level according to the side chain task category; third, to ensure the isolation of data between tasks, while improving the access efficiency and query ability of data between different side chains.

[0139] In terms of the core data format, this unit defines a standardized data record structure. Each piece of encrypted traffic data is denoted as F i , and its structured fields are shown in Table 1 below:

[0140] Table 1

[0141]

[0142]

[0143] The above fields constitute the basic fields of the system, which are generated by the collection nodes after DPI analysis during the traffic detection phase and are used for the preliminary matching and data screening of the side-chain tasks.

[0144] To meet the diverse requirements of different tasks for the field structure, the system supports a task field extension mechanism. Specifically, each task registers the corresponding field template (field name, field type, and whether it is mandatory) in the main-chain smart contract to form a task field template definition. The template can contain multiple extended fields. For example, a VPN data task can define fields such as vpn_ratio (VPN feature ratio), burst_entropy (burst entropy metric), and tor_exit_flag (whether it is an exit marker, boolean value), etc.

[0145] During the task collection period, the collection nodes automatically load the extended fields according to the task field template. When writing the collected data into the local storage structure, the extended fields and the basic fields are nested and stored, and the data is organized according to the following steps:

[0146] S1-1: The system uses the "task category" as the first-level grouping basis to establish task namespaces such as the VPN task side-chain and the Tor task side-chain respectively;

[0147] S1-2: Each task generates a local private task storage bucket, which contains a task configuration file (meta.json), a chunk data file (chunk_000x.json), and a field index database (index.db);

[0148] S1-3: The collected data is written into the data file in units of "blocks". Each data block is recommended to contain about 1000 records to improve the subsequent on-chain batch processing efficiency;

[0149] S1-4: Each record contains a unique flow_id (traffic record identifier);

[0150] In the data storage structure, the meta.json file records the task status, the field template hash, the last submitted block number, and the total number of collected records; the index.db maintains a field-level inverted index and a task field dictionary structure to support efficient screening and aggregation; the chunk data file records the complete structure of the traffic data in JSON format, and the fields support types such as floating-point, boolean, string, and enumeration.

[0151] Refer to Figure 3 As shown, the traffic side-chain proof module specifically includes: a governance committee unit, a deduplication proof unit, and a validity proof unit, specifically as follows:

[0152] Governance Committee Unit: This unit completes the threshold key generation and update process of the unified inference key in the system. The governance committee mechanism is the core foundation for realizing trusted execution of privacy computing. The election of its members is uniformly managed by the main chain governance contract and synchronized to each side chain node to ensure that the key management process of the entire system has decentralization, auditability, and anti-malicious capabilities.

[0153] Furthermore, in the member election process, first, the governance contract on the main chain evaluates the eligibility of candidate nodes. Specifically, the function getNodeScore(address) is called, where address represents the node account address. The contract reads indicators such as the node's historical participation behavior, task completion rate, and past key distribution contribution records from the main chain state database and calculates its corresponding credit score (score).

[0154] When a node meets the candidacy threshold, it can submit a candidacy application to the governance contract by calling the submitCandidate() interface function. The contract marks the node as "candidate status" and opens the voting entrance. Subsequently, the main chain synchronously triggers the side chain nodes to conduct weighted voting on the candidates. Each side chain consensus node calls voteFor(candidate id ) according to the weight of its staked assets on the chain (or other preset governance factors), where candidate id is the unique identifier of the candidate node. The contract records the number of votes, the identity of the voters, and their asset amounts in the state variable for subsequent calculation of the election validity.

[0155] After the voting period ends, the main chain contract calls the electCommittee() function to select the top k nodes with the most votes as the members of the new round of governance committee according to the set election rules. The voting results are broadcast to all listeners by triggering the event emitCommitteeElected(event), and the event contains the array of elected member addresses, the election round number, and the timestamp, etc.

[0156] After the list of the new round of governance committee members is synchronized to the side chain consensus nodes, the threshold generation process of the inference key for this round will be immediately started. The specific process is executed by the committee's trusted distributed key unit, and the steps are as follows:

[0157] S2-1. Each committee member first captures the trigger of the CommitteeElected(event) event in the side chain contract event listening module and enters the key initialization stage;

[0158] S2-2. The committee members negotiate a public seed as the shared parameter for generating the key, and combine a pseudo-random generation algorithm with the indexsharing protocol to jointly generate the secret private key items. The pseudo-random generation algorithm needs to ensure the sparsity of each private key segment, that is, the sum of its non-zero items is still controlled within the set density range;

[0159] S2-3. The nodes exchange key commitments and verification proofs with each other to mutually verify the honesty of the private key generation process;

[0160] S2-4. If it is found that a certain node has malicious behavior, such as not sending data on time or submitting false commitments, then this node will be excluded from the current round of the process, and its malicious state will be recorded;

[0161] S2-5. After all the key commitment items of the qualified committee nodes are merged, the system calculates the unified public inference public key pk agg (where pk agg represents the aggregated public key, the aggregated public key), and at the same time each committee member locally saves its corresponding private key shard sk i (in the formula, sk i represents the private key segment of the i-th committee node), which is not shared or broadcast with other nodes and remains in a secret state.

[0162] Each committee node participates in the inference key update protocol based on its sk i and marks its completed participation status through the state variable in the on-chain governance contract. If a certain committee node refuses to submit or has a response timeout, its status will be recorded as "incomplete", and the side chain will initiate a proposal process to decide whether to replace this node or trigger a penalty procedure (such as deducting pledged assets, reducing credit points, etc.).

[0163] Deduplication proof unit: This unit is applicable to a multi-source node environment, and can avoid waste of on-chain storage resources, accumulation of data deviation and subsequent analysis bias while ensuring the system processing efficiency.

[0164] First, after the data collection is completed, the system executes a pre-check process at the local collection end. Let the single encrypted traffic data collected be F i , and the local node first executes the standard hash function H(·) on this data to calculate its complete data hash value:

[0165] hashOfFullData:=H(F i )

[0166] In the formula, H(·) represents a preset hash function (such as SHA-256), which is used to calculate the complete data hash value from the input original traffic data F iGenerate a hash digest of a fixed length. This hash value serves as an equivalent identifier for data uniqueness.

[0167] The local node maintains a "registered hash table" which records all traffic hash values that have been packaged or submitted by the current node. For each new traffic data, its hash value will be matched with the existing entries in:

[0168] If then the system considers that the data has a "possibility of duplication", marks it as redundant, and terminates the subsequent transaction packaging process;

[0169] If then it is allowed to enter the transaction packaging stage and wait for submission on the chain.

[0170] Furthermore, when the user or the collection node initiates a traffic registration transaction Tx Reg the system enters the on-chain duplicate check process. The transaction structure includes the following fields:

[0171] Tx Reg (flowId,hashOfFullData,accessURL,protocol,label,timeRange,…)

[0172] The side-chain contract layer maintains an independent global hash mapping table for each task T k The mapping relationship is defined as: where

[0173]

[0174] In the formula, represents the hash registration index table corresponding to task T k which is used to record the registration records of each traffic data at the task level, including its transaction hash, the on-chain block number, and the initiator's account address.

[0175] Before processing the Tx Reg transaction, the contract first verifies the signature sig Owner of the data submitter. This signature is encrypted by the data owner using its private key sk Owner to generate for the traffic hash value:

[0176]

[0177] Subsequently, the contract uses its corresponding public key pk Owner to perform signature verification:

[0178] Verify(sig Owner ,hashOfFullData,pkOwner ) = True

[0179] In the formula, represents the private key signature operation based on the elliptic curve encryption algorithm, and Verify(·) represents the corresponding public key signature verification operation, which is used to verify the rights attributes and data integrity of the data uploader.

[0180] If the signature verification fails, that is, Verify = False, the contract immediately rejects the transaction to prevent forged or tampered data from entering the system.

[0181] If the signature verification passes, then enter the duplicate check determination:

[0182] If there exists it indicates that the current data has been registered by other nodes, and the system will reject the transaction and notify relevant parties by triggering an on-chain event:

[0183] emitFlowDuplicateDetected(flowId, sender_address, block.timestamp)

[0184] This event contains the duplicate flow identifier, the submitter address, and the trigger timestamp, which are used for system auditing, statistics, and behavior monitoring.

[0185] If the contract regards it as the first registration, continues to complete the transaction process, and updates the flow hash value and its transaction metadata to

[0186] This mechanism makes isolation judgments in different task dimensions to ensure the uniqueness of the internal data of task T k and prevent the same flow from being registered multiple times under the same task.

[0187] In addition, as an important supplement to this unit, the hash signature mechanism requires that each Tx Reg submission must be accompanied by a legal signature sig Owner generated by the uploader to ensure the provability of data ownership and the traceability of the system to the upload behavior. This mechanism combines the hash deduplication and signature traceability logics to implement a three-stage duplicate check determination process from the "collection end → submission end → contract side".

[0188] Validity Proof Unit: This unit is used to perform trusted inference and on-chain verification on the collected encrypted traffic data based on homomorphic encryption (HE) and proxy re-encryption (PRE) technologies while ensuring user data privacy. This unit consists of an encrypted model sub-unit, a key collaboration sub-unit, a re-encryption execution sub-unit, and a verification execution sub-unit, which jointly complete the entire process from data input to on-chain verification.

[0189] First, the governance committee releases the task template TaskTemplate through the main chain contract, binds the side chain document, task ID, and model identifier, and completes the deposit operation through the following function:

[0190] updateDID(sideChainDocument(taskTemplate,modelID))

[0191] In the formula, updateDID(·) is the task definition deposit interface, and sideChainDocument(·) is the specified side chain task document.

[0192] Based on the dataset provided by the governance committee (including real traffic and forged samples), the model service provider trains the model using a deep learning structure (such as ResNet) and exports it in a standard format (ONNX). The main chain records the task number, model hash, and its bound execution contract of this model, which serves as the basis for subsequent inference and verification.

[0193] In the encrypted model execution stage, the model side first encrypts the original model weights according to the aggregated public key pk of the governance committee agg to generate an encrypted inference model that can run in the homomorphic encryption domain. The user side encrypts the traffic sample F using the same key system or a local conversion mechanism i and uploads it. The model side directly performs operations such as convolution and activation in the ciphertext space (the activation function is implemented through polynomial approximation), and outputs the inference ciphertext result:

[0194]

[0195] Among them, represents the model function encrypted with the aggregated key pk agg , and Enc(F i ) is the ciphertext input uploaded by the user.

[0196] To enable the verification side to read this encrypted output, the governance committee collaborates to generate a threshold re-encryption key under authorized conditions. Each committee member has a private key shard:

[0197] {sk1,sk2,…,skn}

[0198] Just a subset that arbitrarily satisfies the threshold condition can recover the aggregated private key sk agg The equivalent structure of:

[0199]

[0200] In the formula, λ i is the Lagrange interpolation coefficient, and sk i is the private key shard of the i-th committee member.

[0201] On this basis, the system calls the threshold re-encryption function:

[0202]

[0203] In the formula, rk agg→v is the proxy re-encryption key from the aggregated key domain pk agg to the verification end public key pk v , and g is the public generator set by the system.

[0204] The re-encryption unit executes at the model end. First, it verifies the received key rk agg→v :

[0205] Verify(rk agg→v ,pk v ,sig GC ) = True

[0206] Among them, sig GC is the joint signature or zero-knowledge proof of the governance committee.

[0207] The inference output structure is denoted as:

[0208]

[0209] In the formula, y i is the inference output result (such as real / fake label), and h i is the traffic identifier hash (such as H(flow_id‖timestamp)).

[0210] The re-encryption process is as follows:

[0211]

[0212] The final ciphertext C′ out can be decrypted by the verification end using the private key sk v :

[0213]

[0214] After the verification end obtains the ciphertext from the model end, it performs local decryption to obtain the inference result, that is, the authentication result of the true validity of the traffic data. To ensure auditability, the verification end submits the following information to the side-chain contract for relevant authentication:

[0215] Tx flow := SubmitFlowTx(flow_id, verifier, H(y i ‖h i ), timestamp)

[0216] where SubmitFlowTx(·) is the traffic transaction registration interface, verifier is the identity of the verification node, H(y i ‖h i ) is the hash digest of the inference result and the data identifier, and timestamp is the verification timestamp.

[0217] Refer to Figure 4 as shown, the traffic side-chain data module specifically includes: a traffic registration unit, a side-chain storage unit, and a multi-keyword complex query unit, as follows:

[0218] Traffic registration unit:

[0219] The process of uploading traffic data to the chain needs to combine the side-chain and the main-chain collaborative structure to achieve trusted registration, index management, and verification traceability of encrypted traffic data. This process includes the following steps:

[0220] First, the traffic data collection and validity proof link is executed by a trusted node. The collection node obtains the original encrypted traffic data from the network, denoted as Flow, and generates a corresponding validity verification structure through the model inference module to form a verification structure in the following format:

[0221] FlowProof := {y i , Hash(Flow), sig, metadata}

[0222] where y i represents the model inference output (such as true / false label), Hash(Flow) is the hash of the original data, sig is the signature of the uploader or the verification end, and metadata contains additional information such as protocol type and time range.

[0223] The original flow data ontology is not directly uploaded to the blockchain but is stored in the flow_main table of the Distributed Access Storage Engine (DASE for short). Only the data hash and reference pointers (such as accessURL) are recorded on the blockchain, achieving decoupling of evidence storage and access. The validity verification task is executed by the designated verification node verifier, and the verification results and information such as timestamps will be written into the consensus structure as part of the on-chain registration content.

[0224] After receiving the flow registration transaction Tx Reg the blockchain system calls the verification function:

[0225] ProveAndVerify(FlowProof)

[0226] Check the verification structure, including signature validity, model output legality, and hash consistency, etc. After passing the verification, enter the transaction initialization process, broadcast the consensus and write it into the state database. The recorded fields include:

[0227] verifier: the node address that executes the verification task;

[0228] resultHash = H(y i ||txHash): the non-repudiable hash calculated by concatenating the inference output result y i and the transaction hash txHash:

[0229] verifyTimestamp: the on-chain timestamp when this verification task is completed;

[0230] The system then broadcasts the event:

[0231] emitFlowRegistered(flowId,resultHash,verifier,verifyTimestamp)

[0232] Ensure that each node on the side chain receives the registration synchronization signal.

[0233] The structure definition of the registration transaction Tx Reg is as follows:

[0234]

[0235] Among them, flowId represents the unique traffic identifier, accessURL represents the off-chain data location pointer, protocol, label, and timeRange represent traffic classification and indexing identifiers, sideChainId represents the ID of the side chain where it is located, which can be regarded as the task template number, ownerList represents the list of current legitimate owner addresses, verifier represents the address of the verification node, resultHash represents the verification result hash, and verifyTimestamp represents the verification timestamp.

[0236] After successful registration, the DASE data indexing engine will establish a multi-dimensional inverted index structure based on the fields protocol, label, timeRange, and sideChainId to support field-level retrieval queries. For example:

[0237] "protocol=VPN" → {flowId_1, flowId_3}

[0238] "label=TOR" → {flowId_2, flowId_5}

[0239] Continuous fields such as timeRange and duration will be optimized for range matching through bucket indexing to improve the efficiency of range queries. All index entries are synchronized to the mapping structure Its definition is:

[0240]

[0241] This structure supports the mapping from fields to flowId. Combining with accessURL, the off-chain storage address can be obtained, and the hash value can be compared to verify whether the data has been tampered with.

[0242] In the state storage layer, the blockchain maintains the core meta-information structure FlowState, and its format is as follows:

[0243]

[0244] In the formula, all fields are consistent with Tx Reg and are completed by the consensus node for disk writing and distributed storage to ensure that any node can quickly retrieve based on flowId.

[0245] If it is necessary to verify the integrity of the off-chain data, the client can request the hash Hash(·) of the original data from accessURL and compare it with the hash field in FlowState. If they are the same, it means the data has not been tampered with. If it is necessary to verify the reasoning validity, resultHash = H(y can be taken i||txHash), and cooperate with the verification end signature and model logic for recalculation verification. It can also be used for liability audit and data tradability management.

[0246] Side-chain storage unit: This unit integrates the FlowState state table, DASE (Distributed Adaptive Storage Engine), and heterogeneous Merkle audit structure, and specifically implements from four aspects: storage structure design, performance optimization, audit mechanism, and off-chain data management.

[0247] First, the FlowState table is maintained by the main-chain contract, recording the core metadata of each flow. Its structure is as follows:

[0248]

[0249] In the formula: flowId represents the unique flow identifier, Hash(Flow) is the hash digest of the flow content, ownerList is the array of owner addresses, sideChainId is the side-chain task identifier, verifier is the verification node address, resultHash is the verification output hash, and verifyTimestamp is the on-chain timestamp for completing the verification.

[0250] The DASE module provides distributed multi-database support, compatible with backends such as MySQL, RocksDB, Elasticsearch, and TiKV, and has the following structure:

[0251] Data access layer FlowStorageAPI: Uniformly accept on-chain transaction writing, index requests, and log collection;

[0252] Driver adaptation layer StorageAdapter: Mount storage.type according to the configuration and translate operations into database instructions;

[0253] Status cache engine WriteBuffer: Write the status in the new block into the cache and batch commit at the end of the block to ensure transaction atomicity;

[0254] Index maintenance module IndexManager: Establish an inverted index for the fields protocol, label, timeRange, and sideChainId to support Elasticsearch / SQL queries;

[0255] Access log and audit tracking module FlowLog: Record each query, verification, and access behavior to provide the original record for the heterogeneous audit structure.

[0256] In terms of performance optimization, DASE introduces a block-level hash verification mechanism to replace the traditional MPT (Merkle Patricia Trie) path verification:

[0257]

[0258] Where H Block represents the state hash digest of the new block, which is used by consensus nodes for state consistency verification. This mechanism reduces the verification complexity from O(log N) to O(1), improving the verification efficiency.

[0259] In terms of the audit mechanism, the system constructs a heterogeneous Merkle audit structure framework, supporting multiple transaction types such as TxReg (registration), TxAddOwner (authorization), AccessLog (access log), and TxPay (payment record) to be registered with different Merkle structures to the side-chain audit engine. The structure mapping is as follows: MPT type (applicable to TxReg, TxAddOwner): uses a compressed Merkle Patricia Trie, and the node types include extended nodes, branch nodes, and leaf nodes. Its hash is:

[0260] h(n) = H(RLP(n))

[0261] MBT type (applicable to access and payment logs): uses a Merkle B+Tree, and the leaf node structure is as follows:

[0262]

[0263] The root node is:

[0264]

[0265] All types of audit structures are registered with AuditRootMapping (rootType → rootHash), supporting a lightweight proof mechanism:

[0266] The MPT path proof is Proof MPT (k) = {n1, n2,..., siblinghashes}

[0267] The MBT time interval proof is Proof MBT ([t1, t2]) = {B+path, partial roots}

[0268] For off-chain raw traffic data, the system uses a decentralized access method. The data is stored in a distributed database (such as MongoDB, MinIO, IPFS, etc.) and is identified by the accessURL pointer field. Its format is as follows:

[0269] accessURL = " <protocol> : / / <host> / <resource>?requesterDID= <did>&sig=<sig nature>&method= <methodtoinvoke>"

[0270] The requester signs the flowId||timestamp||requesterDID||method through the DID (Decentralized Identifier) mechanism and attaches an access request. The storage node obtains the public key through the contract resolveDID(did), verifies the identity of the requester, checks whether it is a member of the FlowState.ownerList, and returns the encrypted data after passing the verification.

[0271] Traffic resource purchase process: User U buyer can purchase the registered encrypted traffic data from U seller in the side chain, realizing trusted permission granting and payment performance guarantee. This process depends on the collaborative work of the identity framework (trusted identity information architecture + DID), distributed audit structure (MPT / MBT), state storage structure (FlowState + DASE), and anchoring mechanism (AuditSuperRoot) built in the system.

[0272] Furthermore, before the transaction is initiated, the following preconditions need to be met:

[0273] S3-1-1. Both user parties U buyer and U seller have completed the registration process based on the trusted identity information architecture and have unique decentralized identity identifiers (Decentralized Identifier, abbreviated as DID), whose public keys are registered through the side chain contract and can be queried, denoted as PK buyer and PK seller respectively.

[0274] S3-1-2. The traffic resources have been registered with the side chain by U seller and written into the registration structure MPT Reg through the transaction Tx TxReg , with the corresponding root hash being rootHash TxReg , including fields such as flowId, label, protocol type, price, and description.

[0275] S3-1-3. A payment mechanism is deployed within the system to support balance contracts and payment transactions Tx Pay , and the payment records are registered in the MBT Payment , with the root hash being rootHash Payment .

[0276] After the above conditions are met, the transaction process proceeds as follows:

[0277] S3-2-1. A payment mechanism is deployed within the system, supporting balance contracts and payment transactions Tx Pay , and the payment records are registered in the MBT Payment , with the root hash being rootHash Payment . Resource discovery and intent generation: User U buyer queries eligible traffic resources through the DASE index module or the Merkle Patricia Trie (MPT) structure, and completes intent confirmation by reading fields such as flowId, label, and timeRange, in combination with price information

[0278] S3-2-2. A payment mechanism is deployed within the system, supporting balance contracts and payment transactions Tx Pay , and the payment records are registered in the MBT Payment , with the root hash being rootHash Payment . Payment initiation process:

[0279] The user initiates a payment transaction in the following format:

[0280] Tx Pay (flowId,amount)

[0281] The contract first verifies the legality of its signature and the sufficiency of the balance. If the verification passes, the following operations will be completed:

[0282] S3-2-2-1. Deduct the corresponding Token from the user's account;

[0283] S3-2-2-2. Record the payment event in the MBT Payment ;

[0284] S3-2-2-3. Calculate and update the root hash rootHash Payment , and submit it to the audit root mapping contract AuditRootMapping for subsequent verification and anchoring

[0285] After the payment is completed, the system triggers a status change transaction Tx AddOwner by the transaction contract FlowTradeManager, and its format is:

[0286] Tx AddOwner (flowId,newOwner:=U buyer )

[0287] This transaction is used to add U buyer to the ownerList of this traffic, and the result is registered in the audit structure MPT AddOwner , and update the root hash rootHash AddOwner .

[0288] S3-2-3, Resource Access and Logging:

[0289] User U buyer initiates a data access request, and the system checks whether it has access rights in the ownerList of FlowState. If the permission verification passes, the data (encrypted data block or accessURL) is returned, and an access log entry is generated:

[0290] Log Access := (flowId, timestamp, accessType)

[0291] The log is written into a Merkle B+Tree (MBT) - type structure MBT AccessLog and the root hash rootHash is updated AccessLog .

[0292] Furthermore, after the transaction is completed, the system supports full audit capabilities. The proof paths include:

[0293] MPT - type transaction proof path:

[0294] Proof MPT (txHash) = {p1→p2→…→leaf, sibling_hashes}

[0295] where leaf is the end - node of the transaction record, and sibling_hashes are the hashes of the sibling nodes in the path.

[0296] MBT time - interval proof path:

[0297] Proof MBT ([t1,t2]) = {B + path, interval sub - root}

[0298] Super - audit root anchoring structure:

[0299] AuditSuperRoot = H(rootHash TxReg ||rootHash AddOwner ||rootHash AccessLog …)

[0300] where || represents the hash concatenation operation, and H(·) is the hash function selected by the system, which is used to uniformly aggregate all the root nodes of the audit sub - structures and submit them to the main - chain contract for registration to achieve immutable anchoring.

[0301] Complex Query Unit: This unit is used to implement multi-field combined queries on off-chain stored data while ensuring the immutability of on-chain index information. By combining the on-chain trusted state structure FlowState and the composite index mechanism built in the off-chain distributed dynamic storage engine DASE, this unit meets the efficient operation requirements of users in aspects such as filtering traffic data using keywords, verifying on-chain state consistency, and judging access permissions.

[0302] Typical query scenarios supported by the system include:

[0303] Combined matching query of protocol and label: {protocol, label};

[0304] Filtering of protocol and time range conditions: {protocol, timeRange};

[0305] Filtering of task range and extended field keywords: {sideChainId, extFields.keywords};

[0306] Combined judgment of user identity and data ownership: {label, ownerId}.

[0307] To implement the above capabilities, the system divides all retrievable fields as shown in Table 2 below:

[0308] Table 2

[0309]

[0310] Among them, the construction form of the off-chain index structure is as follows:

[0311] IndexEntry DASE :

[0312] = {protocol → [flowId1, flowId2,...], label → [...], (protocol, label) → [...]}

[0313] This structure supports the combined inverted mapping of composite fields (such as protocol + label), and a combined index can be established in MySQL using BTREE, compoundindex in MongoDB, and multi-condition combined filtering can be achieved in Elasticsearch by combining bool query syntax.

[0314] The query process includes the following steps:

[0315] S3-3-1. Construct a query expression The user constructs a logical expression according to the query target, and the structured form is as follows:

[0316]

[0317] Wherein, represents a single query logical request, including a keyword set, logical connectors, and range limits for parsing by the query engine.

[0318] S3-3-2. Submit to the side chain DA interface engine

[0319] The system calls the DASE query engine to convert it into a query plan, match the corresponding inverted or combined index structure, and return an initial result set:

[0320]

[0321] S3-3-3. Query the on-chain FlowState and perform hash verification

[0322] The flowId corresponding to each query returns the main chain storage structure:

[0323] FlowState(flowId):={Hash(Flow),ownerList,sideChainId,…}

[0324] The querier can recalculate Hash(Flow) based on off-chain data, compare it with the on-chain record to ensure that the data has not been tampered with, or call the contract ProveAndVerify(flowId) to complete the status verification.

[0325] S3-3-4. Permission verification and access control determination

[0326] If the user has a decentralized identity (DID), the system will use the permission contract AuthMod to perform the judgment:

[0327] IsOwner(flowId,userId,sideChainId)→{true,false}

[0328] If the result is true, the system will return the data access path accessURL. This path contains the request erDID and its signature field for off-chain node identity and permission verification.

[0329] S3-3-5. Query behavior registration and log auditing

[0330] A successful query will generate a behavior log FlowQueryLog, with the structure:

[0331]

[0332] The log record is written to the MBT AccessLog A structure with its root hash rootHash AccessLog It is regularly submitted to the main-chain contract AuditRootMapping to achieve traceable auditing.

[0333] S3-3-6, Audit Proof Ability

[0334] Supports the following proof paths:

[0335] Time Interval Log Audit Path (MBT):

[0336]

[0337] Where matchedflowIds is the set of query results this time, and audithashpath is the set of hash paths used to construct The root node.

[0338] Super Audit Root Proof Path:

[0339] AuditSuperRoot = H(rootHash TxReg ||rootHash AccessLog ||…)

[0340] In the formula, || represents the hash concatenation operation, and H(·) is a cryptographic hash function (such as SHA-256 or Keccak-256). This root node is used for main-chain anchoring and unified audit interface.

[0341] Refer to Figure 5 As shown, the trusted main-chain module specifically includes a model management and multi-role identity registration mechanism, side-chain anchoring and status summary recording, a full-chain management unit and a cross-chain scheduling mechanism, and a cross-chain interaction mechanism for joint scheduling of the main chain and side chains, as follows:

[0342] Model Management and Multi-Role Identity Registration Mechanism: In this mechanism, all participating parties register and maintain a unique DIDDocument (DID document) through the main chain to achieve traceable verification of identities, permission mapping, and trusted auditing. The implementation of this mechanism includes a distributed trusted identifier and a trusted identity information framework, identity registration, distributed trusted identifier mapping, distributed trusted identifier life cycle, and side-chain mapping process.

[0343] Specifically, the underlying implementation of the distributed trusted identifier and the trusted identity information framework is as follows:

[0344] Distributed Identifier Structure:

[0345] Each participating party binds a globally unique DID in the system, and the identification form is as follows:

[0346] User: did:main:user- <user-id>

[0347] Main chain node: did:main:node- <node-id>

[0348] Sidechain node: did:main:sidechain- <sidechain-id>:node- <node-id>

[0349] Governance Committee: did:main:sidechain- <sidechain-id>

[0350] Model service provider: did:main:sidechain- <sidechain-id>:model- <model-id>

[0351] Distributed Trusted Identity Document Content Structure:

[0352] Each DID corresponds to a DID document, which records fields such as the bound public key, service endpoints, permission policies, identity status, etc. For example:

[0353] DIDDoc = {publicKey, usagePolicy, status, metadata, …}

[0354] Where: publicKey: The main public key owned by the identity entity; usagePolicy: The access or call permission policy; status: The validity status, such as active (valid), revoked (revoked); metadata: Other identity extension information, such as model accuracy description, credit score, etc.

[0355] Characteristics of the Identity Information Trust Framework Architecture:

[0356] All users and nodes can independently manage their private keys. The main chain is only responsible for verifying the uniqueness of their DIDs and the legality of signatures. When trading, using the private key to sign constitutes an identity statement, and the contract executes the permission control logic based on the signature content. The processes of DID registration, update, and cancellation are all uniformly recorded by the contract in the immutable ledger of the main chain, forming a complete audit path.

[0357] Specifically, the system completes identity registration and distributed trusted identity mapping for the following five types of entities through the main chain contract, and its implementation is as follows:

[0358] First, the registration of the distributed trusted identity of ordinary users:

[0359] DID format:

[0360] did:main:user - <user_id>

[0361] DID document structure:

[0362]

[0363] Field interpretation:

[0364] publicKey: The user's public key, used for identity authentication and transaction signing; assets: The asset snapshot of the user in the system, which can be an integer or a structure (such as balance + Token list); creditScore: The user's credit score calculated by the system or the side chain (the value range is generally 0–1000); taskParticipation: The list of side chain tasks participated by the current user:

[0365] taskParticipation = [sideChain_001, sideChain_043, …]

[0366] Among them, sideChain_i represents the side chain number; status: indicates the current status of the user DID, and the values include: active: valid; frozen: frozen; revoked: revoked.

[0367] Second, main chain node registration

[0368] DID format:

[0369] did:main:node-<node_id>

[0370] DID document structure:

[0371]

[0372] Field interpretation: nodePublicKey: the consensus layer public key of this main chain node; nodeType: node type, defined as follows:

[0373] nodeType ∈ {FullNode, LightNode}

[0374] FullNode: stores the full chain data and participates in consensus; LightNode: stores key data and performs simple verification; networkInfo: the access address or network service endpoint of the node, such as http: / / node123.mychain.net:8080; status: the operating status of the node (such as active, inactive, suspended, etc.).

[0375] Third, side chain task node registration

[0376] DID format:

[0377] did:main:sidechain-<sidechain_id>:node-<node_id>

[0378] DID document structure:

[0379]

[0380] Field interpretation: scNodePublicKey: the key used by this node in the corresponding side chain; nodeType: node role type, defined the same as the main chain node; networkInfo: the node network connection address; status: the service status of this node in the side chain.

[0381] Fourth, registration of the side-chain governance committee

[0382] DID format:

[0383] did:main:sidechain-<sidechain_id>

[0384] DID document structure:

[0385]

[0386] Field interpretation:

[0387] governanceKey: The multi-signature governance key or unified signature public key used by the committee;

[0388] members[]: An array of members, storing the DID list of node members:

[0389] members

[0390] = [did:main:sidechain_X:node_001,did:main:sidechain_X:node_002,…]

[0391] votingPolicy: Voting policy, taskTemplate: The identifier of the side-chain task template issued by this committee, pointing to the side-chain task specification; modelID: The DID of the model service used or maintained:

[0392] modelID = did:main:sidechain-<sidechain_id>:model-<model_id>

[0393] sideCh ainPolicy: User access policy, defining reputation thresholds, etc.

[0394] Fifth, registration of the model service provider

[0395] DID format:

[0396] did:main:sidech ain-<sidech ain_id>:model-<model_id>

[0397] DID document structure:

[0398]

[0399] Field interpretation:

[0400] modelOwner: DID of the model service provider; address: the calling address of the model service, in the format of URL or service endpoint identifier; publicKey: the master public key used by the model service provider to sign transactions or responses; modelPublicKey: the homomorphic encryption inference public key used by the model (such as the public key in the CKKS domain); modelHash: the hash value of the model structure and parameters, used for version integrity verification; modelMetadata: a structure field that records the model name, version, precision, etc., such as:

[0401] modelMetadata={name:"ResNet20",version:"v2.3",accuracy:96.5%}

[0402] usagePolicy: call restriction policy, such as call frequency limit, token required for call payment, etc.

[0403] Specifically, the distributed trusted identity lifecycle and side chain mapping process are as follows:

[0404] S4-1-1, Distributed Trusted Identity Registration:

[0405] The participants generate a key pair and submit RegisterDID (DIDDoc);

[0406] The main chain verifies its uniqueness and signs it, writes it into the block and generates rootHash;

[0407] The contract returns a registration event and broadcasts the update to the entire network.

[0408] S4-1-2. DID update and revocation:

[0409] Submit the UpdateDID(DIDDoc') transaction, the main chain saves the new version and retains the old version;

[0410] Revocation can be completed through RevokeDID(DID), and the status field is marked as revoked, which will be automatically deemed invalid in subsequent transactions.

[0411] S4-1-3, Sidechain mapping mechanism:

[0412] The side chain completes the binding of participant permissions by parsing the DID document on the main chain;

[0413] Special fields (such as committee.members[]) are used to determine whether a user is qualified for governance;

[0414] Both the flow ownership and the identity verification in model service calls are based on comparing the public key after unpacking the DID.

[0415] Sidechain state anchoring mechanism: This mechanism periodically submits the sidechain state digest (stateDigest) to the main chain to construct an immutable marker of the sidechain state on the main chain, thereby achieving trusted anchoring and cross-chain auditing.

[0416] First, the sidechain system itself has a blockchain structure. That is, several blocks are generated internally in chronological order, numbered as block k . Each block has a block header, which records the global state root of the block The hash value prev_hash of the previous block, the current height k, and other auxiliary fields form the following structure:

[0417]

[0418] In the formula, represents the global state root of the block (such as the Merkle root of the account state tree or the DID document storage tree); prev_hash represents the hash of the previous block header; k represents the current block height.

[0419] Next, the sidechain node executes the hash function H(·) on the content of the block header to obtain the hash value of the block header That is:

[0420]

[0421] On this basis, the current state digest digest is extracted k , specifically:

[0422]

[0423] In the formula, H(·) represents the hash function (such as SHA-256); ‖ represents the string concatenation operation; the omitted items may include the signature digest of the current block, the task number, and other additional elements used to identify the state characteristics.

[0424] After the sidechain height grows to a certain threshold, for example, more than Δ blocks different from the previous anchored block, the anchored node selected by the sidechain governance committee initiates a state anchoring transaction and submits a transaction with the following structure to the main chain:

[0425] Tx anchor ={sidechainID,k,digest k ,sig(·)}

[0426] Among them, sidechainID represents the unique identifier of the sidechain; k represents the current sidechain block height; digest k is the current sidechain status digest; sig(·) represents the digital signature generated by the governance node or its threshold multi-signature, which is used to verify the authenticity of the anchoring statement.

[0427] The SidechainAnchorContract smart contract is deployed on the main chain to receive the above transactions and perform status updates in its function commitDigest(uint sidechainId, uint blkHeight, bytes32 digest).

[0428] After the submission is successful, the main chain status structure anchorMap[sidechainId][blkHeight] will be updated to:

[0429] anchorMap[sidechainId][k] = digest k

[0430] At the same time, the event AnchorCommied(sidechainId, blkHeight, digest) is triggered to synchronize the status change to all listening nodes, and finally the on-chain record is completed in the new block of the main chain, realizing the immutable anchoring of the sidechain status on the main chain.

[0431] When cross-chain calls are needed or auditing operations are performed on the sidechain status, any verifier can achieve trusted verification based on the following steps:

[0432] S4-2-1. Read the main chain anchoring structure:

[0433]

[0434] S4-2-2. Obtain the block header data of the sidechain at the corresponding height k:

[0435]

[0436] S4-2-3. Calculate the local status digest:

[0437]

[0438] S4-2-4. Compare whether the anchored value is consistent with the locally reconstructed value:

[0439]

[0440] If the two are consistent, it means that the status of the sidechain at block height k has indeed been anchored on the main chain and has not been tampered with; otherwise, the status is considered untrusted.

[0441] Full-chain Management Unit: This unit includes a governance committee registration and change mechanism and an access and exclusion mechanism for ordinary users. This unit relies on the distributed trusted identifier (DID) mechanism on the main chain for role identification registration and archiving, supplemented by state management and policy control within the side chain to ensure that all key roles within the system can be dynamically identified, authorized, and audited.

[0442] Specifically, the implementation method of the governance committee registration and change mechanism is as follows:

[0443] The governance committee is the core governance entity for each side chain, responsible for tasks including parameter configuration, member update, upgrade control, and arbitration voting. The governance entity is uniquely registered with the distributed trusted identifier DID, and its format is defined as:

[0444] did:main:sidechain- <sidechain-id>:gov- <committee-id>

[0445] In the formula, <·> is the identifier of a specific example.

[0446] The document structure corresponding to this DID contains at least the following fields:

[0447] members: A list of members, which is an array of strings in the form of "did:main:user-123";

[0448] policies: Configuration of governance strategies and voting rules;

[0449] thresholdSigKey: Threshold signature public key information;

[0450] governanceHistory: An array of hash digests of governance change records.

[0451] During the registration process of the governance committee, the side chain creator or its designated role needs to first call the registration function registerDID(did, DID_Doc) on the main chain, and the contract will complete the field verification and uniqueness proof storage operations. DID_Doc is the structured data of the governance committee DID document, which becomes effective immediately after being written to the main chain.

[0452] When the governance structure is adjusted (such as adding or deleting members, changing voting strategies, etc.), an update proposal must be initiated by the existing committee members. After the update proposal reaches a consensus on the side chain through a multi-signature mechanism or committee deliberation, updateDID(did, DID_Doc_new) is called to write the new DID_Doc to the main chain ledger. The main chain retains the update transaction number, block number, and the hashes before and after the change through an immutable record mechanism for subsequent auditing. This process forms an auditable governance lifecycle link.

[0453] Specifically, the implementation of the ordinary user admission and exclusion mechanism can be achieved through the following steps:

[0454] The user identity is also registered with a DID, and its format is:

[0455] did:main:user- <user-id>

[0456] The corresponding DID document contains fields including but not limited to:

[0457] publicKey: the user's public key; assets: the assets or collateral it holds; creditScore: the scoring value of the system for the user's behavior and reputation; authentication: the identity authentication parameter or associated identifier; status: the user status (valid, frozen, revoked, etc.).

[0458] S4-3-1. Admission steps:

[0459] The user first creates its identity by calling the main chain function createDID(did, DID_Doc), and then submits an admission application to the side chain after completion. The side chain reviews the applying users according to preset policies (such as the minimum credit score).

[0460] The calculation of the user's credit score can use the following weighted function:

[0461] creditScore = baseScore + w1·α1w2·β + w3·I(assets > threshold)

[0462] In the formula:

[0463] α1 represents the historical task completion rate; β represents the cumulative number of successful complaints; I(·) is an indicator function, which takes the value of 1 if the condition is met, otherwise 0; w1, w2, and w3 are scoring weights.

[0464] When creditScore ≥ c0 (threshold), the side chain can accept the user, write it into the side chain status storage structure such as userList, and call the main chain anchoring contract function approveUser(sidechainId, userDID) to synchronize the admission information to the main chain contract SidechainAnchorContract to complete the joint authentication of the main chain and the side chain.

[0465] S4-3-2. Exclusion steps:

[0466] When the user's behavior is abnormal, the credit drops, or the banning policy is triggered (such as hitting the blacklist, credit score < c min etc.), the governance committee can initiate a user exclusion proposal. The process is as follows:

[0467] Automatically trigger policy detection (such as a decrease in the user score);

[0468] The governance committee reaches an exclusion consensus according to the voting threshold set in policies;

[0469] Invoke revokeUser(did) in the side chain to remove its access rights and resource occupancy;

[0470] Invoke removeUser(sidechainId, userDID) in the main chain to remove the user registration information under the specified side chain; If the user is involved in mortgaged assets or task deposits, the asset disposal plan will be executed according to the arbitration contract for refund or destruction.

[0471] S4-3-3. Policy field control steps:

[0472] User admission and exclusion behaviors are controlled by the side chain governancePolicy policy, and its logical structure is as follows: minCreditScore: minimum credit score; banList: permanent ban list; slashingRules: number of complaints and penalty amounts; autoApproval: whether to enable automatic approval; approvalThreshold: definition of the governance committee signature threshold (such as "2-of-3 MultiSig").

[0473] Each field in the above policy needs to be linked and parsed with the DID document field. For example, when the value of the creditScore field in the user DID is less than minCreditScore, access will be refused.

[0474] Cross-chain interaction mechanism jointly scheduled by the main chain and side chains: This mechanism includes a side chain registration and discovery mechanism, a cross-chain request routing mechanism, and a cross-chain status synchronization and coordination mechanism, ensuring that secure and verifiable interaction operations can be completed between different side chain systems, and full-process auditing can be achieved through the unified view of the main chain.

[0475] Specifically, the specific implementation method of the side chain registration and discovery mechanism is as follows

[0476] To ensure the credibility of cross-chain access and the effectiveness of routing, after each side chain starts, it needs to be registered in the main chain and write into the distributed trusted identifier (DID, Distributed Identifier) document.

[0477] First, side chain registration and main chain record:

[0478] When each side chain is initialized, submit a registration transaction by invoking the SidechainRegistryContract contract in the main chain, and the registration information includes:

[0479] Side chain identifier sidechainID

[0480] Distributed identifier did:main:sidechain- corresponding to the governance committee <sidechain-id>

[0481] Chain type, anchoring period, consensus mechanism, model binding number modelID

[0482] Meta-information such as side chain policy sideChainPolicy

[0483] After the main chain records the event SidechainRegistered, a side chain discovery entry is formed.

[0484] Second, node and service declaration:

[0485] All side chain nodes and service roles need to register their identity information through the main chain, and the format is:

[0486] Node: did:main:sidechain-xxx:node- <node-id>

[0487] Model service provider: did:main:sidechain-xxx:model- <model-id>

[0488] The main chain contract establishes a mapping relationship:

[0489]

[0490] Third, identity and reputation discovery mechanism:

[0491] The initiator of cross-chain communication (such as side chain A) can query the DID document of the target side chain B, parse its subordinate node information, and read fields such as:

[0492] governanceMembers[]: governance node identity;

[0493] creditScore: current credit score;

[0494] sideChainPolicy: access control policy.

[0495] This can be used to determine whether the target node is trustworthy and whether it has the authority to receive cross-chain instructions.

[0496] Specifically, the specific implementation of the cross-chain request routing mechanism is as follows:

[0497] The main chain, as the information center of each side chain, plays the role of "request scheduling + path discovery" in this mechanism to support cross-chain task calls and data transmission. The cross-chain request routing mechanism includes cross-chain request generation and distribution on the main chain side, route mapping and forwarding, and chain-side authentication and execution.

[0498] First, cross-chain request generation and distribution on the main chain:

[0499] The user or node initiates a cross-chain access request on the main chain, calls the InterChainRouterContract contract, and submits the following fields:

[0500] Tx cross :={callerDID,sidechainID target ,targetServiceDID,payload,signature}

[0501] In the formula, callerDID is the caller identity; sidechainID target Indicates the target side chain number; targetServiceDID is the distributed identifier of the node to be called; payload is the data or method parameter requested for execution; signature is the signature of the request structure by the caller.

[0502] Second, route mapping and forwarding:

[0503] Main chain maintenance mapping:

[0504]

[0505] According to the routing policy (such as the shortest path, minimum load), select the most suitable gateway DID from them and forward the request to the target side chain gateway node.

[0506] Thirdly, side chain authentication and execution:

[0507] After receiving the request, the target side chain gateway node performs the following operations:

[0508] Verify whether the caller DID meets the local sideChainPolicy;

[0509] If the permission field judgment (such as minCreditScore) is enabled in the policy, then verify whether the initiator meets the threshold;

[0510] If passed, call the service node bound to the targetServiceDID to execute the task;

[0511] If rejected, return an error code and write it to the rejection log InterChainRejectLog.

[0512] Specifically, the specific implementation method of the cross-chain status synchronization and coordination mechanism is as follows:

[0513] To prevent inter-chain status conflicts and data inconsistencies, the following status anchoring and coordination mechanism is proposed:

[0514] S4-4-1. Side chain anchor summary submission:

[0515] Every fixed period (such as every Δ blocks), the side chain is signed by the governance committee and a summary is generated:

[0516]

[0517] In the formula, is the block hash; is the global state root; H(·) represents the hash function (such as SHA-256).

[0518] And it is packaged into an anchor transaction:

[0519] Tx anchor ={sidechainID,k,digest k ,sig(·)}

[0520] After being uploaded to the chain, it is written by the main chain contract SidechainAnchorContract:

[0521] anchorMap[sidechainID][k]:= digest k

[0522] S4-4-2, Main Chain Status Audit:

[0523] The main chain node or the third-party verifier can obtain the header data corresponding to any side chain block k Calculate the local digest local , and verify:

[0524]

[0525] S4-4-3, Abnormality Coordination and Chain Rollback:

[0526] If inconsistency is found, the main chain contract can trigger an arbitration process, and the side chain governance committee will vote according to the field votingPolicy to decide whether to trigger:

[0527] Chain reorganization (roll back to the anchor point)

[0528] User asset freezing / punishment

[0529] Data locking and status freezing

[0530] All processes will be written into the audit chain structure for future reference.

[0531] The present invention also provides an electronic device, including a bus, a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor. The transceiver, the memory, and the processor are connected through the bus. When the computer program is executed by the processor, the steps in the above-mentioned trusted traffic data distributed storage system based on the main side chain are implemented. Compared with the prior art, the beneficial effects of the electronic device provided by the present invention are the same as those of the above-mentioned trusted traffic data distributed storage system based on the main side chain, and will not be elaborated here.

[0532] The present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned trusted traffic data distributed storage system based on the main side chain are implemented. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present invention are the same as those of the above-mentioned trusted traffic data distributed storage system based on the main side chain, and will not be elaborated here.

[0533] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the embodiments, reference can be made to each other. For the methods disclosed in the embodiments, since they correspond to the devices disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description of the device part.

[0534] Specific examples are used in this article to elaborate on the principles and implementation manners of the present invention. The descriptions of the above embodiments are only used to help understand the method and its core idea of the present invention. At the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manners and application scopes. In summary, the content of this specification should not be construed as a limitation to the present invention. < / methodtoinvoke> < / did> < / resource> < / host> < / protocol>

Claims

1. A distributed storage system for trusted traffic data based on a main side-chain, characterized in that Including: A traffic collection module, which is used to collect encrypted traffic data generated in the network in real time, and perform preliminary standardization processing on the encrypted traffic data to obtain standardized encrypted traffic data; A traffic side-chain proof module, which is used to perform integrity verification and authenticity construction on the standardized encrypted traffic data to prevent data from being tampered with or forged, and form verified encrypted traffic data; A traffic side-chain data module, which is used to structurally store the verified encrypted traffic data and retain queryable records in the side chain; A trusted main-chain module, which is used to record data summaries, verification records, access behaviors, and model voting result information on the side chain.

2. The trusted traffic data distributed storage system based on the main and side chains according to claim 1, wherein The traffic collection module includes: A task allocation and data collection unit, which is used to use distributed traffic probe nodes to select collection tasks according to their own status, and submit task acceptance commitments through the main-chain smart contract. After being authenticated by the main chain, the node starts the traffic capture module to collect encrypted traffic data. After the collection is completed, the traffic probe node performs preliminary screening on the encrypted traffic data, judges the traffic category according to the task template parameters in the task, filters out non-target traffic data and classifies and stores it in the local buffer pool; A data format standardization unit, which is used to convert the collected encrypted traffic data using structured fields to form standardized encrypted traffic data, and organize and index it locally using a block and sub-task structure.

3. The distributed storage system for trusted traffic data based on the main side chain according to claim 2, wherein The traffic side-chain proof module includes: A governance committee unit, which is used to complete the threshold key generation and update of the unified inference key in the system; A deduplication proof unit, which is used to check for duplicates in the standardized encrypted traffic data and remove duplicate encrypted traffic data; A validity proof unit, which is used to perform trusted inference and on-chain verification on the collected encrypted traffic data using homomorphic encryption and proxy re-encryption algorithms.

4. The trusted traffic data distributed storage system based on the main side chain according to claim 3, wherein In the member election process of the governance committee unit, first, the governance contract on the main chain evaluates the qualifications of candidate nodes; the main chain synchronously triggers the side-chain nodes to conduct weighted voting on the candidate nodes that have passed the qualification evaluation, and screens the top k nodes with the most votes as the members of the new round of governance committee, and broadcasts them to all listeners; when the list of the new round of governance committee members is synchronized to the side-chain consensus nodes, the threshold generation process of the current round of inference key will be immediately started; the specific process is executed by the committee's trusted distributed key unit, and the steps are as follows: Each committee member first captures the CommitteeElected(event) event trigger in the side-chain contract event listening module and enters the key initialization stage; The committee members negotiate a common seed as the shared parameter for generating the key, and jointly generate a secret private key item by combining the pseudo-random generation algorithm and the indexsharing protocol; The nodes exchange key commitments and verification proofs with each other to verify the honesty of the private key generation process; If it is found that a certain node has malicious behavior, the node will be excluded from the current round of process and its malicious state will be recorded; After all the key commitment items of the verified committee nodes are merged, a unified public inference public key pk is calculated agg , and at the same time, each committee member locally stores its corresponding private key shard sk i , which is not shared or broadcast with other nodes and remains in a secret state.

5. The distributed storage system for trusted traffic data based on the main side chain according to claim 4, characterized in that In the deduplication proof unit, the single encrypted traffic data collected is set as F i , the local node first executes the standard hash function H(·) on the single encrypted traffic data to calculate its complete data hash value: hashOfFullData: = H(F i ) Wherein, H(·) represents a preset hash function, which is used to generate a hash digest with a fixed length from the input original traffic data F i ​ The local node maintains a "registered hash table" which records all the traffic hash values that have been packaged or submitted by the current node, and the hash value of each new traffic data will be matched with the existing items in it: If the system will consider that the data has a "possibility of duplication" and terminate the subsequent transaction packaging process; If then it is allowed to enter the transaction packaging stage and wait for on-chain submission; When a user or a collection node initiates a traffic registration transaction Tx Reg the system enters the on-chain duplicate check process; the transaction structure includes the following fields: Tx Reg (flowId, hashOfFulData, accessURL, protocol, label, timeRange, …) The side-chain contract layer maintains an independent global hash map for each task T k The mapping relationship is defined as:​ Among them, represents the task T k corresponding hash registration index table; The contract processes the Tx Reg Before the transaction, first verify the signature sig of the data submitter Owner , which is encrypted by the data owner using the private key sk Owner to generate the traffic hash value: Subsequently, the contract uses its corresponding public key pk Owner to perform signature verification: Verify(sig Owner , hashOfFullData, pk Owner ) = True Wherein, represents the private key signature operation based on the elliptic curve encryption algorithm, and Verify(·) represents the corresponding public key signature verification operation; If the signature verification fails, that is, Verify = False, the contract immediately rejects the transaction to prevent forged or tampered data from entering the system; If the signature verification passes, enter the duplicate check determination: If there is It indicates that the current data has been registered by other nodes, and the system will reject this transaction: If the contract is regarded as the first registration, continue to complete the transaction process, and update the flow hash value and its transaction metadata to 6. The trusted traffic data distributed storage system based on the main side chain according to claim 5, characterized in that, In the validity proof unit, the governance committee issues a task template TaskTemplate through the main chain contract, binds the side chain document, task ID, and model identifier, and completes the deposit operation through the following function: updateDID(sideChainDocument(tasjTemplate,modelID)) Among them, updateDID(·) is the task definition deposit interface, and sideChainDocument(·) is the specified side chain task document; Based on the dataset provided by the governance committee, the model service provider trains the model using a deep learning structure and exports the standard format ONNX; During the execution phase of the encryption model, the model side first encrypts the original model weights according to the aggregated public key pk of the governance committee agg to generate an encrypted inference model that can run in the homomorphic encryption domain; the user side encrypts the traffic sample F i using the same key system or local conversion mechanism and uploads it after encryption; the encrypted inference model directly performs convolution and activation operations in the ciphertext space and outputs the encrypted inference result: Among them, represents the encrypted inference model encrypted with the aggregation key pk agg Enc(F i ) is the ciphertext input uploaded by the user; Under the authorization condition, the governance committee collaborates to generate a threshold re-encryption key, and each committee member has a private key shard: {sk1, sk2, …, sk n} Just any subset that satisfies the threshold condition can recover the aggregated private key sk agg of the equivalent structure: Among them, λ i is the Lagrange interpolation coefficient, and sk i is the shard of the private key of the i-th committee member; On this basis, the system calls the threshold re-encryption function: rk agg→v = ThresholdReKeyGen(sk agg , pk v ) or Among them, rk agg→v is the proxy re-encryption key from the aggregated key domain pk agg to the verification end public key pk v , and g is the public generator set by the system; The re-encryption unit is executed at the model side. First, it verifies the received key rk agg→v as follows: Verify(rk agg→v ,pk v ,sig GC ) == True Among them, sig GC is the joint signature of the governance committee or a zero-knowledge proof; The inference output structure is denoted as: where y i is the inference output result, and h i is the traffic identifier hash; the re-encryption process is as follows: Final ciphertext C′ out can be decrypted by the verification end using the private key sk v as follows: After obtaining the ciphertext from the model side, the verification end performs local decryption to obtain the inference result.

7. The distributed storage system for trusted traffic data based on the main side chain according to claim 6, characterized in that The traffic side chain data module includes: A traffic registration unit, which is used to realize the trusted registration, index management, and verification traceability of encrypted traffic data by combining the side chain and the main chain collaborative structure; A side chain storage unit, which adopts a multi-layer nested storage architecture, including a traffic status table FlowState, a distributed dynamic storage engine DASE, and a heterogeneous Merkle audit structure, and is used to support the structured storage, index retrieval, and distributed audit verification of encrypted traffic data; A multi-keyword complex query unit, which is used to realize the multi-field combined query of off-chain stored data on the premise of ensuring the immutability of on-chain index information.

8. The trusted traffic data distributed storage system based on the main side chain according to claim 7, wherein In the traffic registration unit, the acquisition node obtains the original encrypted traffic data from the network, denoted as Flow, and generates a corresponding validity verification structure through the model inference module to form a verification structure body in the following format: FlowProof:={y i ,Hash(Flow),sig,metadata where y i represents the model inference output, Hash(Flow) is the hash of the original data, sig is the signature of the uploader or the verification end, and metadata represents additional information. The original traffic data ontology is not directly uploaded to the chain, but is saved in the flow_main table of the distributed dynamic storage engine; only the data hash and reference pointer are recorded on the chain to decouple the deposit and access; the validity verification task is executed by the specified verification node verifier, and the verification result and timestamp information will be written into the consensus structure as part of the on-chain registration content; After receiving the traffic registration transaction Tx Reg the blockchain system calls the verification function: ProveAndVerify(FlowProof) Check the verification structure; after passing the verification, enter the transaction initialization process, broadcast the consensus and write it into the state database, and the recorded fields include: verifier: The node address that executes the verification task; resultHash = H(y i ||txHash): A non-repudiable hash calculated by concatenating the inference output result y i and the transaction hash txHash; verifyTimestamp: The on-chain timestamp when this verification task is completed; The system then broadcasts an event: emitFlowRegistered(flowId,resultHash,verifier,verifyTimestamp) to ensure that each node of the side chain receives the registration synchronization signal; Registration transaction Tx Reg The structure definition is as follows: Among them, flowId represents the unique traffic identifier, accessURL represents the off-chain data location pointer, protocal, label, and timeRange represent traffic classification and indexing identifiers, sideChainId represents the ID of the side chain where it is located, which can be regarded as the task template number, ownerList represents the list of current legitimate owner addresses, verifier represents the verification node address, resultHash represents the verification result hash, and verifyTimestamp represents the verification timestamp; After successful registration, the DASE data indexing engine will establish a multi-dimensional inverted index structure based on the fields protocol, label, timeRange, and sideChainId to support field-level retrieval queries; In the state storage layer, the blockchain maintains the core meta-information structure FlowState, and its format is as follows: Wherein, all fields are consistent with Tx Reg Keep consistent, and the consensus nodes complete disk writing and distributed storage to ensure that any node can quickly retrieve based on the flowId; If it is necessary to verify the integrity of off-chain data, the client can request the hash Hash(·) of the original data from the accessURL and compare it with the hash field in the FlowState. If they are consistent, it indicates that the data has not been tampered with. If it is necessary to verify the validity of the inference, resultHash = H(y i ||txHash) can be taken, and the verification signature of the verification end and the model logic are used for recalculation and verification, which are used for liability auditing and data tradability management.

9. The distributed storage system for trusted traffic data based on the main side chain according to claim 8, wherein In the traffic registration unit, in the multi-keyword complex query unit, the query process includes: The user constructs a logical expression according to the query target, and the structured form is as follows: In the formula, represents a primary query logic request, which includes a keyword set, logical connectors, and range restrictions for parsing by a query engine; The system call DASE query engine will be converted into a query plan, match the corresponding inverted or combined index structure, and return the initial result set: The flowId corresponding to each query returns the main chain storage structure: FlowState(flowId):={Hash(Flow),ownerList,sideChainId,…} The queryer recalculates Hash(Flow) based on the off-chain data and compares it with the on-chain record to ensure that the data has not been tampered with, or calls the contract ProveAndVerify(flowId) to complete the status verification; If the user has a decentralized identity (DID), the system will use the permission contract AuthMod to execute the judgment: IsOwner(flowId,userId,sideChainId)→{true,false} If the result is true, the system will return the data access path accessURL, which contains the requesterDID and its signature field for off-chain node identity and permission verification; A successful query will generate a behavior log FlowQueryLog, and the structure is: Write the log record to MBT AccessLog Structure, with its root hash rootHash AccessLog Periodically submit it to the main chain contract AuditRootMapping to achieve traceable auditing.

10. The distributed storage system for trusted traffic data based on the main side chain according to claim 9, characterized in that, The trusted main chain module includes: The model management and multi-role identity registration mechanism unit is used to manage users, nodes, side chain governance parties, and model service providers, and through the main chain, it realizes unified registration and tamper-proof identity binding to support trusted model calls and identity audits in a cross-side chain environment; Side-chain anchoring and status summary recording unit, which is used to generate a status summary digest on the side-chain k , and periodically submit it to the main-chain contract for anchoring, so as to form an immutable global consensus record in the main-chain ledger, and achieve trustworthy recording of the side-chain running status and cross-chain verifiability; The full-chain management unit and the cross-chain scheduling mechanism unit are used to complete the life cycle management of governance committee members and ordinary users under the cooperation mechanism of the main chain and the side chain.

Images