Private data processing method based on trusted data space

Abstract

The invention discloses a private data processing method based on a trusted data space, and particularly relates to the field of private data management, which is used for solving the problem of redundancy exposure risk in the existing smart contract multi-source private data calling, and comprises the following steps of: establishing a sensitive variable trigger path mapping table by traversing contract calling branches, boolean processing is carried out on the trigger condition to generate a path judgment graph structure; and matching path nodes according to external input parameters, extracting an activation sensitive variable set, marking unactivated variables as a sandbox state, and setting key request blocking control. For an activation variable, inserting an inert call structure in a contract compiling stage, and triggering a data loading operation only when a path hits and is executed to a corresponding branch; and after the calling process is finished, executing a destruction instruction on the cache of the sandbox variable, generating a structural abstract, and writing out the structural abstract, so as to realize full-process structure control and closed loop quitting of the 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 the multi-institutional collaborative application of the financial industry, smart contracts, as the core logical structure of trusted execution, are widely used in tasks with extremely high data sensitivity, such as joint anti-fraud, joint risk control, and credit penetration. In order to protect data sovereignty and privacy security, such smart contracts usually rely on trusted data space and use key escrow, multi-party encryption, multi-source data isolation and other methods to call private data. However, in the actual contract execution process, there is still an underestimated privacy risk point: because the 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 even when the logical judgment conditions are not met, and be decrypted into the execution memory or intermediate call stack. Such untriggered but loaded privacy variables do not produce actual output, but are easily abused or stolen in auditing, debugging, memory leakage and other situations, constituting a "logical path privacy exposure" problem.

[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: A privacy data processing method based on a trusted data space comprises the following steps: S1: Traverse the code of each call branch in the smart contract, identify the sensitive variables involved in the call branch statement, and establish a trigger path mapping table of 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: receiving a parameter set input by an external caller, and counting the set of activated sensitive variables corresponding to the path nodes in the hit path judgment condition graph structure of the current execution context; S4: For all sensitive variables not in the activated sensitive variable set, mark their variable status as sandboxed and set a key blocking tag to prohibit them from sending key request instructions to the trusted data space; S5: For the sensitive variables in the activated sensitive variable set, during the contract compilation phase, bind the deferred execution body to the corresponding call branch structure. When the execution flow enters this call branch, trigger the data loading process of the corresponding sensitive variable; S6: When the contract life cycle terminates, execute the destruction instruction on the sensitive variables that have been recorded as sandboxed, and erase all caches during branch calls.

[0007] In a preferred embodiment, in S1, traversing the code of each call branch in the smart contract to identify the sensitive variables involved in the call branch statement and establishing a trigger path mapping table for sensitive variables specifically includes: Identifying the control structure units with conditional expression forms in the source code structure of the smart contract and marking the execution entry of each control structure unit; Scanning the execution entry of the code block corresponding to each control structure unit to construct a call variable set composed of variable identifiers, which are the variable entities accessible in the corresponding branch in the static state; Filtering all variable items obtained through off-chain requests in the call variable set and marking the corresponding variable items as sensitive variables with trusted space association attributes; Integrating each sensitive variable with the execution entry and conditional expression of the corresponding control structure unit into a ternary vector relationship and uniformly storing it in the sensitive variable trigger path mapping table.

[0008] In a preferred embodiment, in S2, based on the sensitive variable trigger path mapping table, converting the trigger conditions of all sensitive variables into boolean vectors and generating a path judgment condition graph structure specifically includes: Extracting the condition items corresponding to all conditional expressions from the sensitive variable trigger path mapping table as logical judgment factors and aggregating the non-repeated logical judgment factor set; Numbering the logical judgment factor set and generating a boolean dimension index sequence based on the numbering order; Mapping all conditional expressions to binary encodings on the boolean dimension index sequence to generate a conditional vector set corresponding to the sensitive variable, and each conditional vector set is used as a path node; Generating a one-way edge connection between two nodes with any vector dimension value being 1 at the same time in the conditional vector set corresponding to the sensitive variable; Integrating the one-way edge connection relationships of all path nodes corresponding to the sensitive variables to construct a path judgment condition graph structure.

[0009] In a preferred embodiment, in S3, receiving a parameter set input by an external caller, and statistically determining the set of activation-sensitive variables corresponding to path nodes in the path determination condition graph structure of the current execution context specifically includes: Receiving a parameter set input by an external caller, and constructing a Boolean condition vector set of input parameters according to the Boolean dimension index sequence; Retrieving, in the path determination condition graph structure, a set of path nodes that exactly match the Boolean condition vector set of input parameters as the set of hit path nodes; Reading the sensitive variables bound to the hit path nodes, and aggregating them into the initial activation variable set of the current context; Based on the graph connectivity edges of the hit nodes, tracing and deriving the reachable node set, and expanding the initial activation variable set into a complete activation variable set.

[0010] In a preferred embodiment, in S4, for all sensitive variables not in the activation-sensitive variable set, marking their variable status as sandbox status, and setting a key blocking label to prohibit them from sending key request instructions to the trusted data space specifically includes: Extracting the full set of sensitive variables from the sensitive variable trigger path mapping table, excluding the variable items already existing in the activation-sensitive variable set, to obtain the non-activation-sensitive variable set of the current call context; Attaching a sandbox status identification field to each variable in the non-activation-sensitive variable set, and the sandbox status identification field uses the path node of the current call context as a bound parameter; Configuring a key request control bit on each non-activation-sensitive variable with an attached sandbox status identification field, and initializing the control bit to a blocking state; Constructing a call period isolation list, which consists of a set of binary tuples composed of each sandbox status variable and its bound path node.

[0011] In a preferred embodiment, in S5, for the sensitive variables in the activation-sensitive variable set, during the contract compilation stage, binding the lazy execution body to the corresponding call branch structure, and when the execution flow enters this call branch, triggering the data loading process of the corresponding sensitive variable specifically includes: Extracting the Boolean vector of the path node bound to each activation-sensitive variable as the lazy loading condition; During the contract compilation stage, encapsulating the data loading logic of each activation-sensitive variable into a lazy execution body, and the lazy execution body is a lazy execution code block constructed with a variable access function as the core; Attaching and binding the lazy execution body 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 activation-sensitive variable and meets the lazy loading condition, the bound deferred execution body is triggered to complete the data loading process for the corresponding activation-sensitive variable.

[0012] 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.

[0013] In a preferred embodiment, in S6, when the contract life cycle terminates, a destruction instruction is executed on the sensitive variables that have been recorded as in the sandbox state, and all caches during the branch call are erased, specifically including: After the function call stack corresponding to the call branch returns, mark the termination of the corresponding contract life cycle, scan the set of sandbox-sensitive variables and the variable caches during the current call, and extract the cache items in the cache that match the sandbox variable set; Record the cache item set of this clearing operation and the node numbers of the path judgment condition graph during the call period, generate a structural summary including the cache item set and the call period path node numbers, and construct a destruction information summary unit; Output the destruction information summary unit as the final write-out item before the termination of the contract life cycle to complete the exit processing of the sandbox-sensitive variables in the current round of execution.

[0014] The technical effects and advantages of a privacy data processing method based on a trusted data space according to the present invention: This solution realizes the structured control of the sensitive data access process in the smart contract by constructing a sensitive variable trigger path mapping table and introducing a path judgment condition graph structure. During the execution process, the external input parameters are converted into a Boolean vector and matched with the path graph nodes to determine which sensitive variables are activated in the current context. The unactivated sensitive variables are marked as in the sandbox state, and a key request blocking control bit is configured to prevent their access in case of path miss. For the activated variables, a lazy loading mechanism is adopted to delay the data request behavior to the actual execution path of the call branch, and the data loading operation is only executed when the control flow enters the branch and meets the trigger condition. After the call process ends, all cache contents generated by the sandbox variables during the execution are automatically erased to prevent the access traces of non-hit variables from remaining.

[0015] This mechanism effectively avoids the redundant exposure problem of the variable structure in the traditional contract being pre-loaded or parsed in the middle when the path is not triggered. Overall, a privacy variable access control chain based on path recognition is constructed, which has structural computability, predictable access behavior, and recyclable variable status, effectively improving the contract privacy isolation ability in the multi-source data processing scenario. Description of the Drawings

[0016] Figure 1Schematic diagram of a privacy data processing method based on a trusted data space according to the present invention. Detailed implementation manners

[0017] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to 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 of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0018] Embodiment 1 Figure 1 A privacy data processing method based on a trusted data space according to the present invention is provided, which includes the following steps: 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 the sensitive variables; S2: Based on the trigger path mapping table of the sensitive variables, convert the trigger conditions of all sensitive variables into boolean vectors to generate a path judgment condition graph structure; S3: Receive the parameter set input by the external caller, and count the set of activated sensitive variables corresponding to the path nodes in the path judgment condition graph structure hit by the current execution context; S4: For all sensitive variables not in the set of activated sensitive variables, mark their variable status as sandbox status, and set a key blocking label to prohibit them from sending key request instructions to the trusted data space; S5: For the sensitive variables in the set of activated sensitive variables, during the contract compilation stage, bind the delayed execution body to the corresponding call branch structure. When the execution flow enters this call branch, trigger the data loading process of the corresponding sensitive variables; S6: When the contract life cycle ends, execute a destruction instruction on the sensitive variables that have been recorded as sandbox status, and erase all caches during the branch call.

[0019] In 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 the sensitive variables.

[0020] Taking the financial smart contract code deployed on the multi-party privacy data sharing platform as the processing object. This contract contains multiple branch judgment logics controlled by input parameters, which are semantically used to dynamically load user portraits, credit data, or geographical risk parameters, etc. First, perform source code structure parsing on this contract, construct a code structure diagram based on the abstract syntax tree (AST), and perform node-level identification on the control structure units containing boolean expressions. Specifically, the identification of the structure units is based on the syntax type, and statement blocks with conditional judgment capabilities such as if, require, or switch-case are selected. Each structure unit corresponds to a directed control unit with an entry point (i.e., boolean expression) and an execution body (i.e., code block) in the abstract syntax tree. Based on the statement number, file location, and function scope, calibrate the execution entry of each structure unit, that is, the statement line where the boolean conditional expression of this control structure is located, as the path entry identifier of the structure unit. For example, the expression if(input.role == "admin"){...} is calibrated as control structure unit A, and its execution entry is at the line number corresponding to input.role == "admin". Through a complete structure scan, all control structure units and their bound entry condition expression sets are obtained, which serve as the basic entry set for subsequent static determination of variable access and triggering path mapping. This stage forms a data structure of a triple set, realizing the unified numbering and formatted extraction of the semantic entry of the control structure, and providing a structural anchor for subsequent variable determination and path binding operations.

[0021] After entering each identified control structure unit, perform line-by-line scanning at the statement level in its corresponding execution body, and parse the variable call operations involved in each statement. This process uses the static semantic parsing method, manages the variable names, data sources, and function call structures that appear in the current code block based on the symbol table, and calibrates each potential variable access path. Variable call forms include direct field access, function return value assignment, and off-chain interface call. Variables that directly or indirectly represent contract states or external data references are included in the call variable set. Construct the call variable set of this structure within each control structure unit, and its members are composed of variable items that are potentially executable under the current structure path. For example, for structure A, its code block contains statements such as decrypt(token_identity) and oracle.getScore(user_id). The variables token_identity and score are identified as data entities that may be accessed under the current structure path, and both are calibrated as statically accessible variables of structure A. After this step, all control structure units have bound variable access sets, which serve as the pre-data structure for path and variable access relationship binding.

[0022] After obtaining all structural units and their calling variable sets, enter the trusted attribute identification phase. The goal of this phase is to filter out all variable items accessed through off-chain data sources (such as Oracle, external interfaces, key decryption services), and label them as "trusted space association attributes". During the execution process, for each variable item in the calling variable set, trace its source statement. If the variable item is returned by an external interface function, calculated by a decryption operation, or obtained through a trusted data channel, then label this variable as a sensitive variable. Taking actual code as an example, if the variable score is sourced from oracle.getScore(user_id), then it is determined that score is a variable calculated in the off-chain trusted space; if the variable token_identity is sourced from decrypt(encrypted_token), then it is also regarded as a sensitive decryption variable; while on-chain fields such as amount or timestamp are not labeled as sensitive. Using the calling context tracing combined with the data source determination method, extract the variable items belonging to the trusted data space from the variable sets under all structural paths, and record them as a set of key-value pairs. This step differentiates between ordinary contract state variables and sensitive data items that require controlled access, and completes the data source determination and trusted identity binding for sensitive attributes, providing a data filtering basis for the construction process of the path mapping structure.

[0023] After completing the identification of sensitive variables, bind each sensitive variable to the execution entry of the control structure unit where it appears and the conditional expression of this entry into a unified structure, and write it into the sensitive variable trigger path mapping table. The mapping table is organized in the structure of a ternary vector, and each record item represents the semantic relationship of a certain sensitive variable being triggered by a certain path condition in the contract logic. Taking the variable token_identity as an example, if it appears within the control structure A, and the entry condition of A is input.role == "admin", then generate the triple: {token_identity, input.role == "admin", A}. Process all structural units in sequence, bind each sensitive variable to its logical trigger condition and control structure, and construct a complete path mapping structure. Finally, 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, with the characteristics of clear structure, unique determination conditions, and reversible variable positioning. It is the semantic basis for the refined variable access control and sandbox mechanism scheduling of this solution.

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

[0025] Traverse the trigger path mapping table of sensitive variables, parse the conditional expressions in each record item, and extract the smallest semantic unit that constitutes the conditional judgment, that is, the logical judgment factor. The judgment factor is defined as the atomic conditional item that cannot be further divided in Boolean logic, usually manifested as a comparison expression between an input parameter and a specific value, such as an equality judgment, a numerical range judgment, or an enumeration match. Adopt a conditional item extraction algorithm based on the syntax tree to parse the composite expression into a Boolean tree structure, and gradually sink to extract the judgment statements at the smallest leaf node level. For example, the expression role == "admin" && city == "Beijing" will be split into two judgment factors role == "admin" and city == "Beijing". For conditional items with similar expression structures but repeated semantics in different paths, establish a ternary semantic hash index through the combination of field names, operators, and target values, and perform deduplication and merging processing on all conditional items to generate a set of logical judgment factors. The merged set is unique in structure and there is no redundant judgment dimension, ensuring the consistency and calculability of the subsequent vector coding structure. This set will be used as the basic input for Boolean dimension construction to uniformly abstract the access control paths of sensitive variables at the structural dimension level.

[0026] After completing the extraction and merging of logical judgment factors, number each item in this set. The numbering rule adopts a global fixed order to ensure the consistency of Boolean coding dimensions. The specific method is to sort each judgment conditional item in the judgment factor set according to a preset order rule (such as lexicographical order, field priority, field type order), and assign a unique number in sequence, thereby establishing a judgment factor numbering table, with the structural form {F1: conditional item a, F2: conditional item b, F3: conditional item c,...}. Among them, the numbers F1, F2, F3... are the dimension indexes of the subsequent Boolean vector structure. After the numbering process, the set of judgment factors is structured into an ordered sequence of Boolean dimension indexes. This sequence does not depend on the content of sensitive variables, but completely comes from the logical judgment items involved in the path structure, ensuring the repeatability and neutrality of the Boolean conversion of the input parameter set. The trigger paths of all subsequent variables will be expressed and mapped in this Boolean dimension index space, and the numbering table will also be used as the basic index mapper for the Boolean encoder and the path node builder, remaining unchanged throughout the life cycle. The construction of the Boolean dimension index sequence lays the fundamental structural framework for the logical coding of path nodes, the judgment of path matching, and the logical consistency of structural connection edges.

[0027] After obtaining the Boolean dimension index sequence, the Boolean encoding process for each conditional expression in the sensitive variable trigger path begins. Each trigger conditional expression has been disassembled into several decision factors, and these decision factors have been registered with index numbers in the dimension sequence. A Boolean vector of the same length as the Boolean dimension index sequence is constructed for each expression and initialized to all zeros; subsequently, according to the decision factor terms included in the current expression, the corresponding dimension positions are assigned a value of 1, and the remaining unappeared terms remain 0. The Boolean vector thus obtained represents the logical projection of the path activation condition of the sensitive variable in the unified Boolean space. Each Boolean vector is defined as a path node and is attached with its associated sensitive variable identifier to achieve the structural mapping from path logic to variables. During the entire variable set encoding process, only modeling at the path level is performed, without introducing the specific data values of variables, nor involving value space encoding, and only Boolean abstraction is carried out from the structural logic. This approach ensures the direct matchability of the subsequent input parameter Boolean vectors and establishes a unified encoding basis for the logical association analysis between path nodes. The Boolean vectors of all variables are output as a set of sensitive variable condition vectors, and each vector item in this set is bound to a sensitive variable, providing a structural unit for subsequent path graph construction and variable activation judgment.

[0028] Perform a structural-level graph modeling operation on the generated set of sensitive variable condition vectors. Its goal is to construct the connection edge relationship between path graph nodes through the "intersection coincidence" of conditional logic. During the operation, all vectors in the conditional vector set are compared pairwise. For each pair of path node vectors Q and P, check whether there is a case where the Boolean values of each dimension are both 1. That is, if there exists any dimension F_i such that Q_i = 1 and P_i = 1, then it is considered that there is a logical intersection between path Q and path P in this conditional dimension; establish a one-way edge from Q to P for Q and P, indicating that Q can be logically extended to P, or there is partial reachability between the two in terms of variable trigger logic. The establishment of this one-way edge not only records the conditional commonality but also reflects the structural similarity of the trigger paths between variables, providing a topological structure for path graph analysis and boundary propagation judgment. Generate a structural identifier for each connection edge, recording its connection node numbers and the trigger intersection dimension, to form a complete set of logical connection structures. After this step, the logical commonality connection relationships between all nodes in the path graph are structurally represented, providing a graph basis for the analysis of the connectivity of the entire graph, the activation expansion of variable groups, and the judgment of conditional redundancy.

[0029] After constructing all the logical connection edges between nodes, the set of sensitive variable condition vectors is regarded as the node set of the path graph, and the set of logical common connection edges is used as the directed edge set to construct the path judgment condition graph structure as a whole. This graph structure is a directed graph G(V, E), where V is all path nodes, that is, the Boolean vector expressions of all sensitive variables, and E is the unidirectional edges with conditional intersections between all nodes. Each node structure in the graph contains a variable identifier, an activation condition Boolean vector, a bound trigger condition expression, and a control structure identifier to which it belongs, and has the ability of full structure mapping. Each edge in the graph represents the logical reachability between variables and provides a structural basis for links such as input condition fuzzification, variable activation expansion, and lazy loading scheduling.

[0030] In S3, receive the parameter set input by the external caller, and count the set of activated sensitive variables corresponding to the path nodes in the path judgment condition graph structure hit by the current execution context.

[0031] Receive a set of structured parameter sets passed by the external caller to the smart contract as the input of the current execution context. For example, in the scenario of federated authentication, the input parameter set may contain fields such as role, city, amount, user_status, etc. After receiving this input parameter set, call the Boolean vector builder module to perform vectorized mapping processing on the input parameters according to the predefined Boolean dimension index sequence. The Boolean dimension index sequence is the encoding result of the foregoing set of condition determination factors, with a fixed dimension order and clear field determination rules. For example, F1 represents role == "admin", F2 represents amount > 10000, F3 represents city == "Shanghai", etc. For the current input parameters, check in turn whether the determination factors corresponding to each dimension are established: if established, assign 1 to this dimension, otherwise assign 0, so as to form a Boolean condition vector. For example, if the current input is role = "admin" and amount = 8000, but city = "Beijing", then its corresponding Boolean vector is [1, 0, 0]. To adapt to the multi-path scenario, when the input parameters contain multiple field combinations that may hit paths at the same time, multiple vector items can be constructed to form a set of Boolean condition vectors of 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 input parameters to the contract execution path structure.

[0032] After the input Boolean vector construction is completed, the path node matching process is entered. In this process, the pre-constructed path judgment condition graph structure is loaded. Each node of this graph structure represents the Boolean vector expression of a sensitive variable triggering path and contains the corresponding bound variable information. 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 exactly the same as the input vector in all dimensions, it is considered that the path node is hit by the current execution context. The matching method uses the bitwise comparison method of Boolean values and combines the vector index optimization structure for batch queries to ensure that the matching efficiency is maintained even when the scale of path nodes is large. During the matching process, nodes with some dimensions being unknown or not affecting the current trigger condition are ignored, focusing on the path where the complete hit condition is met. Under a set of input conditions, multiple path nodes may be hit. At this time, a set of hit nodes is constructed, and this set contains the node numbers in all structures where the trigger condition is exactly the same as the current input.

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

[0034] After the construction of the initial activation variable set is completed, further analyze the connectivity relationship of the hit nodes in the path judgment graph structure to discover other variable nodes that share commonalities or path compatibility in the logical condition dimension. In the path judgment graph structure construction stage, the unidirectional edge between each pair of path nodes represents a logical judgment factor where the values of the two paths are consistent in a certain Boolean dimension, that is, the two variable paths may partially overlap under the input conditions. Use the set of hit nodes as the starting point for graph traversal and perform reachability tracing operations on the graph structure. Specifically, for each hit node, perform unidirectional edge tracking and collect the node numbers that can be directly or indirectly reached. Although the current input does not fully hit these nodes, they have a logical intersection with the hit path. Within the scope permitted by the business strategy, the sensitive variables bound to these paths can be considered structurally reachable and thus meet the pre-activation conditions. Merge the variable sets corresponding to all reachable path nodes into the initial activation variable set to form a complete activation variable set, which is the complete set of sensitive variables considered to have the possibility of being loaded in the current execution context. This set is used to construct the lazy loading structure and the sandbox state variable judgment boundary in the subsequent steps. By introducing a graph reachability extension mechanism, while maintaining a strict path judgment, the expression ability for path overlap and logical compatibility is increased, avoiding the problem of variable access islands caused by the splitting of conditional expressions and enhancing the judgment flexibility of the structure model under complex input conditions.

[0035] In S4, for all sensitive variables not in the activated sensitive variable set, mark their variable status as sandbox state and set a key blocking label to prohibit them from sending key request instructions to the trusted data space.

[0036] Extract all registered sensitive variable identifiers from the pre-stored "sensitive variable trigger path mapping table". This mapping table records all controlled variable items involved in the logical structure of the smart contract and is the complete set of variables that can be called by the path control logic during the contract operation. To avoid repeated processing of variables that have already been allowed access, perform a universal set difference operation, that is, compare the variable items in the universal set of variables with the set of variables that have been activated in the current context, and remove the variable items that are already included to obtain the set of remaining unactivated variables. This set is the sensitive variables involved in the paths not triggered by the current input parameters but not yet granted access permissions.

[0037] For each variable instance in the set of unactivated variables, perform the sandbox status identification field attachment operation. The sandbox status identification field takes the set of hit path nodes in the current execution context as a parameter and generates a unique structure identifier through hash encoding, which is used to express that the variable is in a passive shielding state because the triggering condition is not met in the current call path. This field is a status bit block attached to the variable metadata structure, which does not change the basic structure of the variable in the logical model and only serves as an isolation behavior identifier during runtime. In the scenario of multi-variable shared path triggering logic, different variables may share the same sandbox identifier parameter structure, but the fields still need to be attached separately to ensure the independence of variable-level access control. Reserve an independent namespace for the sandbox status field in the variable structure to avoid confusion with other permission control bits. The field value includes the call path boolean vector summary, the set of path node numbers, and the current round call number, etc., which are traceable, auditable, and non-forgeable. This field is only generated in specific isolation trigger scenarios during the variable lifecycle, and does not incur storage overhead in other stages. Through the construction of the sandbox status identifier, a structural shielding mechanism is established for sensitive variables, making the access permissions of variables explicitly judgmentable and the isolation status traceable, fundamentally preventing the privacy exposure risks of variables in untriggered paths from being pre-loaded or implicitly resolved in advance.

[0038] After completing the attachment of the sandbox status identification field, continue to configure the key request control logic for each sandbox variable. Prevent variables from indirectly triggering data loading behaviors through decryption interfaces, external trusted data sources, or off-chain call channels in the sandbox state. Inject a "key request control bit" field into the variable control structure. This field is of boolean type and serves as an execution switch for whether to allow a key request to be initiated during the variable call process. For all variables that are already in the sandbox state, their control bits are initialized to the "blocking state", that is, the variable is not allowed to initiate a key request process in any way in the current execution context. The configuration of the control bit adopts a delayed call structure hanging method bound to the variable access function to achieve the execution isolation of the control logic and the access path. During runtime, when the contract virtual machine attempts to execute variable access, it first determines whether the control bit is in the allowed state. If it is in the blocking state, the access instruction of the variable is directly interrupted and a rejection signal is returned. This mechanism not only blocks the active call path of the variable but also prevents the "access inheritance" problem caused by the variable being called by other variables in the multi-function path. The setting structure of the control bit supports multi-level nesting, which can distinguish contract paths, call functions, and context batches, supporting a finer access control granularity. This design provides a strong access boundary for sensitive variables, establishing a double protection between the structural layer and the execution layer, ensuring that sandboxed variables do not have any loading channels when the path is not hit, and further enhancing the execution guarantee ability of privacy isolation.

[0039] Construct an isolation control index structure for this round of call cycle, called the "call period isolation list". This list structure is used to track the logical relationship between each isolated variable and its corresponding trigger path during the call, to support subsequent auditing, call interruption determination, and lifecycle termination cleaning operations, and to index the path nodes or boolean vectors mapped by the trigger path conditions of the variable. The list is maintained as the isolation index table in the call context of this round, attached to the contract execution context environment, and an interface is provided for other modules to access the status of the table. The isolation list is dynamically maintained during the call. Once a variable unlocks its permission due to path changes or multiple execution processes, 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 decidable reference point for the path-level access isolation status of the smart contract during runtime, making the variable isolation status enumerable and structurally storable.

[0040] In S5, for the 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 this call branch, the data loading process of the corresponding sensitive variable is triggered.

[0041] Extract the boolean vector corresponding to the bound path nodes of each activated sensitive variable. This boolean vector has been clearly assigned during the path judgment graph construction phase and is the logical mapping of the variable's trigger condition in the boolean space. This boolean vector is used as the lazy loading condition for variable loading to determine when the variable is allowed to be loaded and accessed. When entering the compilation phase, scan the reference locations of all activated sensitive variables and encapsulate their access logic to construct the delayed execution body. The delayed execution body is constructed with the variable access function as the core. For example, if the variable binding operation is decrypt(score), then this function is embedded as the main call logic in the delayed execution body structure, and at the same time, the lazy loading judgment condition is injected as a precondition judgment statement. Each delayed execution body forms an independent code block, with bindability, schedulability, and path reference closed-loop property. The encapsulation format follows the pluggable logic structure recognizable in the contract language, such as function wrapper structure, code macro structure, or path trigger mapping table. During the encapsulation process, the variable context remains unchanged, and only the access path is structurally delayed rewritten to ensure that the original access logic is executed as it is when the path trigger condition is met. This stage does not trigger variable access, but only completes the preprocessing of the execution behavior and the preparation of the binding conditions. By constructing this structure, the code-level delay of variable access behavior is achieved, making the variable in an inaccessible state when the path condition is not met, effectively preventing the implicit execution risks of variable pre-decoding, memory mapping, or key request caused by pre-compilation optimization, early loading, or default structure binding.

[0042] After the contract is compiled, during the actual deployment and running phase, the variable access behavior will be controlled by a lazy execution mechanism. In each round of invocation, the construction of the input parameter vector and the matching of path nodes are first executed, and it is determined whether the current input meets the Boolean vector conditions of any path nodes bound to the active sensitive variables. When a node in the path determination graph structure hits the condition vector bound to an active variable and the execution flow enters the call branch structure it mounts, it is determined that the current meets the lazy loading condition of the variable. At this time, the lazy execution body bound to the variable is activated, and the variable access function encapsulated therein is executed, such as key request calls, off-chain data fetching, or status value reading. This loading behavior will trigger the return of the true value of the sensitive variable and give the variable the access status in the current call process. After the lazy execution body is executed, the loading status is recorded, and the variable is marked as "triggered state" to avoid repeated loading and support the result caching logic. In scenarios where the lazy loading condition is not met, the variable access structure will remain dereferenced, will not request any data, consume computing resources, or enter the audit path. This execution strategy ensures that the variable can only trigger the loading process under the dual conditions of "path determination hit + control structure entry", eliminating the possibility of sensitive variables being accessed in unauthorized paths from the dynamic control mechanism. At the same time, the trigger log of the lazy body is recorded for subsequent construction of the access trajectory closed-loop for sandbox variable difference set determination and life cycle termination cleanup operations.

[0043] In S6, when the contract life cycle terminates, a destruction instruction is executed on the sensitive variables that have been recorded as in the sandbox state, erasing all caches during the branch call.

[0044] Perform life cycle determination on the backtracking state of the call stack in the execution environment: When the execution flow has left all logical path control structures and there are no pending scheduling path nodes in the current execution context, it is confirmed that the current call process has ended naturally. Use the event of the function call stack being cleared as the "life cycle termination trigger condition" and mark this state as the termination identifier of the current contract context. Subsequently, enter the cache cleanup process. First, retrieve the "set of sensitive variables in the sandbox state" registered during the current execution cycle. This set comes from the variable structure identification process where the previous path was not hit. Synchronously retrieve all variable cache entries generated during this call process in the runtime buffer and construct a hash map structure for set comparison operations with 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 set of sandbox state variables, it is considered that this cache entry needs to be cleared. Such cache entries include the pre-decryption intermediate state that has not been triggered, the variable decoding preparation area, the off-chain call result pending binding items, etc.

[0045] After the cache item identification is completed, it enters the structural destruction summary construction stage. This stage aims to structurally record the sandbox variable cache clearing behavior to be executed, ensuring its auditable and verifiable historical traceability ability during the contract exit stage. First, record the identifier set of all variable cache items to be cleared, and combine and encode it with the set of path judgment condition graph node numbers hit during this round of calls. The set of path node numbers comes from the historical record module of variable activation and path structure hits, which is the determination expression of the control structure conditional logic during the contract operation. The variable cache item set and the path node set are combined into a binary structure summary, which is compressed using the structure hash method to form a structural summary carrier. Embed this summary carrier in a storage format called the "destruction information summary unit" in the form of a structural unit. The internal structure of this unit includes: a cleared variable index list, a bound path number index, a contract instance hash signature, a call round identifier, and timestamp information, etc., with structural uniqueness and execution verifiability. This summary unit does not save the actual values of variables or the intermediate execution states, but only saves the structural indexes to prevent information leakage.

[0046] In the final stage before the life cycle termination, persist the constructed destruction information summary unit as the final write-out item of the current contract execution context. This write-out operation is executed before the call stack is completely rolled back and the execution control right is recovered, ensuring that all variable behavior records are closed and archived at the structural level. The destruction information summary unit is output to the structural evidence storage area or the audit interface area bound to the contract, and can be written into the on-chain data area, the audit contract channel, or the external trusted log service according to the contract platform support situation. The write-out operation adopts a signature submission mechanism to ensure that the summary information is actively initiated by the current contract execution instance and is verifiable, preventing forgery or overwriting. After the write-out is completed, mark all cache structures related to sandbox variables in the current context as "terminated", execute the memory clearing instruction, and completely release all accessible states left by the variables in this round of call process. This process will not affect the ability of variables to be reactivated in subsequent calls, but will reset their access preparation status to ensure that subsequent activations must re-hit the path judgment conditions. After the write-out of this destruction summary unit is completed, write the life cycle termination state and the path determination state into the execution audit track together, forming a complete contract variable behavior closed-loop chain from "path determination → activate variables → sandbox variable isolation → cache generation → summary write-out". Through this mechanism, sensitive variables have a cleanable, provable, and traceable exit path in each round of execution process, greatly improving the security integrity and governance audit ability of the contract in the field of privacy data access control.

[0047] The above formulas are all dimensionless and take their numerical calculations. The formula is obtained by collecting a large amount of data for software simulation to get a formula closest to the actual situation. The preset parameters and threshold selection in the formula are set by those skilled in the art according to the actual situation.

[0048] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. 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 includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. 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 (such as infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that contains one or more collections of available media. The available media can be magnetic media (such as floppy disks, hard disks, magnetic tapes), optical media (such as DVDs), or semiconductor media. The semiconductor media can be a solid-state drive.

[0049] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of the examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or in a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of the present application.

[0050] Those skilled in the art can 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 foregoing method embodiments and will not be described herein again.

[0051] In the several embodiments provided in the present 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 illustrative. For example, the division of the modules is only a logical function division, and there can be other division methods in actual implementation. For example, 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 displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of the devices or modules can be in electrical, mechanical, or other forms.

[0052] The module described as a separation component may or may not be physically separated. The component shown as a module may or may not be a physical module, and it may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

[0054] If the above 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, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0055] As described above, this is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0056] Finally: The above is only the preferred embodiment of the present invention and is not used to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention shall be included in the protection scope 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 statement, and establish a trigger path mapping table of 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: receiving a parameter set input by an external caller, and counting the set of activated sensitive variables corresponding to the path nodes in the hit 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 states as sandbox states, 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 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; 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.

2. According to claim 1, a privacy data processing method based on a trusted data space is 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, and 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 variable entities accessible by the branch in a static state; Filter all variable items obtained through off-chain requests in the calling variable set, and mark the corresponding variable items as sensitive variables with attributes associated with the trusted space; Each sensitive variable and the corresponding control structure unit execution entry and conditional expression are integrated into a ternary vector relationship, and are uniformly stored in a sensitive variable trigger path mapping table.

3. According to claim 1, a privacy data processing method based on a trusted data space is characterized in that: 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: Extract all conditional items corresponding to the conditional expressions from the sensitive variable trigger path mapping table as logic decision factors, and return to a non-repeated set of logic decision factors; The logical decision factor set 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 one at the same time; Integrate the one-way edge connection relationships of all sensitive variables corresponding to the path nodes and construct the path judgment condition graph structure.

4. The method for processing private data based on a trusted data space according to claim 1, characterized in that: 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, specifically including: Receive a parameter set input by an external caller, and construct a 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.

5. 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 state 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.

6. 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 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, which specifically includes: Extract each path node Boolean vector of activation sensitive variable bindings as lazy loading conditions; During the contract compilation phase, the data loading logic of each activated sensitive variable is encapsulated as a delayed execution body, which is a delayed execution code block built around the variable access function. The delayed execution body is additionally bound to the call branch structure to which the Boolean vector of the corresponding path node belongs, so as to form a path trigger binding relationship; When the execution flow reaches the call branch corresponding to the activated sensitive variable and satisfies the lazy loading condition, the bound delayed execution body is triggered to complete the data loading process of the corresponding activated sensitive variable.

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

8. 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 for the sensitive variables that have been recorded as sandboxed, and all caches during the branch call are erased, including: When the function call stack corresponding to the call branch returns, the corresponding contract lifecycle is marked as terminated, the sandbox state sensitive variable set and the variable cache during the current call are scanned, and the cache items in the cache that match the sandbox variable set are extracted; Record the cache item set and the call period path judgment condition graph node number of this clearing operation, generate a structural summary containing the cache item set and the 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