A secure multi-party computation oriented SQL-like query processor

Abstract

The present disclosure provides a kind of SQL-like query processor for secure multi-party computing.The overall structure is: design SQL-like parser for receiving SQL-like statement, then through adapter, framework adaptation is converted into logical plan and input SQL optimizer, then the physical plan obtained is input task generator, the optimized physical plan is decomposed, they are converted into task sequence TaskDAG convenient for scheduler on chain distribution, and TaskDAG is input secure multi-party operator;The underlying implementation of the long chain is adapted to the blockchain application in privacy computing technology, a Task generator is independently developed, and the optimized execution plan is decomposed into TaskDAG suitable for blockchain environment scheduling and parallelism;At the same time, considering the communication and computing overhead between different nodes, to further improve the effect of execution efficiency and performance.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain, and more specifically, to a SQL-like query processor for secure multi-party computation. Background Technology

[0002] The research and application of blockchain technology have experienced explosive growth, and it is considered the fifth disruptive innovation in computing paradigms, following mainframes, personal computers, the internet, and mobile / social networks. Blockchain technology is the prototype of next-generation cloud computing and has the potential to completely reshape the way human society operates, just as the internet has, and to realize the transformation from the current information internet to the value internet.

[0003] Privacy computing refers to a technological system for realizing data value mining while providing privacy protection, rather than a single technology. In the early days, it was often defined as privacy-preserving computing or privacy-preserving technology. The term "privacy computing" was formally introduced in the 2016 publication "Research Scope and Development Trends of Privacy Computing," which defines privacy computing as: "Computational theories and methods for protecting privacy information throughout its entire lifecycle; a computable model and axiomatic system for privacy measurement, the cost of privacy leakage, and the complexity of privacy protection and privacy analysis when the ownership, management, and use rights of privacy information are separated."

[0004] For individual consumers, privacy-preserving computing applications help protect personal information security. This ensures consumers can enjoy the convenience and benefits of the digital economy while preventing the leakage of their personal information.

[0005] For businesses and organizations, privacy-preserving computation is a crucial pathway to fulfilling data protection obligations during data collaboration. On one hand, within enterprises, privacy-preserving computation effectively protects critical information and data collected, stored, and analyzed. On the other hand, it promotes cross-industry data collaboration. Because privacy-preserving computation enables data to be usable but not visible, it helps different enterprises and organizations across the industry chain to conduct joint analysis and create data-integrated applications.

[0006] For governments, privacy-preserving computation is a crucial support for maximizing the value of data and social welfare. Firstly, it can enhance data security and privacy protection during the process of opening up government data, particularly in areas such as collection, storage, and collaboration. Secondly, it can drive industrial upgrading through data-driven initiatives.

[0007] Firstly, from a blockchain perspective, blockchain itself has certain limitations. While data on the blockchain is publicly transparent, its compliance processing and privacy protection capabilities are insufficient. Secondly, the on-chain data processing capacity is inadequate, hindering further technological implementation and commercial expansion. Introducing privacy computing can ensure data privacy throughout its entire lifecycle, from generation, perception, publication, and dissemination to storage, processing, use, and destruction. Standardized data processing can also improve the efficiency of data processing and sharing, thereby enhancing the blockchain's data processing capabilities.

[0008] From the perspective of privacy-preserving computation, certain shortcomings also exist. The lack of secure verification in data sharing hinders the feasibility of the entire data circulation process. Furthermore, the lack of a data ownership confirmation mechanism restricts the applicability of data during circulation. By introducing blockchain, the entire data circulation process can be recorded, clarifying the responsibilities and rights of participants. Simultaneously, during data transmission, the data provider can be recorded, verifying the authenticity of the data provider and facilitating data ownership confirmation.

[0009] Blockchain and privacy computing technologies are complementary, and their integration is an inevitable trend. While blockchain plus privacy computing is not yet standard, many companies have already recognized this trend. In January 2020, WeBank released WeDPR, an efficient, readily available scenario-based privacy protection solution. WeDPR integrates blockchain and privacy computing technologies, enabling better privacy protection for sensitive data in real-world business scenarios on the blockchain. In May 2021, combining the advantages of blockchain and secure multi-party computation, WeBank launched WeDPR-PPC, a multi-party big data privacy computing platform. On October 22, 2021, at the Yunqi Conference, AntChain, a subsidiary of Ant Group, launched its new blockchain network platform, FAIR. Currently, the FAIR platform has begun to be implemented in government and large enterprises, and exploration in more fields such as finance is underway. QuChain Technology has partnered with branches of the People's Bank of China and banks, using blockchain + privacy computing technology to design a data reporting model. It has successfully implemented a financial industry data sharing platform in Nanchang, Jiangxi Province, and established a joint credit reporting platform for financing, solving the problem of data sharing among institutions.

[0010] Currently, Ant Group's FAIR framework best combines blockchain and privacy computing. It achieves a native integration of privacy computing and blockchain technology, and through continuous improvements, it has already achieved interoperability with open-source privacy computing frameworks such as Ephemeris and FATE, as well as privacy computing systems such as Morse. This means that users can independently call multiple privacy computing components, such as multi-party secure computation, federated learning, and trusted execution environments, on a single platform to meet the needs of multi-participant scenarios for data security, efficient collaborative computation, and data transfer.

[0011] The technology most similar to this invention is the SCQL Secure Collaborative Query Language within the Hidden Language Framework. It's a system that allows multiple untrusted parties to conduct joint data analysis without revealing their individual privacy data. Within the Hidden Language Framework, it belongs to the BI layer of the algorithm layer. The core implementation of SCQL includes SQL syntax parsing, CCL control management, graph optimization and splitting (which can be understood as SQL query optimization), and the implementation of underlying secure multi-party operators. Its architecture, as shown in the diagram, is generally divided into two parts. The upper-layer SCDB can be considered the SCQL database, responsible for translating queries into a cryptographic execution graph and sending it to the SCQL Engine deployed on the data participants for execution. The SCQL Engine is the execution engine of SCQL, which collaborates with the SCQL Engines of other participants to complete the execution of the cryptographic graph and reports the results back to the SCDB.

[0012] Specifically, external users can directly initiate a traditional SQL request. This request first passes through a parser, transforming it into an abstract syntax tree, and then through a planner, into a logical plan. The biggest challenge is transforming the logical plan into an execution graph. Here, the translator needs to select the optimal protocol under multiple constraints. This is a key to making SQL privacy-preserving computation, because the entire computation involves security constraints, requiring comprehensive consideration of data type, data source, and data state. Moreover, the data state will continuously migrate and change during the computation process.

[0013] In summary, the SCQL solution has made excellent attempts to address the technical challenges of correctness, timeliness, and security, and has achieved the following functionalities:

[0014] Easy to use and integrate: SCQL supports a SQL-like query language, making it simple to use and easy to learn. In addition, SCQL provides a user-friendly API interface for easy integration and encapsulation, and supports common data sources (currently MySQL, with future plans to support CSV, Postgres, Hive, and other data sources), enabling low-cost fulfillment of business needs for collaborative data analysis from multiple sources.

[0015] Fine-grained data authorization mechanism: SCQL innovatively proposes the CCL (Column Control List) mechanism, which allows data providers to authorize how their data is used, with control granularity down to the data table field (column);

[0016] Feature-rich and flexible for various scenarios: It supports most commonly used SQL syntax and functions, which can meet the needs of joint analysis in most scenarios;

[0017] To meet actual production performance requirements: Under the premise of protecting data privacy, multi-level optimizations were carried out with the optimization idea of ​​minimizing the amount of computation in the dense state.

[0018] In a blockchain and MPC environment, after optimizing the SQL to generate a physical plan, it cannot be directly handed over to a specific executor for execution like traditional SQL. In this environment, all execution needs to be handled by a scheduler, and each node on the chain is extremely sensitive to privacy information. Therefore, an additional task generator is needed to decompose the optimized physical plan and transform it into a task sequence (TaskDAG) that is easy for the scheduler to distribute on-chain. Since task scheduling and distribution are inseparable from the underlying design of the entire privacy computing framework, the parameter naming, input / output formats, etc., of each task need to be strictly aligned with upstream and downstream processes. Therefore, the SCQL framework cannot be directly ported to other privacy computing platforms (such as Chang'an Chain). Using the SCQL framework requires the use of related underlying supporting frameworks, which clearly does not meet our requirements.

[0019] Examining the overall architecture of the hidden language reveals that SCQL is located in the AI ​​& BI algorithm layer. At the same layer, other SQL-like statements such as Federated Learning (FL) and Trusted Execution Environment (TEE) can be found. This indicates that SCQL only adds support for traditional SQL statements, while additional components are needed for parsing and optimization of statements such as Federated Learning, which are more common in blockchain privacy computing platforms.

[0020] The rapid development of blockchain technology has attracted widespread attention in the market. my country's first independently controllable blockchain software and hardware technology system, "Chang'an Chain," was officially launched in Beijing.

[0021] To achieve the above goals, Chang'an Chain needs to provide connection and access adapters for block data, offering block data query services to securely and reliably access data scattered across various blocks. It also needs to provide user-friendly data query and analysis languages, interfaces, and parsing tools, ideally compatible with traditional SQL, a language familiar to most data analysts. This would allow analysts to easily query and analyze physically distributed block data on Chang'an Chain with minimal learning curve. It's important to note that this data query involves data interaction between multiple organizations or institutions, and with increasing international and domestic demands for user data privacy protection, this query operation must be computationally oriented towards secure multi-party computation. However, Chang'an Chain's current data query and analysis functions are relatively simple. Its query language is weak, lacking capabilities such as cross-row computation, and cannot express operations like counting or averaging within queries, failing to meet the needs of data analysis. Furthermore, it lacks query optimization, resulting in poor query performance and difficulty in responding to query results promptly. These shortcomings significantly limit its use by data analysts and constrain Chang'an Chain's data sharing and service capabilities.

[0022] To address the above issues, this invention will focus on the blockchain and MPC environment in which Chang'an Chain operates, analyze the impact of the new environment on SQL queries, and consider the requirements for task distribution and scheduling, privacy protection between nodes, and encrypted resource transmission. While meeting the platform users' requirements for ease of use, it maximizes the provision of complex data analysis and query functions supported by traditional SQL, and has good practical effectiveness. Summary of the Invention

[0023] The purpose of embodiments of this disclosure is to provide a SQL-like query processor for secure multi-party computation, aiming to evaluate and enhance the robustness of models by combining it with other basic adversarial example generation techniques. Traditional adversarial example generation techniques mainly focus on averaging the attack effects of multiple models, without fully considering the contribution of differences between models to the attack. Existing techniques cannot effectively adapt to the characteristics of different models, nor can they provide adversarial examples with strong adaptability and high generalization ability.

[0024] In general, a SQL-like query processor for secure multi-party computation is provided. The overall structure is as follows: a SQL-like parser is designed to receive SQL-like statements, which are then adapted into a logical plan by an adapter and input into a SQL-like optimizer. The resulting physical plan is then input into a task generator, which decomposes the optimized physical plan and transforms it into a task sequence TaskDAG that is easy for the scheduler to distribute on the chain. The TaskDAG is then input into a secure multi-party operator.

[0025] The SQL-like parser is implemented using Antlr4. The Abstract Syntax Tree (AST) generated by Antlr4 will then be converted into a logical plan in Calcite via an adapter. The SQL-like optimizer uses the Apache Calcite framework, and includes the design of data table statistics, optimization rules, modified cardinality estimation methods, and cost models to obtain the physical plan. The task generator is designed in conjunction with the underlying task scheduling and distribution of the Chang'an Chain, ensuring strict alignment of parameter naming, input / output formats, etc., with upstream and downstream processes. Finally, the secure multi-party operator participating in the underlying task scheduling provides the operational flow for secure intersection in an MPC environment.

[0026] The cost model analyzes the Join operator. First, for the case where both parties in the Join operation reside in the same data source, the CPU and memory costs are: C Cpu =Row Build *C Build +

[0027] Row Probe *C Probe

[0028] C Memory =Row Build *Size Build +Cardinality Join *(Size Build

[0029] +Size probe )

[0030] CPU consumption is divided into two parts: the construction phase and the probing phase. Memory consumption is divided into the HashMap built from the small table and the result set generated after a successful match. For IO consumption, if the results of the previous operators are all in memory, then it is 0. Net consumption is also considered to be 0.

[0031] If the two parties in a join are located in different data sources, and the PSI operator is used to find the intersection, the CPU consumption mainly comes from the encryption and decryption operations before and after data transmission, as well as the matching operation of the intersection columns of the two parties.

[0032] The secure multi-party operator employs a two-table one-to-one PSI method, a two-table many-to-many PSI method, a many-table one-to-one PSI method, or a many-table many-to-many PSI method to find the unique intersection column.

[0033] The specific implementation of the two-table one-to-one PSI method is as follows: For two data sources org1 and org2, org1 has a data table TA, and org2 has a data table TB. The values ​​of aid on org1 and bid on org2 are unique, while the values ​​of ta on org1 and tb on org2 are not unique. For a SQL statement with two tables, since aid and bid are unique values, a one-to-one PSI operation is performed. First, data is read according to the inputData information in the Task. Then, the intersection columns are sent to the other party using a specific privacy encryption algorithm. After that, both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched. Finally, data that meets the conditions is filtered out from the local table based on this set.

[0034] The specific implementation of the two-table many-to-many PSI method is as follows: There are two tables, TA and TB, located in data sources org1 and org2 respectively. The SQL statement is SELECT TA.aid FROM TA JOIN TB ON TA.ta = TB.tb, where ta and tb are both non-unique columns, meaning duplicate values ​​are allowed. The main process for PSI between the two tables is as follows:

[0035] Step 1: Obtain the output of the previous task as input based on the inputData information;

[0036] Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm;

[0037] Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally;

[0038] Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence;

[0039] Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information to uniquely identify the requested row.

[0040] The specific implementation of the multi-table one-to-one PSI method is as follows: There are three tables TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is SELECT TA.aid FROM TA JOIN TB ON TA.aid=TB.bid JOINTC ON TA.aid=TC.cid, where aid, bid, and cid are all unique columns.

[0041] Step 1: Obtain the output of the previous task as input based on the inputData information;

[0042] Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm;

[0043] Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally;

[0044] Step 4: Use the data filtered in the previous step to continue the two-table PSI process. The process is exactly the same as the first time. Continue to filter out the data that meets the conditions.

[0045] Step 5: After completing the last two-table PSI, the two tables (both sides) that were intersected in this step will have a complete result set;

[0046] Step 6: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set.

[0047] The specific implementation of the multi-table many-to-many PSI method is as follows: There are three tables TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is SELECT TA.aid FROM TA JOIN TB ON TA.ta=TB.tb JOIN TCON TA.ta=TC.tc, where ta, tb, and tc are all non-unique columns.

[0048] Step 1: Obtain the output of the previous task as input based on the inputData information;

[0049] Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm;

[0050] Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally;

[0051] Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence. If a UID has already been generated, a list of UIDs needs to be attached.

[0052] Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information and uid list (update if uid already exists);

[0053] Step Six: Use the data filtered in the previous step to continue the two-table PSI process. The process is exactly the same as the first time. Continue to filter out the data that meets the conditions.

[0054] Step 7: After completing the last two-table PSI, the two tables (both sides) from this intersection will have a complete result set;

[0055] Step 8: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set.

[0056] The innovation of this invention lies in:

[0057] The application of blockchain in privacy computing technology leads to strong upstream and downstream dependencies in the entire process of SQL parsing optimization, task sequence generation, and finally task distribution and scheduling. This invention implements a blockchain application for privacy computing technology adapted to the underlying implementation of the Chang'an Chain. It independently develops a Task generator that decomposes the optimized execution plan into a TaskDAG adapted to blockchain environment scheduling and parallelism; simultaneously considering the communication and computational overhead between different nodes to further improve execution efficiency and performance. Attached Figure Description

[0058] The above and other objects and features of this disclosure will become clearer from the following description taken in conjunction with the accompanying drawings.

[0059] Figure 1 This is a schematic diagram illustrating the technical location of a SQL-like query processor for secure multi-party computation according to an embodiment of the present disclosure;

[0060] Figure 2 This is a schematic diagram illustrating the structure of a SQL-like query processor for secure multi-party computation according to an embodiment of the present disclosure;

[0061] Figure 3 This is a schematic diagram illustrating the table structure and specific data storage of the two tables according to an embodiment of the present disclosure;

[0062] Figure 4 This is a schematic diagram illustrating the implementation process of a two-table one-to-one PSI according to an embodiment of the present disclosure;

[0063] Figure 5 This is a schematic diagram illustrating the implementation process of a two-table many-to-many PSI according to an embodiment of the present disclosure;

[0064] Figure 6 This is a schematic diagram of the table structure and data of a TC according to an embodiment of the present disclosure;

[0065] Figure 7 This is a schematic diagram illustrating the implementation process of a multi-table one-to-one PSI according to an embodiment of the present disclosure;

[0066] Figure 8This is a schematic diagram of a binary tree structure after multi-table PSI conversion according to an embodiment of the present disclosure;

[0067] Figure 9 This is a schematic diagram illustrating the implementation process of a many-to-many PSI based on an embodiment of the present disclosure;

[0068] Figure 10 This is a schematic diagram illustrating the intersection result without sending a list of uids according to an embodiment of the present disclosure;

[0069] Figure 11 This is a schematic diagram illustrating the test results of verb pushdown in localjoin according to an embodiment of the present disclosure;

[0070] Figure 12 This is a schematic diagram illustrating the test results of verb pushdown in PSI according to an embodiment of the present disclosure. Detailed Implementation

[0071] The following detailed embodiments are provided to aid the reader in gaining a comprehensive understanding of the methods, apparatus, and / or systems described herein. However, various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but may be changed as will become clear upon understanding this disclosure, except for operations that must occur in a specific order. Furthermore, for clarity and conciseness, descriptions of features known in the art may be omitted.

[0072] The features described herein may be implemented in different forms and should not be construed as limited to the examples described herein. Rather, the examples described herein are provided only to illustrate some of the many feasible ways of implementing the methods, apparatus, and / or systems described herein, which will become clear upon understanding the disclosure of this application.

[0073] As used herein, the term “and / or” includes any one of the associated listed items and any combination of any two or more.

[0074] Although terms such as “first,” “second,” and “third” may be used herein to describe various components, assemblies, regions, layers, or parts, these components, assemblies, regions, layers, or parts should not be limited by these terms. Rather, these terms are used only to distinguish one component, assembly, region, layer, or part from another. Thus, without departing from the teaching of the examples described herein, the first component, first assembly, first region, first layer, or first part referred to as the first component, first assembly, first region, first layer, or first part may also be referred to as the second component, second assembly, second region, second layer, or second part.

[0075] In the specification, when an element (such as a layer, region, or substrate) is described as being "on" another element, "connected to," or "bonded to" another element, the element may be directly "on" another element, directly "connected to," or "bonded to" the other element, or one or more other elements may be present in between. Conversely, when an element is described as being "directly on" another element, "directly connected to," or "directly bonded to" another element, no other elements may be present in between.

[0076] The terminology used herein is for the purpose of describing various examples only and is not intended to limit disclosure. Unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. The terms “comprising,” “including,” and “having” indicate the presence of the described features, quantities, operations, components, elements, and / or combinations thereof, but do not preclude the presence or addition of one or more other features, quantities, operations, components, elements, and / or combinations thereof.

[0077] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains upon understanding this disclosure. Unless expressly defined herein, terms (such as those defined in a general dictionary) shall be interpreted as having a meaning consistent with their meaning in the context of the relevant field and in this disclosure, and shall not be interpreted in an idealized or overly formalistic manner.

[0078] Furthermore, in the description of the examples, detailed descriptions of well-known related structures or functions will be omitted when it is believed that such detailed descriptions would lead to a vague interpretation of this disclosure.

[0079] Figure 1 This is a schematic diagram illustrating the location of a SQL-like query processor for secure multi-party computation according to an embodiment of the present disclosure within the overall Chang'an Chain architecture.

[0080] This invention serves as a SQL-like query processor for the Chang'an Chain privacy computing platform, such as... Figure 1 As shown.

[0081] Due to the specific requirements of blockchain and MPC environments, the parser and optimizer introduce various special conditions and rules.

[0082] For example, during the parsing phase, the parser needs to be able to correctly identify and parse statements related to blockchain and MPC, including parameter sharing in federated learning models and calls to trusted execution environments. This may involve specific syntax rules and semantic parsing.

[0083] During the optimization phase, the optimizer needs to consider the unique characteristics of blockchain and MPC environments, such as data privacy and security requirements. The optimizer may need to introduce new optimization rules and strategies to ensure that query performance and efficiency are improved as much as possible while protecting data privacy and ensuring security.

[0084] In addition, to ensure seamless integration with the Chang'an Chain underlying layer, a separate Task generator needs to be developed. Its primary function is to decompose the optimized execution plan into a TaskDAG that adapts to the blockchain environment for scheduling and parallelism. Furthermore, considering the communication and computational overhead between different nodes to further improve execution efficiency and performance, it also needs to support various tuning strategies. For example, it can intelligently decide whether to merge multiple tasks from the same source into a single traditional SQL statement that can run locally, based on the task's characteristics and data distribution, thereby reducing the time wasted on task distribution and scheduling. Similar tuning strategies can improve overall execution efficiency and reduce task execution latency.

[0085] Based on the above considerations, the overall design of this type of SQL query processor is as follows: The SQL parser part is implemented using Antlr4. Due to its relatively new framework and broad language parsing coverage, coupled with convenient visualization plugins, it can easily add support for various SQL-like statements, such as federated learning, confidential computing, and trusted execution environments. In order to optimize using the Calcite framework, the Abstract Syntax Tree (AST) generated by Antlr4 needs to be transformed into a logical plan in Calcite through an adapter. The optimizer part adopts the Apache Calcite framework due to its high flexibility and scalability requirements, and it has successful precedents of being modified from Flink and Hive, so there are precedents to follow. At the same time, the statistical information of the data tables, the optimization rules adopted, the modified cardinality estimation method, and the cost model will all contribute to SQL optimization. The task generator is inseparable from the task scheduling and distribution design of the underlying Chang'an Chain. The parameter naming, input and output formats of each task need to be strictly aligned with the upstream and downstream, so it must be developed from scratch according to the requirements. Finally, the secure multi-party operator participating in the underlying task scheduling can provide the operation process for secure intersection in the MPC environment. The position of each part in the overall query processing and the relationships between them are as follows: Figure 1 As shown.

[0086] The research on optimization rules and cost models in the optimizer section is also an important part of this invention. First, let's consider the expressions involved in the physical plan. If these expressions are very lengthy and complex, and not in their simplest form, then clearly simplifying them will bring certain advantages. This optimization approach is independent of the database system's environment (single-machine, distributed, or blockchain); on the contrary, the more complex the database environment, the better the optimization effect will be. For example, in a standalone environment, an unsimplified expression only requires a few more calculations each time it is accessed (most often when reading a single line). Since SQL statements themselves are relatively fast, this extra time may not have a significant impact. However, in a distributed environment, expression simplification not only speeds up the execution of the expression but may also reduce the amount of data transmission and computational load between nodes, potentially having a more favorable impact on the overall system performance. In blockchain and MPC environments, this positive impact is amplified again. Firstly, due to privacy protection, expression simplification can greatly reduce the various encryption and decryption operations required for each transmission. Secondly, if the lack of expression simplification causes a task that could be solved by one task to be broken down into multiple tasks, the time cost of distributing, scheduling, and running these redundant tasks is very high.

[0087] Therefore, constant folding and expression simplification are the two most readily conceived and effective optimization rules. Constant folding refers to calculating query statements containing constant expressions as their final constant results during query optimization. This optimization rule analyzes the query during the compilation or optimization phase and replaces statically computable constant expressions with their calculated results. For example, for the expression 2+3, constant folding will directly calculate it as 5. Expression simplification refers to simplifying complex expressions in the query to reduce computational complexity and improve execution efficiency. This optimization rule performs algebraic and logical simplification operations on the expressions in the query, such as merging identical terms, removing redundant operations, and simplifying logical operations. Both optimization rules aim to optimize query expressions, reduce the overhead of repetitive calculations and unnecessary operations and calculation steps, thereby reducing the complexity of expressions and improving query execution efficiency.

[0088] The next optimization rule to focus on is predicate pushdown, a very common optimization rule in database query optimization. It pushes predicate conditions to the data source for filtering as early as possible during query execution, thereby reducing data transmission and computation, and improving query performance. In traditional SQL optimization, predicate pushdown has many complex use cases, such as pushdown in various Join operations (Inner Join, Left Join, Right Join, Full Join), pushdown of aggregate functions, pushdown of OrderBy Limit, and even special applications in column-oriented storage formats (Apache Parquet). However, in blockchain and MPC environments, we don't need to discuss such complex scenarios; we can first consider the most basic pushdown of the Filter node before the Join operation. Assume the system currently receives the following ordinary federated query SQL statement.

[0089] In addition, there is another rule that can have a significant impact on query efficiency in the new environment: join reorder. Join reorder is a key technique in database query optimization. It improves query performance by minimizing the overall cost of the query by determining the order in which tables are joined.

[0090] When executing queries involving multiple tables, the database system needs to determine the order in which these tables are joined. The join order determines the order in which join operations are performed, thus affecting query execution efficiency. An incorrect join order can lead to a large number of intermediate results and additional computational overhead, reducing query performance. The goal of join order optimization is to find an optimal join order that minimizes the overall cost of the query.

[0091] In order to find the optimal join order, in addition to the join transposition rules, the optimizer often uses table statistics (such as the number of rows, cardinality, index information, etc.) to estimate the cost of join operations. Accurate statistics can help the optimizer evaluate the effect of different join orders and select the best order. The whole process usually uses techniques such as dynamic programming or heuristic algorithms to search for the best join order. These algorithms consider the cost of different join orders and try to find the join order with the minimum cost.

[0092] Cardinality estimation and cost models are mentioned here, and are also part of this invention. In blockchain and MPC environments, in addition to traditional statistics and corresponding metadata, another parameter is particularly important: the data source to which each data table belongs. In this special environment, data tables are distributed across different nodes of the blockchain; different data sources mean they reside on different nodes within the blockchain network.

[0093] Since the data tables are distributed across different nodes, performing operations such as intersection requires transferring data from one node to another, which obviously incurs additional data transfer overhead. Furthermore, factors such as network communication and transmission latency must also be considered. Secondly, in blockchain and MPC environments, data privacy is paramount. No party wants to disclose their private information to the other for collaborative operations like intersection. Therefore, for privacy protection, operations between different data sources must employ relatively complex encryption and decryption algorithms, which inevitably increase computational overhead and time costs. Therefore,

[0094] When optimizing queries, the cardinality of operators and the evaluation of cost models need to take these factors into account, and traditional cost calculation methods also need to be modified accordingly. Below are some common operator cardinality estimates.

[0095]

[0096]

[0097] We perform cardinality estimation on operators primarily to serve the subsequent cost calculation. The cost calculation of operators depends on the amount of data (number of rows) input to the operator for estimation. The estimation of the number of rows is mainly accomplished through cardinality estimation and statistical information. Therefore, these two values ​​are of great significance for the subsequent evaluation of the execution cost of operators.

[0098] The cost model is used to estimate the cost of the physical execution plan. Each operator is generally described by cost elements (CPU, Memory, IO, Net, etc.), and the specific calculation method is shown in formula (2.1). Among them, CPU represents the CPU consumption, that is, the computational complexity of the operator; Memory represents the memory usage, which mainly depends on the number of rows and the data length; IO represents the cost of reading data from the disk; Net is used to represent the network cost incurred when the operator is executed (the number of interactions with other data sources and the data transfer between them); and w1-w4 are weight vectors used to evaluate the importance of each cost in the calculation of the total cost.

[0099] TotalCost=(C Cpu CMemory C IO C Net )·(w1,w2,w3,w4) (2.1)

[0101] Taking the Join operator as an example, we first consider the case where both join operations reside in the same data source. In this case, the CPU and memory costs are shown in formulas (2.2) and (2.3). The CPU consumption is divided into two parts: the construction phase and the probing phase. The cost of each phase is the number of rows involved in that phase multiplied by the fixed cost of operating on each row. Build C Build Row Probe C probe These represent the number of rows used to build the HashMap, the cost per row during construction, the number of rows used for probing, and the cost per probing attempt, respectively. Memory consumption is divided into the HashMap built from the smaller table and the result set generated after a successful match. Size Build Cardinality Join Size Probe These represent the size of each row when constructing the HashMap, the cardinality estimate of the Join result, and the size of each row used for probing, respectively. For I / O consumption, it is 0 if the results of previous operators are all in memory, and Net consumption can obviously also be considered 0.

[0102] C Cpu =Row Build *C Build +Row Probe *C Probe (2.2)

[0104] C Memory =Row Build *Size Build +Cardinality Join *(Size Build +

[0105] Size probe (2.3)

[0106] If the two parties in a Join operation reside in different data sources, the PSI operator will be used for intersection due to the influence of the blockchain and MPC environment. Its CPU consumption primarily shifts to encryption / decryption operations before and after data transmission, as well as matching operations on the intersection columns. Memory consumption becomes minimal because the two tables don't actually perform a Join operation; therefore, the memory consumption of each data source is at most the memory required to read the current table plus the received intersection column data from the other party. I / O consumption is no longer zero, as it can operate continuously in memory. In a blockchain environment, each step of task execution involves input and output, so I / O consumption is at least the output of the previous step plus the output of the current step. Network (Net) consumption initially accounts for a significant portion. Remote communication between different nodes on the chain, no matter how fast the network speed, cannot compare to local I / O. The data transmission volume here is the number of table rows multiplied by the size of the intersection columns. Furthermore, all aspects involving network communication inevitably involve some network latency; therefore, Net consumption is the sum of these factors.

[0107] In addition, this invention analyzes the design of common secure multi-party operators, using the most basic one-to-one PSI (Power-Side Intersection) with unique intersection columns as an example. Assume there are two data sources, org1 and org2, where org1 has a data table TA and org2 has a data table TB. The table structures and the specific data stored in the two tables are as follows: Figure 3 As shown, the values ​​of aid and bid are unique, while the values ​​of ta and tb are not unique.

[0108] There is currently an SQL statement: `SELECT TA.aid FROM TA JOIN TB ON TA.aid = TB.bid`. Since both `aid` and `bid` are unique values, we need to perform a one-to-one PSI operation between the two tables (here, "one-to-one" means that the intersection columns of the two tables are mutually unique). The specific algorithm flow and diagram are as follows: Figure 4 :

[0109]

[0110]

[0111] Since the values ​​of aid and bid are unique, all rows can be uniquely identified after matching and filtering, eliminating the need for additional communication operations. This implementation of two-table one-to-one PSI forms the basis for subsequent extensions of two-table to many-to-many, many-table one-to-one, and many-table many-to-many PSI, as well as other more complex operators.

[0112] Specifically, this can include two-table many-to-many PSI, many-table one-to-one PSI, and many-table many-to-many PSI algorithms.

[0113] Suppose that for the same data source and table information, the SQL statement becomes SELECT TA.aidFROM TA JOIN TBON TA.ta=TB.tb. In this case, the intersection column no longer has unique values. Although both sides can still obtain all data that meets the conditions through matching and filtering, it is impossible to know how many times each row of data was successfully matched. Therefore, it is impossible to successfully piece together a complete result set when performing subsequent SELECT operations.

[0114] The intersection of two or more tables is used to find the set of records that meet certain conditions. It is a result set consisting of the common rows that meet the conditions in each table.

[0115] The intersection mentioned here in the context of blockchain and MPC specifically refers to Privacy Set Intersection (PSI), a technology considered the first step in cross-institutional data collaboration. Its essence is that both parties use an agreed-upon function to map elements in their respective sets, and the receiving party can then match the mapped results. Starting from this basic idea, the most intuitive approach is to use a secure hash function for mapping. However, this hash function-based mapping method has significant security vulnerabilities: when the entropy of the sets is low, participants can use brute-force collisions to calculate most or even all elements of other participants' sets. Therefore, additional privacy protection technologies are needed.

[0116] Therefore, the two-table one-to-one PSI algorithm process above needs to be improved to transmit more information during the interaction between the two parties. The specific algorithm can be described by the following process.

[0117]

[0118]

[0119] There are two tables, TA and TB, located in data sources org1 and org2 respectively. The SQL statement is SELECT TA.aid FROM TAJOIN TB ON TA.ta=TB.tb, where ta and tb are non-unique columns, meaning duplicate values ​​are allowed. In this case, the main process for PSI between the two tables is as follows.

[0120] Step 1: Obtain the output of the previous task as input based on the inputData information.

[0121] Step 2: Send the intersection values ​​to the other party using a specific privacy encryption algorithm.

[0122] Step 3: Both parties match the data sent by the other with their own data to obtain the set of intersection columns that can successfully match, and then filter out the dataset that meets the conditions locally.

[0123] Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence.

[0124] Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information, uniquely identifying the requesting row.

[0125] The overall approach to implementing the many-to-many PSI operator in two tables is as follows: Figure 5 As shown, however, the actual implementation involves some specific details and potential optimizations. For example, the row number corresponding to each value can be sent to the other party during the first matching step, reducing one communication between the two parties. However, this approach also has its disadvantages. Before matching, the intersection column corresponding to all rows that satisfy the previous Task needs to be sent, and the number of identical values ​​in these rows also needs to be counted, which will bring additional CPU and data transfer overhead. If the matching of this intersection column can filter out the vast majority of rows, and the initial number of rows is large, then exchanging one more communication between the two parties for faster local processing and less data transfer is entirely acceptable.

[0126] Multi-party PSI operator:

[0127] The one-to-one and many-to-many relationships mentioned above are both two-table dimensions, or in other words, only two data sources participate in the intersection. When more than two data sources are involved, the PSI operator needs to construct multi-table one-to-one PSI and multi-table many-to-many PSI algorithms.

[0128] Assuming that, in addition to the data mentioned above, there exists another data source org3, and a table TC exists on this data source, with the following structure and data: Figure 6 As shown in the figure. Here, cid has a unique value, while tc has a non-unique value.

[0129] The SQL statement then becomes: `SELECT TA.aid FROM TA JOIN TB ON TA.aid=TB.bid JOIN TC ON TA.aid=TC.cid`. In this scenario involving a three-way intersection, the traditional two-table PSI is clearly insufficient. We need to extend it, primarily by transforming the multi-way PSI into multiple two-way PSI operations. The following is the specific algorithm for multi-table one-to-one PSI, and the implementation process is as follows: Figure 7 As shown.

[0130]

[0131] There are three tables, TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is: SELECT TA.aid FROM TA JOIN TB ON TA.aid=TB.bid JOIN TC ON TA.aid=TC.cid, where aid, bid, and cid are all unique columns. In this scenario involving three-way intersection, the traditional two-table PSI is clearly insufficient. We need to extend it. The main idea of ​​the extension is to transform the multi-way PSI into multiple two-way PSIs. The following is the main process of multi-table one-to-one PSI.

[0132] Step 1: Obtain the output of the previous task as input based on the inputData information.

[0133] Step 2: Send the intersection values ​​to the other party using a specific privacy encryption algorithm.

[0134] Step 3: Both parties match the data sent by the other with their own data to obtain the set of intersection columns that can successfully match, and then filter out the dataset that meets the conditions locally.

[0135] Step 4: Using the data filtered in the previous step, continue with the next two-table PSI process. The process is exactly the same as the first one, continuing to filter out data that meets the criteria.

[0136] Step 5: After completing the final two-table PSI, the two tables (both sides) from this intersection will have a complete result set.

[0137] Step 6: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set;

[0138] By comparing this with the previous one-to-one PSI using two tables, we can see that in addition to multiple two-table PSI operations, an extra notification step is added at the end. The purpose of this step is to ensure that all data sources participating in the intersection calculation receive the final result set, providing complete input for subsequent tasks. This step is essential because transforming multi-table PSI into multiple two-table PSI operations is equivalent to constructing a binary tree with each data source as a node, such as... Figure 8 As shown in the diagram, we can see from these two trees that the data sources A and D that reach the end have complete result sets, while the data sources B and C that participate in the intersection only have the result sets after the intersection at that time. Of course, these two binary trees are just examples. As long as the intersection involves more than two parties, there will always be intermediate nodes with incomplete data. This is the significance of the final notification step.

[0139] While the notification step is essential, the specific method of notifying other nodes, the timing of the notification operation, and whether it's necessary to notify every participating node are all areas that can be considered and optimized. Firstly, there are different ways to notify other tables. Currently, the data source with the complete result set notifies other data sources after all intersection operations are completed. However, it's also possible to trigger the notification after each two-table PSI operation. The advantage of this approach is that all data sources always have the latest result set; the disadvantage is obvious: numerous notifications will generate additional network communication and data transmission costs. The specific method used can be chosen based on different situations and is not fixed; both methods may have their own suitable environments.

[0140] Besides these two notification methods, another possible solution is to not proactively notify after the multi-party intersection is completed, but instead postpone it until later when data needs to be retrieved from the data source. At this point, it checks whether the data source has a final result set. If it does, the subsequent operations continue directly; otherwise, a notification is generated, prompting the data source with the final result set to synchronize data with this data source. This minimizes unnecessary notification operations and can save significant network communication and data transmission overhead in many cases. However, this approach is not the absolute best choice because it significantly intrudes on the blockchain task scheduling and execution module. Since a data source without a final result set is only discovered when executing a subsequent task, a notification task needs to be inserted, which inherently incurs additional overhead. Secondly, conventional notification tasks are inserted into the scheduler during task generation, eliminating the need to remember the last two data sources involved in the intersection. This approach, however, requires remembering the data sources with the final result set, and either the scheduler needs to have the ability to generate tasks, or the task generator needs to be called again. But by this time, all tasks have already been published on the chain, and modifying them incurs significant overhead. However, going a step further, if it were possible to determine when and which data source needs to notify which data sources by parsing all tasks during the task generation phase, that might be a better solution. This would make the task generator's task generation process more complex, but in highly complex environments without many parties involved, this cost is clearly more worthwhile compared to the communication cost. However, this approach also has a significant drawback: whenever a new situation arises, the task generator's code might need to be modified, unlike previous methods such as full notification or runtime generation which do not require code modifications.

[0141] As can be seen, the situation becomes complicated once multiple parties are involved in the interaction. Moreover, the above discussion is only about one-to-one situations. If it is a multi-table, many-to-many situation, additional information needs to be carried when sending row counts between various data sources in the middle.

[0142] When the SQL statement becomes SELECT TA.aid FROM TAJOIN TB ON TA.ta=TB.tb JOIN TC ONTA.ta=TC.tc, it enters a multi-table many-to-many situation. The specific algorithm and implementation process in this case are as follows.

[0143]

[0144]

[0145] There are three tables, TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is: SELECT TA.aid FROM TA JOIN TB ON TA.ta=TB.tb JOIN TC ON TA.ta=TC.tc, where ta, tb, and tc are all non-unique columns. In this case, algorithms 4.2 and 4.3 need to be combined to complete the many-table many-to-many PSI process.

[0146] Step 1: Obtain the output of the previous task as input based on the inputData information.

[0147] Step 2: Send the intersection values ​​to the other party using a specific privacy encryption algorithm.

[0148] Step 3: Both parties match the data sent by the other with their own data to obtain the set of intersection columns that can successfully match, and then filter out the dataset that meets the conditions locally.

[0149] Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence. If a UID has already been generated, a list of UIDs needs to be attached.

[0150] Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information and uid list (update if uid already exists).

[0151] Step Six: Using the data filtered in the previous step, continue with the next two-table PSI process, which is exactly the same as the first one, to continue filtering out data that meets the criteria.

[0152] Step 7: After completing the final two-table PSI, the two tables (both sides) from this intersection will have a complete result set.

[0153] Step 8: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set.

[0154] By observing the algorithm and Figure 9 It can be observed that the implementation of many-table many-to-many PSI is roughly composed of a combination of many-table one-to-one PSI and two-table many-to-many PSI. It is worth noting that when both parties send the number of successfully matched rows, if the uid already exists, the uid list needs to be sent to the other party synchronously. The purpose of this is to ensure that the two tables participating in the PSI have a complete result set. However, when the number of successful matches is large or there are many data parties participating in the PSI, a large amount of data transmission overhead will be generated due to the long uid list.

[0155] There are indeed methods to achieve the same result as the previous one-to-one PSI without needing to transmit an additional list of uids, only transmitting the row numbers corresponding to successfully matched values. However, this introduces new problems: only data sources that participated in all PSI processes can assemble a complete uid list; uids from other data sources are left as default. For example, the SQL mentioned above, after two intersections under this scheme, will result in... Figure 10 As shown.

[0156] It can be observed that, unlike before when both TA and TC had complete result sets, after adopting this scheme, only TA has a complete result set because only TA participated in all PSIs; while TC, although participating in the last PSI, only received the number of rows N where each value matched successfully. row And N row =N TA *N TB TC is unaware of N TA and N TB The exact number of results makes it impossible to deduce the complete UID; only the relevant parts can be filled in. This example only involves three parties, so the obvious drawbacks of this approach may not be apparent. However, if we add another data source, org4, and a data table, TD, and then have TC and TD perform a PSI, then after completing all pairwise PSIs, none of the parties will be able to obtain a complete result set. At this point, additional interaction is needed to assemble the complete UID.

[0157] The beneficial effects of the technical solution of this invention are as follows:

[0158] We conducted a comprehensive and complete integration test on the SQL-like query processor for MPC in a blockchain environment (hereinafter referred to as the system) invented above. The test included two important parts: system function test and system performance test.

[0159] The system function test mainly tests whether the system, as a separate module in the Chang'an Chain, can complete the SQL parsing and optimization work normally, whether the generated TaskDAG meets the scheduling requirements in the blockchain and MPC environment, whether the interaction with other modules is reasonable, whether it is easy to use, and whether it has good scalability.

[0160] Almost all types of SQL passed the functional tests on the code side. The only exception was the GroupBy and Having clauses, which were delayed due to the development of other components of the Chang'an Chain project, making it impossible to determine the Task format required for subsequent scheduling. As for the platform side, the multi-party PSI test could not be carried out normally because the blockchain in the test environment lacked third-party nodes. The test results of other test cases were consistent with those on the code side.

[0161] Overall, the test results are quite satisfactory, indicating that the system's internal functionality and interaction with other components of the Chang'an Chain have reached a high level, meeting our expectations before development.

[0162] System performance testing primarily assesses the effectiveness of optimizations performed by a SQL optimizer-like system by comparing execution times with and without SQL optimization enabled. The following section will illustrate this with an example of predicate pushdown optimization rules.

[0163] Through the Figure 5 , 6 Our analysis reveals that predicate pushdown offers optimization benefits under all circumstances. Even in LocalJoin scenarios with a filtering rate of only 30%, it consistently reduces overall SQL execution time by 5%-10%. The optimization effect becomes more pronounced at higher filtering rates, with a 90% filtering rate providing an average optimization of around 30% in LocalJoin scenarios. In PSI scenarios, the optimization effect of predicate pushdown is particularly significant. Even a 30% filtering rate provides a 10-30% optimization effect as the data volume increases. When the filtering rate reaches 90% and the data volume exceeds 100,000 rows, the optimization effect reaches an astonishing 80%-95%. Furthermore, the optimization effect calculation given above uses the execution time of all tasks in the entire SQL, including the final Query task which is unrelated to the optimization. This will lengthen the overall time and dilute the optimization effect to some extent. The removal of invariants in the last column of the result table means that irrelevant Filter and Query tasks are removed when calculating the time. It can be seen that there is a significant improvement compared to the optimization effect of the total calculation time in the previous column, especially in scenarios with large data volumes (1 million, 5 million, etc.).

[0164] Functional testing revealed that the system is fully functional, providing excellent support for both traditional SQL and newly added SQL related to federated learning and trusted execution environments. The system also demonstrated excellent stability and robustness, running stably throughout the testing process. Even malicious SQL entries resulted in warnings, and no system crashes or other anomalies occurred. Performance testing showed that the predicate pushdown rules selected through analysis of the blockchain and MPC environments significantly shortened SQL scheduling and execution time, exhibiting excellent optimization effects. Furthermore, the cost-based Join Reorder model further accelerated SQL execution to some extent and effectively avoided slow task output to disk caused by a large number of PSI results.

[0165] While some embodiments of this disclosure have been shown and described, those skilled in the art will understand that modifications may be made to these embodiments without departing from the principles and spirit of this disclosure, which are defined by the claims and their equivalents.

Claims

1. A SQL-like query processor for secure multi-party computation, characterized in that, The overall structure is as follows: A SQL parser is designed to receive SQL statements, which are then adapted to the framework by an adapter and transformed into a logical plan and input into the SQL optimizer. The resulting physical plan is then input into the task generator, which decomposes the optimized physical plan and transforms it into a task sequence TaskDAG that is easy for the scheduler to distribute on the chain. The TaskDAG is then input into the secure multi-party operator. The SQL-like parser is implemented using Antlr4; subsequently, the Abstract Syntax Tree (AST) generated by Antlr4 will be converted into a logical plan in Calcite through an adapter; the SQL-like optimizer part requires the use of the Apache Calcite framework, and the design of the data table statistics, the optimization rules adopted, the modified cardinality estimation method and cost model are designed to obtain the physical plan; The task generator is linked to the task scheduling and distribution design of the underlying Chang'an Chain, and the parameter naming and input / output format of each task need to be strictly aligned with the upstream and downstream. Finally, the safe multi-party operator involved in the underlying task scheduling provides the operation process for safe intersection in the MPC environment; The cost model analyzes the Join operator. First, for the case where both parties in the Join operation reside in the same data source, the costs of CPU and memory are: CPU consumption is divided into two parts: the construction phase and the probing phase. Memory consumption is divided into the HashMap built from the small table and the result set generated after a successful match. For IO consumption, if the results of the previous operators are all in memory, then it is 0. Net consumption is also considered to be 0. If the two parties in the Join are located in different data sources, and the PSI operator is used to find the intersection, the CPU consumption mainly comes from the encryption and decryption operations before and after data transmission, as well as the matching operation of the intersection columns of the two parties. In the secure multi-party operator, a one-to-one PSI method with unique intersection columns is adopted. For two data sources, org1 and org2, org1 has a data table TA, and org2 has a data table TB. The values ​​of aid on org1 and bid on org2 are unique, while the values ​​of ta on org1 and tb on org2 are not unique. For a SQL statement with two tables, since aid and bid are unique values, a one-to-one PSI operation is performed. First, data is read according to the inputData information in the Task. Then, the intersection columns are sent to the other party using a specific privacy encryption algorithm. After that, both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched. Finally, data that meets the conditions is filtered out from the local table based on this set.

2. The SQL-like query processor for secure multi-party computation as described in claim 1, characterized in that, The secure multi-party operator employs a two-table many-to-many PSI method that finds the unique intersection column. There are two tables, TA and TB, located in data sources org1 and org2 respectively. The SQL statement is `SELECT TA.aid FROM TA JOIN TB ON TA.ta=TB.tb`, where both ta and tb are non-unique columns, meaning duplicate values ​​are allowed. The main process is as follows: Step 1: Obtain the output of the previous task as input based on the inputData information; Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm; Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally; Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence; Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information to uniquely identify the requested row.

3. The SQL-like query processor for secure multi-party computation as described in claim 1, characterized in that, The secure multi-party operator employs a one-to-one PSI method with unique intersection columns. There are three tables: TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is: SELECT TA.aid FROM TA JOIN TB ON TA.aid=TB.bid JOIN TC ON TA.aid=TC.cid, where aid, bid, and cid are all unique columns. The main process is as follows: Step 1: Obtain the output of the previous task as input based on the inputData information; Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm; Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally; Step 4: Use the data filtered in the previous step to continue the two-table PSI process. The process is exactly the same as the first time. Continue to filter out the data that meets the conditions. Step 5: After completing the final two-table PSI, the two tables that were intersected in this step will have a complete result set; Step 6: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set.

4. A SQL-like query processor for secure multi-party computation as described in claim 1, characterized in that, There are three tables, TA, TB, and TC, located in data sources org1, org2, and org3 respectively. The SQL statement is: SELECT TA.aid FROM TA JOIN TB ON TA.ta=TB.tb JOIN TC ON TA.ta=TC.tc, where ta, tb, and tc are all non-unique columns. The main process is as follows: Step 1: Obtain the output of the previous task as input based on the inputData information; Step 2: Send the values ​​of the intersection columns to the other party using a specific privacy encryption algorithm; Step 3: Both parties match the data sent by the other party with their own data to obtain a set of intersection column values ​​that can be successfully matched, and filter out the dataset that meets the conditions locally; Step 4: Send the corresponding row number of each successfully matched value to the other party in sequence. If a UID has already been generated, a list of UIDs needs to be attached. Step 5: Both parties add a globally unique virtual column uid to their local data table based on the received row count information and uid list. If the uid already exists, it will be updated. Step Six: Use the data filtered in the previous step to continue the two-table PSI process. The process is exactly the same as the first time. Continue to filter out the data that meets the conditions. Step 7: After completing the last two-table PSI, the two tables that were intersected in this step will have a complete result set; Step 8: Choose one of the two sides to notify the tables that participated in the intersection process, so that all data sources have the final result set.

Images