A privacy data processing method based on trusted data space

Abstract

The present invention discloses a privacy data processing method based on a trusted data space, specifically relating to the field of privacy data management, and is used to address the redundant exposure risk problem in existing smart contract multi-source privacy data calls, including: establishing a sensitive variable trigger path mapping table by traversing the contract call branches, and generating a path judgment graph structure by Booleanizing the trigger conditions; matching path nodes based on external input parameters, extracting a set of activated sensitive variables, marking inactivated variables as sandboxed, and setting a key request blocking control. For activated variables, an inert call structure is inserted during the contract compilation phase, triggering a data loading operation only when the path hits and executes to the corresponding branch; after the call process ends, a destruction instruction is executed on the cache of the sandbox variable, and a structural summary is generated and written out, thereby achieving full-process structural control and exit closed-loop of sensitive data access behavior.

Description

Technical Field

[0001] The present invention relates to the technical field of privacy data management, and more specifically, to a privacy data processing method based on a trusted data space. Background Art

[0002] In multi-institutional collaborative applications within the financial industry, smart contracts, as the core logical structure for trusted execution, are widely used in highly data-sensitive tasks such as joint anti-fraud, joint risk control, and credit penetration. To safeguard data sovereignty and privacy, these smart contracts typically rely on trusted data spaces and employ key escrow, multi-party encryption, and multi-source data isolation to access private data. However, an underestimated privacy risk persists during actual contract execution: because existing smart contract engines generally pre-parse all variables in the execution path by default, some sensitive data may be included in the intermediate state processing flow and decrypted into execution memory or the intermediate call stack even when logical conditions are not met. These untriggered but loaded private variables do not produce actual output, but are susceptible to abuse or theft during audits, debugging, and memory leaks, posing a "logical path privacy exposure" issue.

[0003] Currently, the industry has not yet formed a fine-grained variable access control mechanism for this type of problem, nor does it lack a semantic constraint system for the linkage analysis of execution paths and data calls. This results in structural exposure vulnerabilities in smart contracts when processing multi-source privacy information, seriously affecting the construction of a secure boundary for trusted collaboration of financial data.

[0004] In order to solve the above problems, a technical solution is now provided. Summary of the Invention

[0005] In order to overcome the above-mentioned defects of the prior art, an embodiment of the present invention provides a privacy data processing method based on a trusted data space to solve the problems raised in the above-mentioned background technology.

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

[0007] A method for processing private data based on a trusted data space comprises the following steps:

[0008] S1: Traverse the code of each call branch in the smart contract, identify the sensitive variables involved in the call branch statements, and establish a trigger path mapping table for sensitive variables;

[0009] S2: Based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors to generate a path judgment condition graph structure;

[0010] S3: Receive the parameter set input by the external caller, and count the activation sensitive variable set corresponding to the path node in the path judgment condition graph structure of the current execution context;

[0011] S4: For all sensitive variables that are not in the activated sensitive variable set, mark their variable status as sandbox state and set key blocking tags to prohibit them from sending key request instructions to the trusted data space;

[0012] S5: For sensitive variables in the activated sensitive variable set, during the contract compilation phase, the deferred execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered;

[0013] S6: When the contract lifecycle ends, execute the destruction instruction for the sensitive variables recorded as sandbox state, and erase all caches during the branch call.

[0014] In a preferred embodiment, in S1, code traversal is performed on each call branch in the smart contract, sensitive variables involved in the call branch statements are identified, and a trigger path mapping table of sensitive variables is established, which specifically includes:

[0015] Identify control structure units with conditional expressions in the source code structure of the smart contract and mark the execution entry of each control structure unit;

[0016] Perform execution entry scanning on the code block corresponding to each control structure unit, and construct a call variable set consisting of variable identifiers, corresponding to the variable entities accessible by the branch in the static state;

[0017] Filter all variable items obtained through off-chain requests in the call variable set and mark the corresponding variable items as sensitive variables with trusted space-related attributes;

[0018] Each sensitive variable and the corresponding control structure unit execution entry and conditional expression are integrated into a ternary vector relationship and uniformly stored in the sensitive variable trigger path mapping table.

[0019] In a preferred embodiment, in S2, based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors, and the path judgment condition graph structure is generated, which specifically includes:

[0020] Extract all conditional items corresponding to the conditional expressions from the sensitive variable trigger path mapping table as logical decision factors, and return them to a set of non-repeated logical decision factors;

[0021] The set of logical decision factors is numbered, and a Boolean dimension index sequence is generated based on the numbering sequence;

[0022] Map all conditional expressions into binary codes on the Boolean dimension index sequence, generate conditional vector sets corresponding to sensitive variables, and each conditional vector set serves as a path node;

[0023] In the conditional vector set corresponding to the sensitive variable, a one-way edge connection is generated between two nodes where any vector dimension has a value of one at the same time;

[0024] Integrate the one-way edge connection relationships of all sensitive variables corresponding to path nodes and construct a path judgment condition graph structure.

[0025] In a preferred embodiment, in S3, receiving a parameter set input by an external caller and counting the activation sensitive variable set corresponding to the path node in the path judgment condition graph structure of the current execution context specifically includes:

[0026] Receive the parameter set input by the external caller and construct the Boolean condition vector set of the input parameters according to the Boolean dimension index sequence;

[0027] Retrieving a path node set that completely matches the Boolean condition vector set of the input parameter in the path judgment condition graph structure as a hit path node set;

[0028] Read the sensitive variables bound to the hit path node and aggregate them into the initial activation variable set of the current context;

[0029] The reachable node set is derived based on the graph connectivity edge tracing of the hit node, and the initial activation variable set is expanded to the complete activation variable set.

[0030] In a preferred embodiment, in S4, for all sensitive variables that are not in the activated sensitive variable set, their variable states are marked as sandbox states, and key blocking tags are set to prohibit them from sending key request instructions to the trusted data space. Specifically, the steps include:

[0031] Extract the full set of sensitive variables from the sensitive variable trigger path mapping table, exclude the variable items that already exist in the activated sensitive variable set, and obtain the inactivated sensitive variable set of the current call context;

[0032] Add a sandbox status identification field to each variable in the inactive sensitive variable set. The sandbox status identification field uses the path node of the current call context as a binding parameter.

[0033] Configure the key request control bit on each inactive sensitive variable to which the sandbox status identification field is attached, and initialize the control bit to the blocking state;

[0034] Construct a call-period isolation list, which consists of a set of two-tuples consisting of each sandbox state variable and its binding path node.

[0035] In a preferred embodiment, in S5, for sensitive variables in the activated sensitive variable set, during the contract compilation phase, the deferred execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered, specifically including:

[0036] Extract the Boolean vector of each path node that activates the sensitive variable binding as the lazy loading condition;

[0037] During the contract compilation phase, the data loading logic for each activated sensitive variable is encapsulated as a delayed execution body. The delayed execution body is a delayed execution code block built around the variable access function.

[0038] The delayed execution body is attached and bound to the call branch structure to which the Boolean vector of its corresponding path node belongs, forming a path trigger binding relationship;

[0039] When the execution flow reaches the call branch corresponding to the activated sensitive variable and the lazy loading condition is met, the bound delayed execution body is triggered to complete the data loading process of the corresponding activated sensitive variable.

[0040] In a preferred embodiment, the variable access function is the execution entry of the control structure unit in the source code of the smart contract.

[0041] In a preferred embodiment, in S6, when the contract lifecycle ends, executing a destruction instruction on the sensitive variables recorded as sandboxed, and erasing all caches during the branch call specifically include:

[0042] When the function call stack corresponding to the call branch returns, the corresponding contract lifecycle is marked as terminated, the sandbox sensitive variable set and the variable cache during the current call are scanned, and the cache items that match the sandbox variable set are extracted;

[0043] Record the cache item set and call period path judgment condition graph node number of this clear operation, generate a structural summary containing the cache item set and call period path node number, and construct a destruction information summary unit;

[0044] Output the destruction information summary unit as the final write-out item before the end of the contract life cycle, completing the exit processing of the sandbox sensitive variables in the current round of execution.

[0045] The technical effects and advantages of the privacy data processing method based on the trusted data space of the present invention are as follows:

[0046] This solution implements structured control of the sensitive data access process in smart contracts by constructing a sensitive variable trigger path mapping table and introducing a path judgment condition graph structure. During execution, external input parameters are converted into Boolean vectors and matched with path graph nodes to determine which sensitive variables are activated in the current context. Unactivated sensitive variables are marked as sandboxed and configured with a key request blocking control bit to prevent them from being accessed when the path is not hit. For activated variables, a lazy loading mechanism is used to delay the binding of data request behavior to the actual execution path of the call branch. Data loading operations are only performed when the control flow enters the branch and the trigger condition is met. After the call process ends, the cache contents of all sandboxed variables generated during execution are automatically erased to prevent access traces of non-hit variables from remaining.

[0047] This mechanism effectively avoids the redundant exposure of variable structures in traditional contracts, such as preloading or intermediate parsing when the path is not triggered. It constructs a privacy variable access control chain based on path identification, which features structural computability, predictable access behavior, and recyclable variable status, effectively improving the privacy isolation capabilities of contracts in multi-source data processing scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 This is a schematic diagram of a privacy data processing method based on a trusted data space according to the present invention. DETAILED DESCRIPTION

[0049] The following will provide a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0050] Example 1

[0051] Figure 1 The present invention provides a privacy data processing method based on a trusted data space, which includes the following steps:

[0052] S1: Traverse the code of each call branch in the smart contract, identify the sensitive variables involved in the call branch statements, and establish a trigger path mapping table for sensitive variables;

[0053] S2: Based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors to generate a path judgment condition graph structure;

[0054] S3: Receive the parameter set input by the external caller, and count the activation sensitive variable set corresponding to the path node in the path judgment condition graph structure of the current execution context;

[0055] S4: For all sensitive variables that are not in the activated sensitive variable set, mark their variable status as sandbox state and set key blocking tags to prohibit them from sending key request instructions to the trusted data space;

[0056] S5: For sensitive variables in the activated sensitive variable set, during the contract compilation phase, the deferred execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered;

[0057] S6: When the contract lifecycle ends, execute the destruction instruction for the sensitive variables recorded as sandbox state, and erase all caches during the branch call.

[0058] In S1, the code of each call branch in the smart contract is traversed, the sensitive variables involved in the call branch statements are identified, and a trigger path mapping table of sensitive variables is established.

[0059] The processing target is a financial smart contract code deployed on a multi-party privacy data sharing platform. This contract contains multiple branching logics controlled by input parameters, semantically used to dynamically load user profiles, credit data, or geographic risk parameters. First, the contract's source code is parsed to construct a code structure diagram based on an abstract syntax tree (AST). Control structure units containing Boolean expressions are then identified at the node level. Specifically, structure unit identification is based on syntax type, selecting conditional blocks such as if, require, or switch-case. Each structure unit in the AST corresponds to a directed control unit with an entry point (i.e., a Boolean expression) and an execution body (i.e., a code block). Based on the statement number, file location, and function scope, the execution entry point of each structure unit is identified. This is the line containing the Boolean conditional expression of the control structure, which serves as the path entry identifier for the structure unit. For example, the expression if(input.role=="admin"){...} is identified as control structure unit A, and its execution entry point is the line corresponding to input.role=="admin". Through a complete structural scan, we obtain a set of entry conditional expressions for all control structure units and their bindings, which serve as the foundational entry set for subsequent static variable access determination and trigger path mapping. This stage forms a data structure of triple sets, enabling unified numbering and formatted extraction of control structure semantic entries, providing a structural anchor for subsequent variable determination and path binding operations.

[0060] After entering each identified control structure unit, a statement-level line-by-line scan is performed within its corresponding executable body, parsing the variable calls involved in each statement. This process utilizes a static semantic parsing approach, using a symbol table to manage variable names, data sources, and function call structures appearing in the current code block, and to identify each potential variable access path. Variable calls include direct field access, function return value assignments, and off-chain interface calls. Variables that directly or indirectly represent contract state or external data references are included in the call variable set. Within each control structure unit, a call variable set is constructed for that structure, consisting of variables potentially executable under the current structure path. For example, for structure A, whose code block contains statements such as decrypt(token_identity) and oracle.getScore(user_id), the variables token_identity and score are identified as potentially accessible data entities under the current structure path and are marked as statically accessible variables of structure A. After this step is completed, all control structure units have bound variable access sets, which serve as the predicate data structure for binding paths to variable accesses.

[0061] After obtaining all structural units and their call variable sets, the trusted attribute identification phase begins. The goal of this phase is to identify all variables accessed through off-chain data sources (such as oracles, external interfaces, and key decryption services) and label them as "trusted space-associated attributes." During execution, for each variable in the call variable set, its source statement is traced. If the variable is returned by an external interface function, calculated by a decryption operation, or obtained through a trusted data channel, the variable is labeled as sensitive. For example, if the variable score originates from oracle.getScore(user_id), score is determined to be a variable calculated in the off-chain trusted space. If the variable token_identity originates from decrypt(encrypted_token), it is also considered a sensitive decrypted variable. On-chain fields such as amount or timestamp are not labeled as sensitive. Using call context tracking combined with data source identification, variable entries belonging to the trusted data space are extracted from the variable set under all structural paths and recorded as a set of key-value pairs. This step distinguishes between ordinary contract state variables and sensitive data items that require controlled access, and completes the data source determination and trusted identifier binding of sensitive attributes, providing a data filtering basis for the construction process of the path mapping structure.

[0062] After sensitive variables are identified, each sensitive variable is bound to the execution entry of the control structure unit in which it appears and the conditional expression of that entry into a unified structure and written into the sensitive variable trigger path mapping table. The mapping table is organized as a ternary vector structure, with each record representing the semantic relationship of a sensitive variable being triggered by a path condition constraint in the contract logic. Taking the variable token_identity as an example, if it appears in control structure A and the entry condition of A is input.role=="admin", the triplet {token_identity, input.role=="admin", A} is generated. All structural units are processed sequentially, and each sensitive variable is bound to its logical trigger condition and control structure to construct a complete path mapping structure. Ultimately, all sensitive variables involved in the entire contract are archived as record items with path structure constraints, forming a unified sensitive variable trigger path mapping table. This mapping table will serve as the sole reference table for subsequent path Boolean encoding, input parameter vectorization processing, variable activation determination, and lazy loading logic. It features a clear structure, unique determination conditions, and reversible variable positioning. It serves as the semantic basis for this solution's refined variable access control and sandbox mechanism scheduling.

[0063] In S2, based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors to generate a path judgment condition graph structure.

[0064] The sensitive variable trigger path mapping table is traversed, and the conditional expressions in each entry are parsed to extract the smallest semantic unit constituting the conditional judgment, namely the logical decision factor. A decision factor is defined as an indivisible atomic conditional term in Boolean logic, typically expressed as a comparison expression between an input parameter and a specific value, such as an equality check, a numerical range check, or an enumeration match. A syntax tree-based conditional term extraction algorithm is used to parse the compound expression into a Boolean tree structure, extracting the decision statement at the smallest leaf node level step by step. For example, the expression "role=="admin"&&city=="Beijing" is split into two decision factors: "role=="admin"" and "city=="Beijing". For conditional terms with similar expression structure but repeated semantics in different paths, a ternary semantic hash index is created by combining the field name, operator, and target value. This is then used to de-duplicate and merge all conditional terms to generate a set of logical decision factors. This merged set is structurally unique, with no redundant decision dimensions, ensuring the consistency and computability of the subsequent vector encoding structure. This set will serve as the basic input for Boolean dimension construction, and will perform unified abstraction of sensitive variable access control paths at the structural dimension level.

[0065] After extracting and merging the logical decision factors, each item in the set is numbered. This numbering rule uses a globally fixed order to ensure consistency in the Boolean encoding dimension. Specifically, each decision condition item in the decision factor set is sorted according to pre-set ordering rules (such as lexicographic order, field priority, and field type order) and assigned a unique number in sequence. This creates a decision factor number table with the structure {F1: condition item a, F2: condition item b, F3: condition item c, ...}. The numbers F1, F2, F3... serve as the dimensional indexes for the subsequent Boolean vector structure. After the numbering process is complete, the decision factor set is structured into an ordered sequence of Boolean dimensional indices. This sequence is independent of the content of the sensitive variables and is derived entirely from the logical decision items involved in the path structure, ensuring repeatable and neutral Boolean conversion of the input parameter set. All subsequent variable trigger paths are mapped within this Boolean dimensional index space. The numbering table serves as the fundamental index mapper for the Boolean encoder and path node builder, remaining unchanged throughout its lifecycle. The construction of Boolean dimension index sequence lays the foundation for the fundamental structural framework of path node logical encoding, path matching judgment and logical consistency of structural connection edges.

[0066] After obtaining the Boolean dimension index sequence, Boolean encoding is performed on each conditional expression in the sensitive variable trigger path. Each trigger condition expression is broken down into several determinants, each of which has an index number registered in the dimension sequence. For each expression, a Boolean vector with the same length as the Boolean dimension index sequence is constructed and initialized to all zeros. Then, based on the determinant terms contained in the current expression, the corresponding dimension positions are assigned a value of 1, while all other non-appearing terms remain 0. The resulting Boolean vector represents the logical projection of the path activation condition for the sensitive variable in a unified Boolean space. Each Boolean vector is defined as a path node and is accompanied by its associated sensitive variable identifier, achieving a structural mapping from path logic to variables. Throughout the variable set encoding process, modeling is performed only at the path level, without introducing specific variable data values ​​or value space encoding. Instead, Boolean abstraction is performed based on structural logic. This approach ensures direct compatibility with subsequent input parameter Boolean vectors and establishes a unified encoding foundation for logical association analysis between path nodes. The Boolean vectors of all variables are output as a sensitive variable condition vector set. Each vector item in the set is bound to a sensitive variable, providing a structural unit for subsequent path diagram construction and variable activation judgment.

[0067] Structural graph modeling is performed on the generated set of sensitive variable conditional vectors. The goal is to construct edge connections between path graph nodes through the "intersection coincidence" of conditional logic. During this operation, all vectors in the conditional vector set are compared pairwise. For each pair of path node vectors Q and P, the Boolean values ​​of each dimension are checked to see if they both have a value of 1. Specifically, if any dimension F_i exists such that Q_i = 1 and P_i = 1, then paths Q and P are considered to have a logical intersection on that conditional dimension. A unidirectional edge is established from Q to P, indicating that Q can logically extend to P or that both paths are partially reachable based on variable triggering logic. This unidirectional edge not only records conditional commonality but also reflects the structural similarity of triggering paths between variables, providing a topological structure for path graph analysis and boundary propagation judgment. A structural identifier is generated for each edge, recording its connecting node number and triggering intersection dimension, thus forming a complete set of logically connected structures. After this step is completed, the logical common connection relationship between all nodes in the path diagram is structured, providing a graph basis for full-graph connectivity analysis, variable group activation expansion, and conditional redundancy judgment.

[0068] After constructing the logical connections between all nodes, the set of sensitive variable condition vectors is treated as the node set of the path graph, and the set of logical commonality connection edges is treated as the directed edge set. The overall path judgment condition graph structure is constructed. This graph structure is a directed graph G(V,E), where V represents all path nodes, i.e., the Boolean vector representation of all sensitive variables, and E represents the unidirectional edges with conditional intersections between all nodes. Each node structure in the graph includes a variable identifier, an activation condition Boolean vector, a binding trigger condition expression, and the identifier of the control structure to which it belongs, providing full structural mapping capabilities. Each edge in the graph represents the logical reachability between variables, providing a structural basis for input condition fuzzification, variable activation expansion, lazy loading scheduling, and other steps.

[0069] In S3, a parameter set input by an external caller is received, and a set of activation sensitive variables corresponding to the path nodes in the path judgment condition graph structure of the current execution context is counted.

[0070] The smart contract receives a structured set of parameters from an external caller as input for this execution context. For example, in a federated identity authentication scenario, the input parameter set might include fields such as role, city, amount, and user_status. After receiving this input parameter set, the Boolean vector builder module is invoked to vectorize the input parameters according to a predefined Boolean dimension index sequence. This Boolean dimension index sequence is the encoding result of the aforementioned conditional factor set. The dimension order is fixed, and the field judgment rules are clear. For example, F1 represents role=="admin", F2 represents amount>10000, and F3 represents city=="Shanghai". For the current input parameter, the corresponding factor for each dimension is checked in turn: if it holds, the dimension is assigned a value of 1; otherwise, it is assigned a value of 0, thus forming a Boolean conditional vector. For example, if the current input is role="admin" and amount=8000, but city="Beijing", the corresponding Boolean vector is [1,0,0]. To accommodate multi-path scenarios, when the input parameters contain multiple field combinations that may simultaneously hit the path, multiple vector items can be constructed to form a Boolean condition vector set for the input parameters. This structure is used to locate the set of hit path nodes in subsequent matching operations and is the core mechanism for mapping the logical state of the input parameters to the contract execution path structure.

[0071] After the input Boolean vector is constructed, the path node matching process begins. This process loads a pre-built path judgment condition graph structure. Each node in this graph structure represents a Boolean vector representation of a sensitive variable trigger path and includes information about the corresponding bound variables. The Boolean vector set of the input parameters is matched within the graph structure. The matching rule is: if the Boolean vector of a graph node is identical to the input vector in all dimensions, the path node is considered to be hit by the current execution context. The matching method uses a bitwise comparison of Boolean values, combined with a vector index optimization structure for batch querying, ensuring that matching efficiency is maintained even when the number of path nodes is large. Nodes with unknown dimensions or those that do not affect the current trigger condition are ignored during the matching process, focusing on the complete hit condition path. Given a set of input conditions, multiple path nodes may be hit. A hit node set is then constructed, containing the node numbers of all nodes in the structure whose trigger conditions are exactly the same as the current input.

[0072] After obtaining the set of hit path nodes, a variable unbinding operation is performed on each node to extract the set of sensitive variable identifiers registered in its structure. Each path node has a logical trigger binding relationship with one or more sensitive variables, which was injected during the graph structure construction phase. For example, path node number Node_3 may be bound to the variable token_identity, and node Node_5 may be bound to the variable city_profile, and so on. All hit node numbers are scanned sequentially, and their corresponding variable sets are merged, removing duplicates to form the initial activation variable set. This variable set represents the list of sensitive variables that the contract allows to be activated and accessed in the path where the logical structure is completely hit under the current input parameters. Variable loading or decryption is not performed at this stage; only activation marking of access rights and structure-level preparation are performed. Once a variable enters the initial activation variable set, it will have the conditions to participate in lazy loading binding and data call permissions in subsequent executions.

[0073] After constructing the initial set of activated variables, the connectivity of the hit nodes in the path judgment graph structure is further analyzed to discover additional variable nodes that share commonalities or path compatibility in terms of logical conditions. During the path judgment graph construction phase, a one-way edge between each path node indicates that the two paths have a consistent logical determinant value on a Boolean dimension, meaning that the two variable paths may partially overlap under the input conditions. Using the set of hit nodes as the starting point for graph traversal, reachability tracing is performed on the graph structure. Specifically, one-way edge tracing is performed for each hit node, collecting the numbers of all directly or indirectly reachable nodes. These nodes, while not fully hit by the current input, exhibit logical intersection with the hit path. Within the permitted scope of business policies, the sensitive variables bound by these paths are considered structurally reachable, thus meeting the pre-activation conditions. The variable sets corresponding to all reachable path nodes are merged into the initial activated variable set to form the complete activated variable set, representing the complete set of sensitive variables considered potentially loadable in the current execution context. This set is used to subsequently construct the lazy loading structure and sandbox variable decision boundary. By introducing a graph reachability extension mechanism, while retaining strict path judgment, the ability to express path overlap and logical compatibility is increased, the variable access island problem caused by conditional expression splitting is avoided, and the judgment flexibility of the structural model under complex input conditions is enhanced.

[0074] In S4, for all sensitive variables that are not in the activated sensitive variable set, their variable states are marked as sandbox states, and key blocking tags are set to prohibit them from sending key request instructions to the trusted data space.

[0075] All registered sensitive variable identifiers are extracted from the pre-stored "Sensitive Variable Trigger Path Mapping Table." This mapping table records all controlled variables involved in the smart contract's logical structure and represents the complete set of variables that can be called by the path control logic during contract execution. To avoid repeated processing of variables that have already been allowed access, a full set difference operation is performed. This compares the variable items in the full set with the set of activated variables in the current context, removes the variable items already included, and obtains the set of remaining inactivated variables. This set is the sensitive variables involved in the path not triggered by the current input parameters but to which access has not yet been granted.

[0076] For each variable instance in the set of inactive variables, a sandbox status identification field is appended. The sandbox status identification field takes the set of hit path nodes in the current execution context as its parameter and generates a unique structure identifier through hash encoding. This identifier indicates that the variable is passively blocked due to the failure to meet the trigger conditions in the current call path. This field is a state bit block appended to the variable metadata structure. It does not change the basic structure of the variable in the logical model and serves only as an isolation behavior identifier during runtime. In scenarios where multiple variables share path trigger logic, different variables may share the same sandbox identification parameter structure, but the fields must still be appended separately to ensure independent variable-level access control. A separate namespace is reserved for the sandbox status field in the variable structure to avoid confusion with other permission control bits. The field value contains a Boolean vector summary of the call path, a set of path node numbers, and the current call round number. It is traceable, auditable, and unforgeable. This field is generated only in specific isolation trigger scenarios during the variable lifecycle and does not contribute to storage overhead at other stages. By constructing sandbox status identification, a structural-level shielding mechanism is established for sensitive variables, making the access rights of variables explicitly judgeable and the isolation status traceable, fundamentally preventing the privacy exposure risk of variables in untriggered paths being pre-loaded or implicitly solved.

[0077] After adding the sandbox status identification field, key request control logic is configured for each sandbox variable. This prevents variables from indirectly triggering data loading through decryption interfaces, external trusted data sources, or off-chain call channels while in sandbox state. A "key request control bit" field is injected into the variable control structure. This Boolean field serves as an execution switch to determine whether key requests are permitted during variable invocation. For all sandboxed variables, their control bit is initialized to "blocked," meaning that key requests are not permitted in any manner within the current execution context. This control bit is configured using a deferred call structure bound to the variable access function, isolating the control logic from the access path. During runtime, when attempting to access a variable, the contract virtual machine first determines whether the control bit is in the permitted state. If it is blocked, the variable access instruction is aborted and a rejection signal is returned. This mechanism not only blocks the active call path for the variable but also prevents "access inheritance" issues caused by variables being called by other variables in multiple function paths. The control bit setting structure supports multi-level nesting, distinguishing contract paths, calling functions, and context batches, enabling finer access control granularity. This design provides strong access boundaries for sensitive variables, establishing dual protection between the structure layer and the execution layer, ensuring that sandboxed variables have no loading channels in the event of a path miss, further enhancing the execution protection capabilities of privacy isolation.

[0078] An isolation control index structure, called the "call-period isolation list," is constructed for the current call cycle. This list structure is used to track the logical relationship between each isolated variable and its corresponding trigger path during the call, supporting subsequent audits, call interruption determination, and lifecycle cleanup operations. It represents the path node number or Boolean vector index mapped to its trigger path condition. The list is maintained as the isolation index table in the current call context, attached to the contract execution context, and provides an interface for other modules to access the table status. The isolation list is dynamically maintained during the call cycle. If a variable's path changes or its permissions are unlocked during multiple executions, its record in the isolation list will be actively removed. Conversely, if the path conditions do not change, the list content remains consistent throughout the call cycle. This structure provides a determinate reference point for path-level access to isolation status during smart contract execution, making variable isolation status enumerable and structurally storable.

[0079] In S5, for sensitive variables in the activated sensitive variable set, during the contract compilation phase, the delayed execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered.

[0080] For each activation-sensitive variable, the Boolean vector corresponding to its binding path node is extracted. This Boolean vector, explicitly assigned during the path judgment graph construction phase, represents the logical mapping of the variable's triggering conditions in Boolean space. This Boolean vector serves as the lazy loading condition for variable loading, determining when the variable is allowed to be loaded and accessed. During the compilation phase, all reference locations of activation-sensitive variables are scanned and their access logic is encapsulated to construct a deferred execution body. The deferred execution body is built around the variable access function. For example, if the variable binding operation is decrypt(score), this function is embedded in the deferred execution body as the main calling logic, and the lazy loading condition is injected as a precondition statement. Each deferred execution body constitutes an independent code block, featuring bindability, schedulability, and path reference closure. The encapsulation format adheres to pluggable logical structures recognizable in the contract language, such as function wrappers, code macros, or path trigger mapping tables. During the encapsulation process, the variable context remains unchanged, and only the access path is structurally deferred, ensuring that the original access logic is executed as is when the path triggering conditions are met. This phase does not trigger variable access; it only completes execution preprocessing and binding condition preparation. This structure allows code-level delay of variable access, keeping the variable structure inaccessible when path conditions are missed. This effectively prevents the risk of implicit execution of variable pre-decoding, memory mapping, or key requests caused by pre-compilation optimizations, early loading, or default structure binding.

[0081] After contract compilation is complete, during the actual deployment and execution phase, variable access behavior is controlled by a deferred execution mechanism. In each call round, the input parameter vector is first constructed and matched against the path nodes. The input is then determined to satisfy the Boolean vector conditions of any path node bound to an activated sensitive variable. When a node in the path determination graph matches the condition vector bound to an activated variable and execution enters the call branch structure attached to it, the variable's lazy loading condition is determined to be met. At this point, the deferred execution body bound to the variable is activated, and the encapsulated variable access function, such as a key request call, off-chain data fetch, or state value read, is executed. This loading action triggers the return of the sensitive variable's true value and grants the variable access status for the current call. After the deferred execution body executes, the loading status is recorded and the variable is marked as "triggered" to avoid duplicate loading and support result caching. If the lazy loading condition is not met, the variable access structure remains unreferenced, no data is requested, no computation resources are consumed, and the audit path is not entered. This execution strategy ensures that variables can only be loaded if a path hits and a control structure is entered. This dynamic control mechanism prevents sensitive variables from being accessed from unauthorized paths. Furthermore, a delayed body trigger log is recorded for subsequent sandbox variable difference determination and lifecycle cleanup operations, creating a closed-loop access trace.

[0082] In S6, when the contract lifecycle ends, the destruction instruction is executed on the sensitive variables that have been recorded as sandbox state, and all caches during the branch call are erased.

[0083] Lifecycle determination is performed based on the call stack's rollback state in the execution environment: When the execution flow has exited all logical path control structures and there are no pending path nodes in the current execution context, the current call flow is considered to have naturally terminated. The function call stack clear event serves as the "lifecycle termination trigger condition," and this state is marked as the termination indicator for the current contract context. Subsequently, the cache cleanup process begins. First, the "sandbox sensitive variable set" registered during this execution cycle is retrieved. This set originates from the variable structure identification process for the previous path miss. All variable cache entries generated during this call flow are synchronously retrieved from the runtime cache, and a hash map structure is constructed. A set comparison is performed using the variable identifier as the index dimension. The comparison logic is: if a variable cache entry exists in the runtime record structure and its identifier appears in the sandbox variable set, the cache entry is considered to require purging. Such cache entries include untriggered pre-decryption intermediate states, variable decoding preparation areas, and off-chain call result binding items.

[0084] After cache item identification is complete, the structured destruction summary construction phase begins. This phase aims to structurally record the upcoming sandbox variable cache purge, ensuring auditable and verifiable historical traceability during the contract exit phase. First, the identifiers of all pending variable cache items are recorded and combined with the set of path judgment condition graph node numbers hit during the current call round. The path node number set is derived from the historical record module of variable activations and path structure hits, representing the judgment of the control structure conditional logic during contract execution. The variable cache item set and the path node set are combined into a binary structured summary, which is compressed using a structured hash method to form a structured summary carrier. This summary carrier is embedded as a structural unit in a storage format called a "destruction information summary unit." The internal structure of this unit includes a list of purge variable indexes, a binding path number index, a contract instance hash signature, a call round identifier, and a timestamp, ensuring structural uniqueness and execution verifiability. This summary unit does not store actual variable values ​​or intermediate execution states, only the structure index to prevent information leakage.

[0085] In the final phase before the expiration of the lifecycle, the constructed destruction information summary unit is persisted as the final writeout item of the current contract execution context. This writeout operation is performed before the call stack is fully rolled back and execution control is reclaimed, ensuring that all variable behavior records are closed and archived at the structural level. The destruction information summary unit is output to the contract-bound structural evidence storage area or audit interface area. Depending on the contract platform's support, it can be written to the on-chain data area, the audit contract channel, or an external trusted logging service. The writeout operation utilizes a signature submission mechanism to ensure that the summary information is proactively initiated by the current contract execution instance and is verifiable, preventing forgery or overwriting. After the writeout is complete, all cache structures associated with sandboxed variables in the current context are marked as "terminated," and a memory clear instruction is executed, completely releasing any accessible state of the variables left in this call cycle. This process does not affect the variable's ability to be reactivated in subsequent calls, but it resets its access readiness, ensuring that subsequent activations must re-qualify the path judgment condition. After writing the destruction summary unit, the lifecycle termination status and path determination status are written into the execution audit trail, forming a complete closed-loop chain of contract variable behavior from "path determination → variable activation → sandbox variable isolation → cache generation → summary writing." Through this mechanism, sensitive variables have a cleanable, provable, and traceable exit path in each round of execution, greatly improving the security integrity and governance audit capabilities of contracts in the field of private data access control.

[0086] The above formulas are all dimensionless and numerical calculations. The formulas are obtained by collecting a large amount of data and performing software simulation to obtain the most recent real situation. The preset parameters and thresholds in the formulas are set by technicians in this field according to actual conditions.

[0087] The above embodiments can be implemented in whole or in part via software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. The computer program product comprises one or more computer instructions or computer programs. When loaded or executed on a computer, the processes or functions described in the embodiments of this application are fully or partially performed. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired means (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server or data center that contains a collection of one or more available media. The available medium can be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., DVDs), or semiconductor media. The semiconductor media can be a solid-state drive.

[0088] Those skilled in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0089] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0090] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0091] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, and may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0092] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0093] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0094] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0095] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A privacy data processing method based on a trusted data space, characterized in that: The steps include: S1: Traverse the code of each call branch in the smart contract, identify the sensitive variables involved in the call branch statements, and establish a trigger path mapping table for sensitive variables; S2: Based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors to generate a path judgment condition graph structure; S3: Receive the parameter set input by the external caller, and count the activation sensitive variable set corresponding to the path node in the path judgment condition graph structure of the current execution context; S4: For all sensitive variables that are not in the activated sensitive variable set, mark their variable status as sandbox state and set key blocking tags to prohibit them from sending key request instructions to the trusted data space; S5: For sensitive variables in the activated sensitive variable set, during the contract compilation phase, the deferred execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered; S6: When the contract lifecycle ends, execute the destruction instruction for the sensitive variables recorded as sandbox state, and erase all caches during the branch call; In S2, based on the sensitive variable trigger path mapping table, the trigger conditions of all sensitive variables are converted into Boolean vectors to generate the path judgment condition graph structure, which specifically includes: Extract all conditional items corresponding to the conditional expressions from the sensitive variable trigger path mapping table as logical decision factors, and return them to a set of non-repeated logical decision factors; The set of logical decision factors is numbered, and a Boolean dimension index sequence is generated based on the numbering sequence; Map all conditional expressions into binary codes on the Boolean dimension index sequence, generate conditional vector sets corresponding to sensitive variables, and each conditional vector set serves as a path node; In the conditional vector set corresponding to the sensitive variable, a one-way edge connection is generated between two nodes where any vector dimension has a value of 1 at the same time; Integrate the one-way edge connection relationships of all sensitive variables corresponding to the path nodes to construct the path judgment condition graph structure; In S3, a parameter set input by an external caller is received, and the activation sensitive variable set corresponding to the path node in the current execution context hit path judgment condition graph structure is counted, specifically including: Receive the parameter set input by the external caller and construct the Boolean condition vector set of the input parameters according to the Boolean dimension index sequence; Retrieving a path node set that completely matches the Boolean condition vector set of the input parameter in the path judgment condition graph structure as a hit path node set; Read the sensitive variables bound to the hit path node and aggregate them into the initial activation variable set of the current context; The reachable node set is derived based on the graph connectivity edge tracing of the hit node, and the initial activation variable set is expanded to the complete activation variable set.

2. The method for processing private data based on a trusted data space according to claim 1, characterized in that: In S1, the code of each call branch in the smart contract is traversed to identify the sensitive variables involved in the call branch statement. The trigger path mapping table of the sensitive variables is established, which specifically includes: Identify control structure units with conditional expressions in the source code structure of the smart contract and mark the execution entry of each control structure unit; Perform execution entry scanning on the code block corresponding to each control structure unit, and construct a call variable set consisting of variable identifiers, corresponding to the variable entities accessible by the branch in the static state; Filter all variable items obtained through off-chain requests in the call variable set and mark the corresponding variable items as sensitive variables with trusted space-related attributes; Each sensitive variable and the corresponding control structure unit execution entry and conditional expression are integrated into a ternary vector relationship and uniformly stored in the sensitive variable trigger path mapping table.

3. The method for processing private data based on a trusted data space according to claim 1, characterized in that: In S4, for all sensitive variables that are not in the activated sensitive variable set, their variable states are marked as sandbox states, and key blocking tags are set to prohibit them from sending key request instructions to the trusted data space. Specifically, the following steps are performed: Extract the full set of sensitive variables from the sensitive variable trigger path mapping table, exclude the variable items that already exist in the activated sensitive variable set, and obtain the inactivated sensitive variable set of the current call context; Add a sandbox status identification field to each variable in the inactive sensitive variable set. The sandbox status identification field uses the path node of the current call context as a binding parameter. Configure the key request control bit on each inactive sensitive variable to which the sandbox status identification field is attached, and initialize the control bit to the blocking state; Construct a call-period isolation list, which consists of a set of two-tuples consisting of each sandbox state variable and its binding path node.

4. The method for processing private data based on a trusted data space according to claim 1, characterized in that: In S5, for sensitive variables in the activated sensitive variable set, during the contract compilation phase, the deferred execution body is bound to the corresponding call branch structure. When the execution flow enters the call branch, the data loading process of the corresponding sensitive variable is triggered, specifically including: Extract the Boolean vector of each path node that activates the sensitive variable binding as the lazy loading condition; During the contract compilation phase, the data loading logic for each activated sensitive variable is encapsulated as a delayed execution body. The delayed execution body is a delayed execution code block built around the variable access function. The delayed execution body is attached and bound to the call branch structure to which the Boolean vector of its corresponding path node belongs, forming a path trigger binding relationship; When the execution flow reaches the call branch corresponding to the activated sensitive variable and the lazy loading condition is met, the bound delayed execution body is triggered to complete the data loading process of the corresponding activated sensitive variable.

5. The method for processing private data based on a trusted data space according to claim 4, characterized in that: The variable access function is the execution entry of the control structure unit in the source code of the smart contract.

6. The method for processing private data based on a trusted data space according to claim 1, characterized in that: In S6, when the contract lifecycle ends, the destruction instruction is executed on the sensitive variables recorded as sandbox state, erasing all caches during the branch call, including: When the function call stack corresponding to the call branch returns, the corresponding contract lifecycle is marked as terminated, the sandbox sensitive variable set and the variable cache during the current call are scanned, and the cache items that match the sandbox variable set are extracted; Record the cache item set and call period path judgment condition graph node number of this clear operation, generate a structural summary containing the cache item set and call period path node number, and construct a destruction information summary unit; Output the destruction information summary unit as the final write-out item before the end of the contract life cycle, completing the exit processing of the sandbox sensitive variables in the current round of execution.

Images