Privacy computing system and device

Abstract

The application provides a privacy computing system and device, wherein the privacy computing system comprises: a first node and at least one second node, the second node is used for executing a privacy computing task locally and feeding back an execution result to the first node based on an engine and a task instruction distributed by the first node; wherein the first node comprises at least one of the following: an engine management module, an engine registration and discovery module, and an operation and maintenance module; wherein the engine management module is used for providing a full life cycle management capability of the engine; the engine registration and discovery module is used for providing an engine discovery and / or calling capability across nodes among different second nodes; and the operation and maintenance module is used for providing a remote operation and / or state control capability of the second node. The embodiment of the application can effectively reduce the deployment and operation complexity of the privacy computing system, break through the technical barriers of manufacturers, enhance the scene adaptation capability, and help small and medium-sized customers to use conveniently and efficiently.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a privacy computing system and device. Background Technology

[0002] As the privacy computing market continues to expand, manufacturers from various fields are entering the market and developing their own privacy computing algorithms based on their own technical paths, and have also developed independent privacy computing platforms.

[0003] However, these existing platforms and engines have obvious drawbacks: First, they are highly complex. Traditional privacy computing platforms rely on distributed clusters, requiring professional teams for deployment and incurring high hardware procurement and maintenance costs, which are difficult for small and medium-sized customers to afford. Second, they suffer from fragmented ecosystems. Privacy computing engines from different vendors, such as AntChain, WeBank, and Tencent Cloud, use independent technology stacks, and cross-platform collaboration requires significant resources for customized development, resulting in low efficiency. Third, they lack flexibility. Users cannot combine algorithm components as needed according to business requirements, and task initiation relies on code development (such as Python and Java), making it difficult to quickly adapt to diverse scenarios such as healthcare, finance, and government affairs. Summary of the Invention

[0004] This application provides a privacy computing system and device to address the problems of high system complexity, fragmented cross-vendor ecosystems, and insufficient flexibility in scenario adaptation of existing privacy computing platforms.

[0005] In a first aspect, a privacy-preserving computing system is provided, comprising: a first node and at least one second node, wherein the second node is configured to execute privacy-preserving computing tasks locally based on engine and task instructions distributed by the first node and to feed back the execution results to the first node; wherein...

[0006] The first node includes at least one of the following: an engine management module, an engine registration and discovery module, and an operation and maintenance module;

[0007] The engine management module is used to provide full lifecycle management capabilities for the engine.

[0008] The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes;

[0009] The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node;

[0010] The second node includes at least one of the following: an engine operation support module, a task scheduling module, and a data resource management module;

[0011] The engine operation module provides the engine operating environment and / or resource isolation capabilities; the task scheduling module provides the scheduling and / or execution capabilities of privacy computing tasks; and the data resource management module provides local data access, de-identification, and / or authorization management capabilities.

[0012] Optionally, the engine management module includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit;

[0013] Among them, the engine meta-information database unit is used to store engine information;

[0014] The engine package storage unit is used to store the engine's operating resources;

[0015] The version management unit is used to support parallel management of multiple versions of the same engine and records the iteration log of each engine version.

[0016] The access control unit is used to manage the second node's access permissions to the engine.

[0017] Optionally, the engine registration and discovery module includes at least one of the following: a registration center unit and a service discovery proxy unit;

[0018] The registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of the engine;

[0019] The service discovery agent unit is used to receive service query requests from the second node and send a list of engines that match the service query requests to the second node.

[0020] Optionally, the operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit;

[0021] The node status monitoring unit is used to collect the hardware indicators and / or service status of the second node;

[0022] The remote upgrade management unit is used to push the engine upgrade package to the second node;

[0023] The fault repair unit is used to detect the abnormal state of the second node, and triggers the second node to perform a preset repair action after detecting the abnormal state.

[0024] Optionally, the remote upgrade management unit is further configured to: confirm the remaining disk space of the second node, confirm that there are no running tasks, and verify the compatibility between the current version of the engine and the target version before pushing the engine upgrade package to the second node; and, in the event of an engine upgrade failure, trigger the failed engine in the second node to roll back to the version before the upgrade.

[0025] Optionally, the engine running module satisfies at least one of the following: each engine is run using a customized container; an independent engine is deployed in one namespace; and it supports access to different types of storage media and hierarchical data storage management.

[0026] Optionally, the task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein,

[0027] The task queue unit is used to store privacy computing tasks to be executed according to priority;

[0028] The executor management unit is used to manage local task execution threads.

[0029] The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules.

[0030] Optionally, the data resource management module includes at least one of the following: a data access unit, a data anonymization unit, and an authorization management unit; wherein,

[0031] The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks;

[0032] The data desensitization unit is used to process sensitive fields in the data;

[0033] The authorization management unit is used to record authorization information for the data.

[0034] Optionally, the second node further includes a resource situation awareness module, which includes at least one of the following: an indicator acquisition unit, an anomaly warning unit, and a data reporting unit; wherein,

[0035] The indicator collection unit is used to collect at least one of the following: hardware resource indicators, network status indicators, and engine status indicators of the second node.

[0036] The anomaly warning unit is used to identify abnormal states during the operation of the second node and issue early warnings.

[0037] The data reporting unit is used to report the content collected by the indicator collection unit to the first node.

[0038] Secondly, a first node is provided, which includes at least one of the following: an engine management module, an engine registration and discovery module, and an operation and maintenance module;

[0039] The engine management module is used to provide full lifecycle management capabilities for the engine.

[0040] The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes;

[0041] The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node.

[0042] Optionally, the engine management module includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit;

[0043] Among them, the engine meta-information database unit is used to store engine information;

[0044] The engine package storage unit is used to store the engine's operating resources;

[0045] The version management unit is used to support parallel management of multiple versions of the same engine and records the iteration log of each engine version.

[0046] The access control unit is used to manage the second node's access permissions to the engine.

[0047] Optionally, the engine registration and discovery module includes at least one of the following: a registration center unit and a service discovery proxy unit;

[0048] The registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of the engine;

[0049] The service discovery agent unit is used to receive service query requests from the second node and send a list of engines that match the service query requests to the second node.

[0050] Optionally, the operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit;

[0051] The node status monitoring unit is used to collect the hardware indicators and / or service status of the second node;

[0052] The remote upgrade management unit is used to push the engine upgrade package to the second node;

[0053] The fault repair unit is used to detect the abnormal state of the second node, and triggers the second node to perform a preset repair action after detecting the abnormal state.

[0054] Thirdly, a second node is provided, the second node including at least one of the following: an engine operation support module, a task scheduling module, and a data resource management module;

[0055] The engine operation module provides the engine operating environment and / or resource isolation capabilities; the task scheduling module provides the scheduling and / or execution capabilities of privacy computing tasks; and the data resource management module provides local data access, de-identification, and / or authorization management capabilities.

[0056] Optionally, the engine running module satisfies at least one of the following: each engine is run using a customized container; an independent engine is deployed in one namespace; and it supports access to different types of storage media and hierarchical data storage management.

[0057] Optionally, the task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein,

[0058] The task queue unit is used to store privacy computing tasks to be executed according to priority;

[0059] The executor management unit is used to manage local task execution threads.

[0060] The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules.

[0061] Optionally, the data resource management module includes at least one of the following: a data access unit, a data anonymization unit, and an authorization management unit; wherein,

[0062] The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks;

[0063] The data desensitization unit is used to process sensitive fields in the data;

[0064] The authorization management unit is used to record authorization information for the data.

[0065] In this embodiment, the full lifecycle management capabilities provided by the engine management module of the first node and the remote control functions of the operation and maintenance module, combined with the lightweight operating environment built by the engine operation and bearing module of the second node, significantly reduce the complexity of system deployment and operation and maintenance, enabling small and medium-sized customers to use the system conveniently without the need for professional technical teams or high hardware costs. The engine registration and discovery module of the first node enables efficient discovery and invocation of heterogeneous engines across different vendors between different second nodes, breaking down the barriers between vendor technology stacks, eliminating the need for customized development during cross-platform collaboration, and effectively improving collaboration efficiency. Relying on the flexible scheduling capabilities of the task scheduling module and the local data management functions of the data resource management module of the second node, users can flexibly match algorithm resources and configure computing tasks according to the actual needs of different scenarios such as healthcare, finance, and government affairs, completing the operation without relying on code development, thereby effectively enhancing the system's adaptability to diverse business scenarios. Attached Figure Description

[0066] Figure 1 This is a schematic diagram of a system architecture provided in an embodiment of this application;

[0067] Figure 2 This is a flowchart of engine management provided in an embodiment of this application;

[0068] Figure 3 This is a flowchart of the manufacturer's engine registration process provided in the embodiments of this application;

[0069] Figure 4 This is a flowchart of the engine upgrade for the second node provided in an embodiment of this application;

[0070] Figure 5 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0071] In the embodiments of this application, the terms "first," "second," and "third" are used to distinguish identical or similar items with essentially the same function and purpose. Those skilled in the art will understand that the terms "first," "second," and "third" do not limit the quantity or execution order, nor are they necessarily required to be different. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0072] It should be understood that in the embodiments of this application, "at least one" refers to one or more; "multiple" refers to two or more. Furthermore, the word "equal to" in this application can be used in conjunction with "greater than" or "less than". When "equal to" and "greater than" are used together, the technical solution of "greater than" is adopted; when "equal to" and "less than" are used together, the technical solution of "less than" is adopted.

[0073] In the embodiments of this application, the terms "of," "corresponding (relevant)," "corresponding," "associated (related)," and "mapped" may sometimes be used interchangeably. It should be noted that when no distinction is emphasized, the concepts or meanings expressed are consistent.

[0074] First, the relevant technologies involved in the embodiments of this application will be described.

[0075] In the field of privacy computing, technologies such as Federated Learning (FL), PrivateSet Intersection (PSI), and Private Information Retrieval (PIR) are the core foundations for achieving data that is "usable but not visible." Federated Learning avoids sharing raw data by collaboratively training models through distributed nodes; PSI is used to compute intersection data among multiple parties without revealing non-intersection information; and PIR allows clients to retrieve information from server data without exposing the retrieved content. These technologies have been widely applied in cross-institutional data collaboration scenarios.

[0076] The Federated AI Technology Enabler (FATE) platform, as a typical federated learning platform, adopts a distributed cluster architecture and includes modules for federated training, evaluation, and inference. Its deployment relies on container orchestration tools such as Kubernetes, requiring a professional team to configure node communication and data sharding rules. It supports homogeneous federated learning tasks, but is only compatible with its own technology stack's algorithm components; cross-platform collaboration requires custom interface development.

[0077] TensorFlow Federated (Google): A federated learning framework based on the TensorFlow ecosystem. It relies on distributed computing clusters and supports the construction and training of federated models. Users need to write the federated task logic in code. It only supports TensorFlow-compatible algorithm components and cannot be directly integrated with privacy computing engines from other vendors (such as AntChain and Tencent Cloud).

[0078] AntChain's Privacy Computing Engine focuses on combining blockchain with privacy computing. It employs an independent encryption protocol and engine architecture, supporting technologies such as Secure Multi-Party Computation (SMPC). Its deployment requires integration with the AntChain ecosystem infrastructure. Collaboration with other vendor engines (such as WeBank's FL engine) requires customized data transformation interfaces, and it consumes significant resources, making it suitable only for large institutions.

[0079] Disadvantages of existing technology:

[0080] 1) High system complexity: Traditional privacy computing platforms (such as FATE and TensorFlow Federated) rely on distributed clusters, requiring professional teams for deployment and incurring high hardware costs.

[0081] 2) Fragmented ecosystem: Different vendors (such as AntChain, WeBank, and Tencent Cloud) use independent technology stacks for their privacy computing engines, and cross-platform collaboration requires customized development, which is inefficient.

[0082] 3) Insufficient flexibility: Users cannot combine algorithm components as needed, and task initiation relies on code development, making it difficult to adapt to diverse scenarios such as healthcare, finance, and government affairs.

[0083] The following description, in conjunction with the accompanying drawings, details a system message receiving method, sending method, apparatus, and device provided in this application through some embodiments and application scenarios.

[0084] See Figure 1 Embodiments of this application provide a privacy computing system, including: a first node and one or more second nodes, wherein the second nodes are configured to execute privacy computing tasks locally based on engine and task instructions distributed by the first node and report the execution results back to the first node; wherein,

[0085] The first node includes at least one of the following: an engine management module, an engine registration and discovery module, and an operation and maintenance module;

[0086] The engine management module is used to provide full lifecycle management capabilities for the engine;

[0087] The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes;

[0088] The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node;

[0089] The second node includes at least one of the following: an engine operation support module, a task scheduling module, and a data resource management module;

[0090] The engine operation support module is used to provide the engine operating environment and / or resource isolation capabilities;

[0091] The task scheduling module is used to provide the ability to schedule and / or execute privacy computing tasks;

[0092] The data resource management module is used to provide local data access, de-identification, and / or authorization management capabilities.

[0093] Optionally, the first node can also be referred to as the first communication device.

[0094] Optionally, the second node can also be referred to as a second communication device.

[0095] In this embodiment, the privacy computing system adopts a "center-edge" collaborative architecture. The first node is responsible for global management, engine distribution and modeling agent, while the second node is responsible for local data processing and task execution. The two communicate securely through an encrypted channel.

[0096] Optionally, the engine may include at least one of the following: FL engine, PSI engine, or PIR engine.

[0097] In some implementations, the engine management module manages all engines, including those packaged by different vendors. Engines managed by this module can be downloaded, deployed, and used by the second nodes in the network. The operations and maintenance module upgrades the application image versions within the second nodes of the network, enabling remote operations and maintenance.

[0098] In some implementations, the engine registration and discovery module is a module that assists the second node in realizing the interconnection of heterogeneous engines. Through a unified registration protocol and multi-language software development kit (SDK) support, it ensures that computing engines from different vendors can dynamically register service information and realize cross-node service discovery and invocation, ensuring that engines from different vendors can work together on the platform.

[0099] In some implementations, the operations and maintenance module can enable remote management (upgrades, monitoring, or fault recovery) of the second node, reducing the operations and maintenance costs for small and medium-sized customers.

[0100] In some implementations, the second node is a scheduling and deployment platform used by the engine. It can download and deploy newly released engines from the first node, perform full lifecycle management of the deployed engines, and audit all operations within the engines. The second node can execute privacy-preserving computation tasks through the engines, including but not limited to at least one of the following: federated modeling, PSI, PIR, etc.

[0101] In one embodiment of this application, the engine management module of the first node includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit;

[0102] The engine metadata repository unit is used to store engine information. Optionally, the engine information includes at least one of the following: engine name, vendor, version, resource requirements, and supported algorithm types. Optionally, the engine metadata repository unit is also used to support fast retrieval and multi-dimensional filtering of engine information. The multi-dimensional filtering includes at least one of the following: filtering by application scenario and filtering by performance metrics. Optionally, the engine metadata repository unit is implemented using a combined MySQL and Elasticsearch architecture, where MySQL is used to store structured metadata, and Elasticsearch is used to provide efficient full-text search and multi-condition filtering capabilities.

[0103] The engine package storage unit is used to store the engine's runtime resources. Optionally, the runtime resources include at least one of the following: an engine image package, configuration files, and dependency libraries. Optionally, the engine package storage unit is also used to support breakpoint resumption and integrity verification. The breakpoint resumption is used to avoid repeated downloads caused by transmission interruptions, and the integrity verification is used to prevent the engine package from being tampered with. Optionally, the engine package storage unit is implemented based on MinIO distributed storage, using sharding storage technology to split large-volume engine packages to improve transmission efficiency, and using the SHA256 hash algorithm to implement engine package integrity verification.

[0104] The version management unit supports parallel management of multiple versions of the same engine, recording the iteration log for each engine version. Optionally, the iteration log includes at least one of the following: fixed security vulnerabilities, newly added algorithmic features, and compatibility adjustments. Optionally, the version management unit also supports engine version rollback; when a new engine version has issues, it can revert to a historical stable version. Optionally, the version management unit adopts Git-like version control logic, assigning a unique identifier, such as a commit ID, to each engine version, associating the version iteration log with the corresponding engine package, and achieving precise version switching and rollback through the engine version identifier.

[0105] The access control unit manages the access permissions of second nodes to the engine. Optionally, the access permissions include at least one of the following: authorizing only second nodes to download a specific engine, or making the engine publicly visible to all second nodes in the network to ensure the compliant distribution of engine resources. Optionally, the access control unit stores the access rules in a cache. When a second node initiates an engine download request, it must carry the second node's certificate and token. The access control unit verifies the legitimacy of the engine download request through a token verification mechanism, and only second nodes that pass the verification can download the engine.

[0106] See Figure 2 First, the vendor uploads the engine: The vendor submits the engine through the first node, filling in the relevant engine information (such as "FL engine v2.1, supports linear regression and logistic regression, resource requirements 2 cores 4G"). The first node automatically performs format verification (such as whether the image package conforms to the Open Container Initiative (OCI) standard).

[0107] Secondly, the operations team reviews the engine's compliance (such as whether it complies with the data encryption requirements of the Personal Information Protection Law). After the review is passed, the engine's metadata database unit is entered and a unique engine ID is assigned.

[0108] Finally, the second node download: When the second node initiates a download request, it carries the second node's certificate and token. The first node will automatically start the verification task. After successful verification, it will transmit the engine package fragments to the second node via Hypertext Transfer Protocol Secure (HTTPS). After receiving the data, the second node will perform SHA256 verification. If the verification passes, the installation is complete; if the verification fails, the installation fails and needs to be reinstalled.

[0109] In one embodiment of this application, the engine registration and discovery module includes at least one of the following: a registration center unit, a service discovery proxy unit, and a multi-language SDK unit;

[0110] The registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of engines in the engine registry. Optionally, the status includes at least one of the following: running, offline, or abnormal. For example, the registration center unit maintains the status by periodically (e.g., at 30-second intervals) sending confirmation response information to the second node corresponding to the engine in the engine registry. If the second node fails to respond to the confirmation response information multiple times consecutively, the status of the engine corresponding to the second node is determined to be abnormal, and the registration information of the engine is removed from the engine registry.

[0111] The service discovery proxy unit receives service query requests from the second node. These requests include at least one of the following: querying available PSI engines, querying federated learning engines with normal health status, and returning a list of engines that match the service query request. Optionally, the engine list includes the engine's address. Optionally, the service discovery proxy unit implements its functionality through a query interface based on gRPC (gRPC is a modern open-source high-performance RPC framework that can run in any environment). It supports filtering engines based on at least one of the following conditions: engine type (e.g., FL, PSI, PIR, etc.), health status (online, offline, or abnormal), response latency (low, medium, or high). This achieves accurate service discovery, avoids invalid requests and resource waste, and allows the first node to update the engine registry in real time when a new engine is registered or an old engine is taken offline, ensuring that the query results always reflect the latest available resources.

[0112] The multi-language SDK unit provides software development kits for multiple languages ​​(such as Java, Python, or Go), simplifying the registration and adaptation process of heterogeneous vendor computing engines on the second node, enabling vendors to complete registration without modifying the engine's core code. The multi-language SDK unit encapsulates a unified registration protocol, which includes at least one of the following: registration message format and heartbeat packet structure. Vendors only need to call the registration interface provided by this unit to complete the protocol adaptation related to engine registration.

[0113] The engine registration and cross-node invocation process in this application includes:

[0114] First, engine registration can include the manufacturer's engine registration process and the second-node's engine registration process.

[0115] See Figure 3 The manufacturer sends an engine registration request to the first node, the first node obtains relevant engine information, reviews the engine, notifies the manufacturer to modify the engine, the manufacturer uploads the engine, the first node tests the engine, and saves the engine to the engine repository.

[0116] The engine registration process for the second node is as follows: After the second node starts the engine, it sends an engine registration request to the first node (for example, the engine registration request includes at least one of the following: engine ID, node IP, port, supported algorithm interface, etc.). After the first node receives the engine registration request, it maintains the engine registry and sends a confirmation response message to the second node corresponding to the engine in the engine registry every 30 seconds to determine whether the engine is still online. If the engine does not respond more than 3 times, the first node will remove the registration information of the engine from the engine registry.

[0117] Secondly, the cross-node call process is as follows: When the second node A needs to call the PSI engine, it sends a service query request to the first node, and the first node returns the PSI engine address of the second node B; the second node A initiates the call to the second node B through the TLS channel, carrying encrypted task parameters (such as dataset ID and calculation rules); after the second node B executes the call, it returns the encrypted result, and the second node A decrypts it and continues processing.

[0118] In this embodiment, the first node monitors the engine load (e.g., CPU utilization, task queue length, etc.) in real time through the Prometheus service deployed on the machine. Specifically, the Prometheus interface queries in real time, and when returning the results of the service query request, it prioritizes recommending low-load engines to avoid single-point overload; that is, the engine list includes low-load engines. For example, when the PSI engine load of the second node B exceeds 80%, new requests are automatically routed to the same type of engine on the second node C.

[0119] In one embodiment of this application, the operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit;

[0120] The node status monitoring unit is used to collect hardware metrics and / or service status of the second node. Optionally, the hardware metrics include at least one of the following: CPU utilization, memory utilization, and disk utilization; the service status includes at least one of the following: engine operation logs and error codes. Optionally, the node status monitoring unit is implemented based on Prometheus and Grafana visualization tools, and collects metrics (resource usage ≤ 5%) through a lightweight agent, refreshing the data every 10 seconds to ensure real-time monitoring of the node's operating status.

[0121] The remote upgrade management unit is used to push the engine upgrade package to the second node. Optionally, the remote upgrade management unit supports version rollback after upgrade failure. Specifically, in the event of engine upgrade failure, the remote upgrade management unit triggers the failed engine in the second node to roll back to the version before the upgrade. Optionally, the remote upgrade management unit uses differential compression processing on the upgrade package (transmitting only the differences from the old version) and achieves efficient transmission of the upgrade package through the Remote Sync (Rsync) protocol. Before the upgrade is executed, a pre-check process is also performed, which includes at least one of the following: confirming the remaining disk space on the second node, confirming that there are no running tasks (or that tasks can be paused), and verifying the compatibility between the current engine version and the target version. If any pre-check item fails, the upgrade is terminated and the specific reason is returned.

[0122] The fault repair unit is used to detect abnormal states of the second node and triggers the second node to perform preset repair actions upon detection of an abnormal state. Optionally, the abnormal state includes at least one of the following: engine crash, disk space full. Optionally, the repair actions include at least one of the following: automatic engine restart, cache clearing. The fault repair unit presets self-healing rules, such as "automatic restart within 5 minutes after engine crash," and executes specific repair commands through the Ansible automation tool to reduce manual maintenance intervention.

[0123] In some implementations, participants Figure 4 The second node upgrade process shown includes:

[0124] The first node selects the second node, then generates the engine installation package, sends an upgrade command to the second node, and notifies the second node to perform the upgrade.

[0125] After receiving the upgrade command, the second node performs checks and pre-checks (hardware conditions, service status, compatibility) and executes the upgrade. The pre-check process is as follows: before the first node sends the upgrade command, it checks the status of the second node.

[0126] For hardware requirements: Remaining disk space ≥ 3 times the size of the upgrade package (to avoid insufficient space);

[0127] Regarding service status: No tasks are running (or tasks can be paused);

[0128] Regarding compatibility: Verify the compatibility between the current engine version of the second node and the target version (e.g., whether the dependency libraries match).

[0129] If any of the hardware conditions, service status, or compatibility requirements are not met, the upgrade will fail and a specific reason will be returned (such as "Insufficient remaining space, 1GB needs to be cleaned up"). Manual intervention is supported.

[0130] Next, the upgrade is executed: the second node downloads the upgrade package (using HTTPS + resumable interruption), and performs SHA256 verification upon completion. Verification is primarily to confirm the integrity of the acquired package data; if verification fails, the process ends and the reason for failure is returned. The application image is then replaced by deploying the new image service using the deployment command, and the process startup status is monitored (timeout period 30 seconds).

[0131] During the above process, a rollback mechanism is adopted. If the service fails to start after the upgrade (such as process crash or port not listening), the second node automatically performs a rollback: deletes the new program, restores the backed-up configuration and data, and restarts the service; at the same time, it sends an alarm (including failure logs) to the first node to support manual troubleshooting.

[0132] In one embodiment of this application, the engine running host module satisfies at least one of the following:

[0133] (1) Each engine is carried out using a customized container;

[0134] The engine operation carrier module serves as the engine's runtime environment, managing the entire lifecycle of the computing engine container, including image pulling and container startup / shutdown, while also enabling lightweight deployment. The engine operation carrier module is implemented using a customized container (containerd), stripping away unnecessary functions (such as Swarm mode). For example, the deployment engine size is compressed to 30MB, and the container startup time is less than or equal to 10 seconds, while traditional Kubernetes nodes require more than 5 minutes to start, meeting the low resource consumption needs of small and medium-sized customers.

[0135] (2) A namespace deploys a separate engine.

[0136] Optionally, the engine running module is implemented based on Linux control groups (cgroups) technology, which can configure resource restriction rules for different namespaces. Optionally, the resource restriction rules include limiting the number of CPU cores, memory limits, etc., such as "configure the federated learning (FL) engine to use a maximum of 1 CPU core and 2GB of memory", and deploy an independent engine (including the engine's full functionality) in one namespace, to avoid system crashes due to resource abuse by a single engine. cgroups combined with namespaces achieve resource isolation, ensuring that different engines (such as FL, PSI, PIR) run in independent environments and avoid mutual interference.

[0137] (3) Supports access to different types of storage media and hierarchical data storage management, improving the engine's data access speed;

[0138] The engine's runtime module supports access to local disks (such as the Fourth Extended File System (ext4) and the X File System (XFS)) and network storage (such as the Network File System (NFS)). It also adopts a tiered storage strategy, storing hot data in memory to reduce access latency and storing cold data on disk to save memory resources, thus adapting to the dynamic data access needs of the computing engine.

[0139] The engine startup and resource adjustment process in this embodiment is as follows:

[0140] Engine Startup: After receiving the start command from the first node, the second node pulls the engine image (if it doesn't exist in the local cache), creates the container (configuring control group restrictions and network port mappings), executes the startup script (such as initializing the encryption key), and returns a "ready" status upon successful startup. The engine image is the container engine (Docker) image. An engine, such as federated modeling, may consist of 20 or more Docker images. Therefore, when starting the engine, it first checks if these Docker images exist locally; if not, it pulls them from the central repository. Once deployed, the image becomes a container. A Docker image is a file; after deployment, it becomes a Docker container used to provide services.

[0141] Dynamic resource adjustment: The second node monitors the engine's resource usage. When the FL engine's memory usage exceeds the threshold (e.g., 1.5G), it automatically triggers expansion (temporarily adding 0.5G of memory). Resources are reclaimed after the task ends.

[0142] In one embodiment of this application, the task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein,

[0143] The task queue unit is used to store privacy-preserving computation tasks (such as federated learning tasks, PSI tasks, and PIR tasks) to be executed according to priority, ensuring that high-priority tasks are executed first. Optionally, the task priority is divided into P0-P3 levels (P0 being the urgent priority); optionally, the task queue unit is implemented based on the sorted set (zset) data structure of a remote dictionary server (Redis), and tasks are sorted according to the rule of "score = priority + submission time" to ensure the timeliness and accuracy of task scheduling and avoid delays in the execution of high-priority tasks.

[0144] The executor management unit manages local task execution threads, controls the number of tasks running simultaneously, and prevents node failure due to thread resource exhaustion. Optionally, the executor management unit adopts a thread pool design, with the number of core threads matching the number of CPU cores on the node, and the maximum number of threads set to twice the number of CPU cores (e.g., 4 core threads and 8 maximum threads when the CPU has 4 cores). Optionally, the executor management unit can limit the concurrency of specific task types (e.g., a maximum of 3 federated learning tasks running simultaneously) to balance the resource consumption of different task types and avoid excessive resource consumption by a single task type.

[0145] The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules to ensure the stability of task execution. Optionally, the exceptions include at least one of the following: data format error, computing engine crash, network timeout, and insufficient resources; optionally, the exception handling unit presets differentiated rules, such as "retry 3 times (with a 5-second interval between each retry) in the network timeout scenario" and "automatically switch to the backup engine in the engine crash scenario"; optionally, the exception handling unit also records exception logs (including task ID, exception type, and occurrence time) to support subsequent problem tracing and investigation, reducing manual intervention costs.

[0146] The process for the second node to perform its task in this application includes:

[0147] The second node receives the tasks (including task ID, priority, and parameters) distributed by the first node and adds them to the queue of the corresponding priority. The second node can be understood as an engine scheduling platform that arranges task execution according to the orders. For example, if there are PSI tasks, federated learning tasks, and data processing tasks, the second node, as the engine scheduling center, will schedule and allocate the order tasks according to the rules and collect the results and progress.

[0148] The executor management unit retrieves privacy computing tasks to be executed from the task queue unit, checks local resources (such as whether memory is sufficient), and if so, calls the engine interface to execute them.

[0149] The second node reports its progress to the first node in real time while performing tasks (e.g., "FL training completed 30%)", and retryes according to rules in case of abnormalities (e.g., retrying after 5 seconds if the failure is due to network fluctuations).

[0150] After the second node completes its execution, it uploads the encrypted results (such as model parameters and evaluation reports) to the first node, while simultaneously retaining logs locally (for easy traceability).

[0151] In one embodiment of this application, the data resource management module includes at least one of the following: a data access unit, a data desensitization unit, and an authorization management unit; wherein,

[0152] The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks. Optionally, the data source includes at least one of the following: a MySQL database, an Oracle database, or a comma-separated values ​​file (CSV); optionally, the data format includes structured data and unstructured data; optionally, the data access unit is a lightweight modification based on the Apache NiFi data workflow automation tool, providing visual data pipeline configuration functions (such as "synchronizing a specified data table from MySQL to local storage"), allowing data source access to be completed without code development, reducing the operational threshold.

[0153] The data anonymization unit is used to process sensitive fields in the data to prevent the leakage of sensitive information and comply with privacy protection regulations (such as the Personal Information Protection Law). Optionally, the sensitive fields include at least one of the following: ID card number, bank card number, mobile phone number, and medical record address. Optionally, the data anonymization unit has a built-in anonymization rule library, and the rules include at least one of the following: masking (such as "110101********1234"), character replacement, and field truncation. Optionally, the data anonymization unit supports user-defined anonymization rules (such as hiding the specific department in the medical record in a hospital setting) to adapt to the data privacy needs of different industries.

[0154] The authorization management unit is used to record data authorization information, control the scope of data use and operation permissions, and ensure that the data is "usable but not visible". Optionally, the authorization information includes at least one of the following: authorized tenant, data usage period, and allowed computational operations (e.g., only PSI computation is allowed, downloading raw data is prohibited); Optionally, the authorization management unit uses blockchain notarization technology (e.g., AntChain consortium blockchain) to store authorization records to ensure that the records are tamper-proof and facilitate auditing and traceability; Optionally, when a tenant task calls data, the authorization management unit automatically verifies the validity of the authorization (e.g., whether it is within the usage period, whether the operation complies with the restrictions), and after successful verification, only an encrypted subset of non-sensitive fields is provided to prevent data abuse.

[0155] In this embodiment, the data resource management module is used to realize the full lifecycle management of local data (access, cleaning, authorization, and destruction) to ensure that the data is "usable but not visible" and complies with privacy protection regulations.

[0156] In this embodiment, the data authorization and usage control process includes:

[0157] After a user uploads a local dataset, the privacy computing system automatically detects sensitive fields and prompts for de-identification (e.g., "Mobile number field detected, do you want to apply masking for de-identification?").

[0158] When users authorize datasets to tenant spaces, they can set usage periods (e.g., "valid until 2023-12-31") and operation restrictions (e.g., "only PSI calculations are allowed, downloading raw data is prohibited").

[0159] When a task in the tenant space calls this dataset, the second node verifies the validity of the authorization (whether it is within the validity period and whether the operation complies with the restrictions). If it passes the verification, it provides an encrypted subset of fields (non-sensitive fields in plaintext, sensitive fields in encryption).

[0160] In one embodiment of this application, the second node further includes a resource situation awareness module. The resource situation awareness module is used to monitor at least one of the following in real time: hardware resources (CPU, memory, disk), network status (bandwidth, latency), and engine status (load, response time), providing a basis for decision-making regarding the scheduling of the first node. Since different computing engines have different resource requirements, the first node needs to provide basic metadata when uploading the engine package, such as the minimum supported available resources (how many CPUs, how much memory, etc.). When the second node pulls the computing engine container, it needs to check whether the available resources on the current machine support running the engine; if insufficient, an alarm needs to be issued.

[0161] In one embodiment of this application, the resource situation awareness module includes at least one of the following: an indicator collection unit, an anomaly warning unit, and a data reporting unit; the indicator collection unit is used to collect at least one of the following: hardware resources, network status, and engine operation-related indicators of the second node, providing data support for resource scheduling and operation and maintenance. Optionally, the hardware resource indicators include at least one of the following: CPU utilization, memory utilization, and disk utilization; the network status indicators include at least one of the following: bandwidth usage and network latency; the engine status indicators include at least one of the following: engine load and response time; optionally, the indicator collection unit is implemented using extended Berkeley Packet Filter (eBPF) technology, which has low invasiveness characteristics, resource usage ≤2%, and avoids performance loss to the normal operation of the node.

[0162] The anomaly warning unit is used to identify abnormal states during the operation of the second node and issue early warnings to reduce the impact of failures. Optionally, the abnormal states include at least one of the following: sudden increase in memory usage, persistently high CPU utilization, engine unresponsiveness, and network latency exceeding a threshold. Optionally, the anomaly warning unit achieves anomaly identification based on "threshold judgment + machine learning model (such as Isolation Forest)," with a warning accuracy greater than or equal to 90%, and can issue warnings 5 ​​minutes in advance to allow maintenance personnel time to handle the situation. Optionally, the warning information will be synchronized to the first node for convenient global maintenance management.

[0163] The data reporting unit is used to report the content collected by the indicator collection unit to the first node at a specified frequency to support global resource scheduling decisions. Optionally, the reporting frequency is on the minute level, and the reported content includes at least one of the following: the node's current CPU utilization, remaining memory, real-time load of each engine, and average network latency. Optionally, the data reporting unit only reports key indicators to reduce data transmission volume, while ensuring that the first node can grasp the resource status of each node in real time so as to dynamically adjust task allocation (such as tilting new tasks to low-load nodes). In addition, the data reporting unit will also combine engine metadata (such as the minimum resource requirements of the engine) to help the first node determine whether the node has the resource conditions to run a new engine. If the resources are insufficient, an alarm will be triggered.

[0164] In this application, compared with traditional privacy-preserving computation schemes (such as FATE and TensorFlow Federated), the privacy-preserving computation system of this application can achieve the following technical effects, specifically reflected in four dimensions: deployment efficiency, cross-platform collaboration, modeling threshold, and resource consumption:

[0165] 1) This application deploys an engine package of less than or equal to 50MB, supporting one-click deployment and completing the entire process within 5 minutes; traditional solutions deploy engine packages of 2GB or more, requiring a professional team to configure and complete deployment in 2-3 days. This technology can reduce download and storage costs for small and medium-sized customers, while improving deployment efficiency by 99%, solving the pain points of traditional solutions that rely on professional operation and maintenance and have long deployment cycles, enabling small and medium-sized customers to build nodes independently without a professional technical team.

[0166] 2) This application supports seamless collaboration between heterogeneous engines such as Federated Learning (FL) and Secure Multi-Party Intersection (PSI) on the platform through a unified engine registration standard (with a supporting multi-language SDK) and engine repository management mechanism, replacing the traditional approach that requires customized interface development. This technology can break down the technical stack barriers between different vendors, improve cross-platform collaboration efficiency by more than 80%, and effectively solve the problem of ecosystem fragmentation in the traditional privacy computing field.

[0167] 3) This application establishes an aerial modeling platform and provides a visual canvas, allowing business personnel to initiate privacy-preserving computation tasks by dragging and dropping components. The first node is only responsible for building the model canvas, while the actual task execution is completed in the second node, requiring no code development throughout. This technology is adaptable to diverse business scenarios such as healthcare and finance, solving the problems of traditional platforms (such as TensorFlow Federated) that rely on code development and lack flexibility, while shortening the modeling cycle by 60%.

[0168] 4) The over-the-air maintenance module of this application supports remote upgrades of lightweight base nodes. Before the upgrade, a pre-check is performed (including checking remaining space, database backup status, etc.), and a version rollback can be triggered if the upgrade fails. Simultaneously, a health check mechanism is used to monitor the engine's operating status in real time. Compared to the traditional local maintenance mode of the platform, this technology can reduce maintenance costs by 60% and improve engine upgrade stability to over 99%.

[0169] Embodiments of this application also provide a first node, which includes at least one of the following: an engine management module, an engine registration and discovery module, and an operation and maintenance module;

[0170] The engine management module is used to provide full lifecycle management capabilities for the engine.

[0171] The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes;

[0172] The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node.

[0173] In some implementations, the engine management module includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit;

[0174] Among them, the engine meta-information database unit is used to store engine information;

[0175] The engine package storage unit is used to store the engine's operating resources;

[0176] The version management unit is used to support parallel management of multiple versions of the same engine and records the iteration log of each engine version.

[0177] The access control unit is used to manage the second node's access permissions to the engine.

[0178] In some implementations, the engine registration and discovery module includes at least one of the following: a registration center unit and a service discovery proxy unit;

[0179] The registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of the engine;

[0180] The service discovery agent unit is used to receive service query requests from the second node and send a list of engines that match the service query requests to the second node.

[0181] In some implementations, the operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit;

[0182] The node status monitoring unit is used to collect the hardware indicators and / or service status of the second node;

[0183] The remote upgrade management unit is used to push the engine upgrade package to the second node;

[0184] The fault repair unit is used to detect the abnormal state of the second node, and triggers the second node to perform a preset repair action after detecting the abnormal state.

[0185] Embodiments of this application also provide a second node, which includes at least one of the following: an engine operation support module, a task scheduling module, and a data resource management module;

[0186] The engine operation module provides the engine operating environment and / or resource isolation capabilities; the task scheduling module provides the scheduling and / or execution capabilities of privacy computing tasks; and the data resource management module provides local data access, de-identification, and / or authorization management capabilities.

[0187] In some implementations, the engine running module satisfies at least one of the following: each engine is run using a customized container; an independent engine is deployed in a namespace; and access to different types of storage media and tiered data storage management are supported.

[0188] In some embodiments, the task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein,

[0189] The task queue unit is used to store privacy computing tasks to be executed according to priority;

[0190] The executor management unit is used to manage local task execution threads.

[0191] The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules.

[0192] In some implementations, the data resource management module includes at least one of the following: a data access unit, a data desensitization unit, and an authorization management unit; wherein,

[0193] The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks;

[0194] The data desensitization unit is used to process sensitive fields in the data;

[0195] The authorization management unit is used to record authorization information for the data.

[0196] Please see Figure 5 , Figure 5 This is a schematic diagram of another communication device provided in an embodiment of this application. The communication device 500 can be a network device, or a device compatible with a network device, such as a processor, chip, or chip module; or it can be a terminal device, or a device compatible with a terminal device, such as a processor, chip, or chip module. The communication device 500 may include a processor 501. Optionally, the communication device 500 may further include a memory 502 and a computer program or instructions stored on the memory 502. Figure 5 (Not shown in the diagram). The processor 501 and memory 502 are interconnected. Optionally, the communication device 50 may further include a transceiver 503. The processor 501, memory 502, and transceiver 503 can be connected via a bus 504 or other means. The bus is in... Figure 5 The connections between other components are shown in bold lines only and are not intended to be limiting. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0197] The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. This embodiment does not limit the specific connection medium between the processor 501, memory 502, and transceiver 503. Memory 502 may include read-only memory and random access memory, and provides instructions and data to the processor 501. A portion of memory 502 may also include non-volatile random access memory.

[0198] Processor 501 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor; optionally, processor 501 can also be any conventional processor.

[0199] Transceiver 503 is used to receive or send data.

[0200] In one implementation, memory 502 is used to store computer programs or instructions; processor 501 is used to call the computer programs or instructions stored in memory 502.

[0201] In the embodiments of this application, the methods provided in the embodiments of this application can be implemented by running a computer program (including program code or instructions) capable of performing the steps involved in the above-described methods on a general-purpose computing device, such as a computer, which includes processing elements and storage elements such as a CPU, random access memory (RAM), and read-only memory (ROM). The computer program or instructions can be recorded on, for example, a computer-readable recording medium, loaded into the aforementioned computing device through the computer-readable recording medium, and executed therein.

[0202] Based on the same inventive concept, the communication device 500 provided in the embodiments of this application solves the problem in the same way and with the same beneficial effects as this application. Figure 1 The principles and beneficial effects of solving the problem in the illustrated embodiments are similar. Please refer to the implementation principles and beneficial effects of the method. For the sake of brevity, they will not be repeated here.

[0203] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0204] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0205] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, read-only optical discs (CD-ROMs), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Additionally, the ASIC can reside in a network device or terminal device. Alternatively, the processor and storage medium can exist as discrete components in the network device or terminal device.

[0206] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0207] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0208] The above detailed embodiments further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A privacy computing system, characterized in that, include: A first node and at least one second node, wherein the second node is used to execute privacy-preserving computation tasks locally based on the engine and task instructions distributed by the first node and to feed back the execution results to the first node; wherein... The first node includes: an engine management module, an engine registration and discovery module, and an operation and maintenance module; The engine management module is used to provide full lifecycle management capabilities for the engine. The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes; The engine registration and discovery module includes: a registration center unit and a service discovery proxy unit; wherein, the registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of the engines; the service discovery proxy unit is used to receive service query requests from the second node and send a list of engines that meet the service query requests to the second node; The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node; The second node includes: an engine operation support module, a task scheduling module, a data resource management module, and a resource situation awareness module; The engine operation module provides the engine operating environment and / or resource isolation capabilities; the task scheduling module provides the scheduling and / or execution capabilities of privacy computing tasks; and the data resource management module provides local data access, de-identification, and / or authorization management capabilities. The resource situation awareness module is used to monitor at least one of the hardware resources, network status, and engine status of the second node in real time, providing a basis for decision-making for the scheduling of the first node.

2. The privacy computing system according to claim 1, characterized in that, The engine management module includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit; Among them, the engine meta-information database unit is used to store engine information; The engine package storage unit is used to store the engine's operating resources; The version management unit is used to support parallel management of multiple versions of the same engine and records the iteration log of each engine version. The access control unit is used to manage the second node's access permissions to the engine.

3. The privacy computing system according to claim 1, characterized in that, The operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit; The node status monitoring unit is used to collect the hardware indicators and / or service status of the second node; The remote upgrade management unit is used to push the engine upgrade package to the second node; The fault repair unit is used to detect the abnormal state of the second node, and triggers the second node to perform a preset repair action after detecting the abnormal state.

4. The privacy computing system according to claim 3, characterized in that, The remote upgrade management unit is also used for at least one of the following: before pushing the engine upgrade package to the second node, confirming the remaining disk space of the second node, confirming that there are no running tasks, and verifying the compatibility between the current version of the engine and the target version; In the event of an engine upgrade failure, the failed engine in the second node is rolled back to the version before the upgrade.

5. The privacy computing system according to any one of claims 1 to 4, characterized in that, The engine operation module satisfies at least one of the following: each engine is run using a customized container; one independent engine is deployed in one namespace; and it supports access to different types of storage media and hierarchical data storage management.

6. The privacy computing system according to claim 1, characterized in that, The task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein... The task queue unit is used to store privacy computing tasks to be executed according to priority; The executor management unit is used to manage local task execution threads. The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules.

7. The privacy computing system according to claim 1, characterized in that, The data resource management module includes at least one of the following: a data access unit, a data desensitization unit, and an authorization management unit; wherein... The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks; The data desensitization unit is used to process sensitive fields in the data; The authorization management unit is used to record authorization information for the data.

8. The privacy computing system according to claim 1, characterized in that, The resource situation awareness module includes at least one of the following: an indicator acquisition unit, an anomaly warning unit, and a data reporting unit; wherein... The indicator collection unit is used to collect at least one of the following: hardware resource indicators, network status indicators, and engine status indicators of the second node. The anomaly warning unit is used to identify abnormal states during the operation of the second node and issue early warnings. The data reporting unit is used to report the content collected by the indicator collection unit to the first node.

9. A first node, characterized in that, The first node is the first node in the privacy computing system as described in claim 1, and the first node includes: an engine management module, an engine registration and discovery module, and an operation and maintenance module; The engine management module is used to provide full lifecycle management capabilities for the engine. The engine registration and discovery module is used to provide cross-node engine discovery and / or invocation capabilities between different second nodes; The engine registration and discovery module includes: a registration center unit and a service discovery proxy unit; wherein, the registration center unit is used to receive engine registration requests sent by the second node and / or maintain the status of the engines; the service discovery proxy unit is used to receive service query requests from the second node and send a list of engines that meet the service query requests to the second node; The operation and maintenance module is used to provide remote operation and maintenance and / or status management capabilities for the second node; The second node is the second node in the privacy computing system as described in claim 1.

10. The first node according to claim 9, characterized in that, The engine management module includes at least one of the following: an engine metadata library unit, an engine package storage unit, a version management unit, and a permission control unit; Among them, the engine meta-information database unit is used to store engine information; The engine package storage unit is used to store the engine's operating resources; The version management unit is used to support parallel management of multiple versions of the same engine and records the iteration log of each engine version. The access control unit is used to manage the second node's access permissions to the engine.

11. The first node according to claim 9, characterized in that, The operation and maintenance module includes at least one of the following: a node status monitoring unit, a remote upgrade management unit, and a fault repair unit; The node status monitoring unit is used to collect the hardware indicators and / or service status of the second node; The remote upgrade management unit is used to push the engine upgrade package to the second node; The fault repair unit is used to detect the abnormal state of the second node, and triggers the second node to perform a preset repair action after detecting the abnormal state.

12. A second node, characterized in that, The second node is the second node in the privacy computing system as described in claim 1. The second node is used to execute privacy computing tasks locally and feed back the execution results to the first node based on the engine and task instructions distributed by the first node in the privacy computing system. The second node includes: an engine operation support module, a task scheduling module, a data resource management module, and a resource situation awareness module; The engine operation module provides the engine operating environment and / or resource isolation capabilities; the task scheduling module provides the scheduling and / or execution capabilities of privacy computing tasks; and the data resource management module provides local data access, de-identification, and / or authorization management capabilities. The resource situation awareness module is used to monitor at least one of the hardware resources, network status, and engine status of the second node in real time, providing a basis for decision-making for the scheduling of the first node.

13. The second node according to claim 12, characterized in that, The engine operation module satisfies at least one of the following: each engine is run using a customized container; one independent engine is deployed in one namespace; and it supports access to different types of storage media and hierarchical data storage management.

14. The second node according to claim 12, characterized in that, The task scheduling module includes at least one of the following: a task queue unit, an executor management unit, and an exception handling unit; wherein... The task queue unit is used to store privacy computing tasks to be executed according to priority; The executor management unit is used to manage local task execution threads. The exception handling unit is used to monitor exceptions during task execution and execute retry or degradation strategies according to preset rules.

15. The second node according to claim 12, characterized in that, The data resource management module includes at least one of the following: a data access unit, a data desensitization unit, and an authorization management unit; wherein... The data access unit is used to access privacy data from multiple data sources and automatically identify the data format, providing a data foundation for subsequent privacy computing tasks; The data desensitization unit is used to process sensitive fields in the data; The authorization management unit is used to record authorization information for the data.

Images