Task processing method and device for multi-party security computing

Abstract

The embodiment of the invention provides a task processing technical scheme for multi-party security computing, based on a service-free computing architecture, in a task processing process, a service node respectively predicts resource quantities required by various subsequent types of instances through a time sequence data stream in the task processing process, so that the resource quantities required by various types of instances are predicted; and adjusting the resource configuration of the current instance according to the prediction result. Therefore, various types of instances can be regulated and controlled in real time, and the instance resource utilization rate is improved to the maximum extent under the corresponding task type and flow mode.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of joint secure computing technology, and in particular, to a task processing method and apparatus for multi-party secure computing. Background Art

[0002] With the information explosion and the development of artificial intelligence, multi-party joint computing has become a computing trend to fully utilize information. At the same time, protecting data privacy has become particularly important. Multi-party secure computing (MPC) is a distributed computing technology that enables multiple participants to jointly complete a task without disclosing their private data. Through MPC, participants can collaborate on data processing, data analysis, and decision-making without worrying about data leakage or privacy violations. This approach has practical applications in many scenarios, such as joint data analysis, privacy-preserving machine learning, and secure voting systems. In MPC, data encryption methods such as differential privacy, obfuscated circuits, secret sharing, or homomorphic encryption are often used to achieve joint computing while protecting data privacy.

[0003] However, multi-party secure computation technology faces numerous challenges in practical application, particularly in terms of computational efficiency, the number of supported participants, and resource management. Conventional technical solutions have mostly focused on improving computational efficiency and supporting a larger number of participants, and while these solutions have achieved some success, they suffer from poor scalability and availability. For example, multi-party secure computation systems typically require a fixed number of pre-configured resources, resulting in poor scalability and difficulty adapting to fluctuating traffic conditions. When traffic surges, fixed resources may be insufficient to support computational demands, leading to degraded system performance. Conversely, when traffic decreases, excessive pre-configured resources can be wasted. Furthermore, availability is poor because, within a decentralized architecture, computing nodes require a constant network connection. Participants in a multi-party secure computation system may come from different regions and industries. Without guaranteed constant online availability, node disconnections can lead to frequent system congestion or even crashes. Therefore, designing and implementing a system that can elastically scale to meet dynamically changing computational demands has become a key challenge facing multi-party secure computation systems. Summary of the Invention

[0004] One or more embodiments of this specification describe a task processing method and apparatus for multi-party secure computing to solve one or more problems mentioned in the background art.

[0005] According to a first aspect, a task processing method for multi-party secure computing is provided, the method being implemented based on a serverless computing architecture, the serverless computing architecture comprising a plurality of service nodes and a plurality of database nodes, the service node being used to, upon receiving a task request sent by a task requester, parse the task request at least one service node, and perform task processing with at least one database node through at least one interaction cycle, obtaining a task processing result and providing it to the task requester; in a single interaction cycle, the service node completes relevant operations in the task through at least one type of instance; for a single type of instance, the service node adjusts the amount of resources allocated to it in the following manner: obtaining a time series data stream of the current type instance during the current task processing process, the time series data stream comprising historical instance indicators of the current type instance; predicting the amount of instance resources within a predetermined time period based on the time series data stream; and performing resource configuration for the current type instance within a predetermined time period based on the instance resource amount.

[0006] In one embodiment, the operations performed by the service node through the instance include at least one of the following: parsing, calculation, and assignment of subtasks; the instance metrics include at least one of the following: the instance's processor quota, memory quota, call latency, throughput, and the amount of data to be processed in the message queue or event source; the task request, subtask data in the interaction cycle, and the task processing results are all transmitted in the form of files to a shared cloud data pipeline.

[0007] In one embodiment, the historical instance indicators are captured at predetermined time intervals via the monitoring interface of the cloud platform where the service node is located and stored in a time series database. The time series data flow is: instance indicator data obtained from the time series database according to a predetermined time window or data volume window for the current type of instance.

[0008] In one embodiment, predicting the instance resource amount within a predetermined time period based on the time series data stream includes: extracting instance features from the time series data stream, the instance features including at least one of the following: processor usage, memory usage, single function call duration, error rate, and amount of data to be processed in a message queue or event source of a single instance; processing the instance features through a pre-trained resource prediction model, and determining the instance resource amount within a predetermined time period based on the output of the resource prediction model, the instance resource amount including at least one of memory quota, processor quota, and concurrency within the instance.

[0009] In a further embodiment, the resource prediction model includes one of a long short-term memory network LSTM, a gated recurrent unit GRU network, and a temporal encoder based on an attention mechanism; the resource prediction model updates parameters in the form of offline training and online fine-tuning, and the training samples used for parameter updating correspond to historical instance indicators and resource quantity labels as feature data. In the offline training stage, the label is determined by the mean of multiple samples of a single type of instance, and the historical instance indicator is the instance indicator of the corresponding type of instance before the multiple samples used to determine the label. In the online fine-tuning stage, the previous prediction result is supervised incremental training using the actual collected resource usage data as a label.

[0010] In one embodiment, the resource configuration for the current type instance within a predetermined time period based on the instance resource quantity includes: comparing the predicted instance resource quantity with the current configuration of each current instance to determine whether the two are consistent; the current configuration is the instance resource configuration of the current type instance during the previous execution; determining the resource configuration for the next execution of the current type instance based on the comparison result; wherein, if the comparison result is consistent, continuing the current configuration, and if the comparison result is inconsistent, adjusting the current configuration to make it consistent with the predicted instance resource quantity.

[0011] In one embodiment, the resource configuration for the current type instance within a predetermined time period based on the instance resource quantity includes: adjusting the resource configuration of the current type instance according to a pre-set smoothing strategy, the smoothing strategy including not adjusting the resource configuration when at least one of the following non-adjustment conditions is met: the time interval with the previous resource configuration adjustment is less than the cooling-off period, and the difference between the currently configured resource quantity and the predicted instance resource quantity is less than a preset step size.

[0012] In one embodiment, the method further includes: for the current type of instance, the service node controls the instance life cycle in the following manner: predicting the time interval between its next task and the end time of the current task to obtain a predicted time interval; comparing the predicted time interval with the cold start duration of the current type of instance; and deciding whether to destroy the instance based on the comparison result.

[0013] In a further embodiment, the prediction time interval is performed by a pre-trained time prediction model, and the input data of the time prediction model includes task type and task parameters, the task type includes one of query subtask, horizontal modeling subtask, and vertical modeling subtask, and the task parameters include at least one of the following: task operation type, model parameter magnitude, and the amount of data input for a single calculation; the time prediction model is a lightweight multi-layer perceptron or tree model.

[0014] In a further embodiment, the method also includes: for a single instance, when the next task arrives, calculating the actual time interval between the arrival time of the next task and the end time of its previous task; comparing the gap between the actual time interval and the predicted time interval; determining the model loss of the time prediction model based on the comparison result, and using the model loss to fine-tune the time prediction model online.

[0015] According to a second aspect, a task processing device for multi-party secure computing is provided, which is arranged in a service node of a serverless computing architecture, wherein the serverless computing architecture includes multiple service nodes and multiple database nodes. The service node is configured to, upon receiving a task request from a task requester, perform at least one interaction cycle with at least one database node to perform task processing based on parsing the task request, and obtain a task processing result and provide it to the task requester.

[0016] In a single interaction cycle, the service node completes relevant operations in the task through at least one type of instance; for the current type of instance, the service node adjusts the amount of resources allocated to it through the device; the device includes:

[0017] In a single interaction cycle, the service node completes relevant operations in the task through at least one instance; for a single type of instance, the service node adjusts the amount of resources allocated to it through the device; the device includes:

[0018] an acquiring unit configured to acquire a time series data stream of the instance of the single type during the current task processing, wherein the time series data stream includes historical instance indicators of the instance of the corresponding type;

[0019] a prediction unit configured to predict the instance resource quantity of the single type instance within a predetermined time period based on the time series data stream;

[0020] An alignment unit is configured to perform resource allocation for the single type within a predetermined time period based on the instance resource quantity. In one embodiment, the apparatus further includes an instance lifecycle control unit configured to:

[0021] For a single type of instance, the instance lifecycle is controlled in the following way: the time interval between its next task and the end of the current task is predicted to obtain a predicted time interval; the predicted time interval is compared with the cold start duration of the single type of instance; and a decision is made on whether to destroy the instance based on the comparison result.

[0022] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method according to the first aspect.

[0023] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0024] Through the methods and devices provided in the embodiments of this specification, based on a serverless computing architecture, during task processing, service nodes use the time-series data streams from the task processing process to predict the resource requirements of various subsequent instance types and adjust the resource allocation of the current instance based on the prediction results. This allows for real-time control of various instance types, maximizing instance resource utilization for the corresponding instance type and traffic pattern.

[0025] In an optional embodiment, the instance lifecycle management can also be performed by predicting the time interval between the end time of the current task and the time of the next task, judging the relationship between the time interval and the cold start duration, and managing whether the instance is destroyed. This improves the problem of slow task response in high-frequency task scenarios in the time-triggered mode of use-and-destroy. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0027] Figure 1 A schematic diagram illustrating the implementation architecture of multi-party secure computation is shown;

[0028] Figure 2 A schematic diagram showing a serverless computing architecture to which this specification applies;

[0029] Figure 3 A schematic diagram of a task processing flow for multi-party secure computing according to one embodiment of this specification is shown;

[0030] Figure 4 A schematic diagram of the process architecture for adjusting the amount of resource configuration for an instance is shown in a specific example;

[0031] Figure 5 A schematic diagram of a process architecture for controlling the life cycle of an instance is shown in a specific example;

[0032] Figure 6 A schematic block diagram of a task processing device for multi-party secure computing according to one embodiment of the present specification is shown. DETAILED DESCRIPTION

[0033] The technical solution provided in this specification is described below in conjunction with the accompanying drawings.

[0034] First, some terms that may be used are explained.

[0035] The multi-party secure computing architecture usually includes two modes: one with a server and one without a server. Figure 1 As shown in the figure. Without a service provider, multiple participants exchange data with each other, protecting data privacy through agreed-upon encryption methods. Business processing results can be in plaintext or ciphertext, shared among the participants or held by a single participant. With a service provider, the service provider is typically a trusted or semi-trusted third party that can assist with operations such as data aggregation, complex calculations, and auxiliary parameter generation. This will not be discussed in detail here.

[0036] Serverless computing is a new cloud computing paradigm in which cloud service providers dynamically manage resources. Users no longer need to worry about managing the underlying infrastructure; they simply write and upload their code, and the cloud platform automatically provides an execution environment and allocates resources on demand. This is a function-as-a-service computing paradigm that operates in an event-driven manner. When an event occurs, function instances (such as processes and the number of virtual machines) are automatically generated and user-configured resources are allocated. When the function completes, the instance is automatically destroyed and resources are reclaimed. This is not serverless, but server-free, achieving function-as-a-service.

[0037] Multi-party secure computation can be generally categorized into query and modeling tasks based on task type. Query tasks often involve joint queries and statistical computations across databases owned by multiple data owners, while modeling tasks often involve federated training of machine learning models based on data from multiple data owners.

[0038] Conventional solutions for implementing query tasks include Conclave, OpenHuFu, and Starling. Conclave, based on secret-sharing encryption technology, supports joint computation without mutual visibility of participant data. It typically supports up to three participants and does not support scalability of system resources. OpenHuFu, based on secret-sharing encryption counting, supports joint computation without mutual visibility of user data. It performs distance counting, distance queries, and kNN (k-nearest neighbor) queries on all participant data (spatial objects). This solution is a further optimization of Conclave, minimizing the need for computation in ciphertext, improving computational efficiency, and supporting a larger number of participants. Starling, a data query system based on AWS serverless computing and S3 storage, queries and analyzes data stored in AWS S3 storage. It can achieve elastic resource scalability by controlling the number of serverless computing function instances. However, Conclave and OpenHuFu generally do not support elastic scalability of computing resources. Starling is data-centric, which does not conform to the multi-party secure computing principle of "data never leaves the data owner" and generally does not consider data privacy during the computation process.

[0039] Conventional modeling task solutions include FedML and lambdaML. FedML is an open-source federated system computing framework that implements modeling tasks for multi-party secure computing. This solution can use encryption technologies such as differential privacy and homomorphic encryption to jointly train machine learning models among various participants while ensuring that user data does not leave the local machine and is invisible to each other. However, the resource configuration of this solution is usually fixed, and long connections between nodes must be maintained. Node disconnection may cause system blockage or interruption. LambdaML is a distributed machine learning system based on AWS's serverless computing service. It uses serverless computing functions to perform local training tasks for each node, which can achieve elastic scaling of resources. However, this solution is designed for horizontal data structures and is generally not suitable for federated modeling tasks under vertical data structures.

[0040] Thanks to the unique characteristics of serverless computing architecture, the number of instances can be adjusted based on traffic changes, achieving elastic resource scalability, effectively addressing traffic fluctuations, and improving the system's resource utilization efficiency and overall performance. Furthermore, on-demand expansion and billing models help reduce operating costs, making multi-party secure computing technology more feasible and economical in practical applications.

[0041] In view of this, this specification provides a scalable multi-party secure computing architecture based on serverless computing. Figure 2 The figure shows the overall structure of the architecture. Figure 2In the system, the database nodes of each participant and the service nodes running in the serverless computing environment are connected through the shared cloud data pipeline. The user, as the task requester, can be any participant in the multi-party secure computing or any network user who provides services to the participants through the multi-party secure computing architecture. Figure 2 The system architecture shown is described in detail.

[0042] The task interface is provided by the cloud service provider. Users can use the task interface to select secure computing types based on multi-party databases, such as query or modeling (corresponding to ①), set relevant parameters and submit the task (corresponding to ②), and obtain the task results through the task interface after the task is completed (corresponding to ⑧).

[0043] The service node, deployed in the serverless computing environment of the cloud platform, is responsible for initializing and parsing tasks (corresponding to step ③). It then generates subtasks (corresponding to step ④), schedules the database nodes involved in the computation, and distributes the subtasks to the database nodes via a shared cloud data pipeline. Furthermore, it collects subtask results from the database nodes (corresponding to step ⑦), aggregates these subtask results, and obtains the complete task result, which is then fed back to the user through the task interface (corresponding to step ⑧). Typically, the collected subtask results are in encrypted form, and the service node performs aggregate calculations in this encrypted form, thereby protecting the privacy and security of user data.

[0044] Database nodes can be deployed in serverless computing environments, rented servers on cloud platforms, or private servers to enhance the applicability of multi-party secure computing systems. Database nodes can be of various node types, such as physical nodes, logical nodes, single nodes, multiple nodes, and so on. The database node connects to the local database and performs local data query tasks or model training tasks according to the subtasks assigned by the service node (corresponding to ⑤). After the database node queries or calculates based on private data, it can use the encrypted public key obtained from the service node to encrypt the data and return the subtask results to the service node through the shared cloud data pipeline (corresponding to ⑥). Here, the subtask results can be encrypted using homomorphic encryption methods. Homomorphic encryption supports mathematical operations on ciphertext, effectively protecting data privacy and enabling smooth operations.

[0045] Database nodes can be deployed on cloud servers or private clusters, or on private computers, devices, servers, etc. They can interact with service nodes through active monitoring. Database nodes correspond to various data holders and can serve as Figure 2 The user shown uploads a task request as a trigger event and interacts with the service node in an event-driven manner. The user can also interact with the service node as a participant in multi-party secure computing to complete the task requested by the user.

[0046] Conventional solutions use persistent connections to achieve data communication between different nodes in a cluster. However, in a serverless system, stateless functions cannot establish persistent connections. Therefore, in the scenario of multi-party database secure computing, the indirect communication method using shared storage cannot guarantee that the data between participants is invisible to each other. In order to strengthen data protection at the communication level of the serverless system, Figure 2 A shared cloud data pipeline is set up in the provided architecture.

[0047] Data pipeline can be understood as a path for data to pass and be distributed. It is easy to understand that data in multi-party secure computing can have various data sources, such as API, SQL, NoSQL databases and files, but data preparation tasks are usually completed by researchers, data engineers and other groups, and these data may not be directly matched to specific business needs. Data pipeline can combine exploratory data analysis and defined business needs to determine the type of data processing, and after appropriate filtering, merging and summarizing of the data, store and display the data for use. Figure 2 Under the system architecture shown, information such as task requests, subtasks, task results (i.e., task processing results) can all be sent to the shared cloud data pipeline in the form of files.

[0048] A shared cloud data pipeline can be set up on the cloud service side to collect raw data from various data sources of each participant, and then store it in a cloud database or file system (such as an OSS object storage system) for analysis. It can be shared by the service provider and each participant. In this way, in order to protect data privacy, in some optional implementations, the shared cloud data pipeline can perform permission control based on identity authentication. For example, when a database node is connected to the system, it can be assigned a RAM (random access memory) identity tag to complete the verification of reading and writing the shared cloud data pipeline.

[0049] In one embodiment, to achieve more fine-grained permission control, the shared cloud data pipeline can be divided into different functional spaces, such as the system task space and the user interaction space. These spaces can be accessed using corresponding identity tags. Optionally, to protect data privacy within the shared cloud data pipeline, communication between service nodes and database nodes adopts a minimum authorization strategy. For example, each database node is granted only write permission in the subtask result space, not read permission, ensuring that subtask computation results are invisible to each other. Each database node is granted only read permission in the subtask publishing space on the service node, not write permission, preventing database nodes from maliciously modifying the published subtask files and disrupting normal system operation, causing task failures. A subspace is created for the requesting user (task requester), with read / write permissions limited to the system and the user. This ensures that task computation results are visible only to the requesting user, achieving user-level isolation between multiple users and preventing unauthorized users from stealing data. Furthermore, a number of other mechanisms are discussed.

[0050] Because serverless computing is event-driven, server-side functions are services (the specific executed function is an instance), and functions are created and used immediately, and destroyed upon task completion. Therefore, it is impossible to maintain a long-term, effective connection between service nodes and database nodes. Therefore, in some optional implementations, database nodes can proactively upload state files containing timestamps to a shared cloud data pipeline at predetermined intervals. Service nodes read the state files and determine the online status of database nodes. Through this state file-based node management, service nodes can proactively discard offline database nodes when responding to task requests, avoiding long wait times.

[0051] Thus, in one embodiment, the service node can also perform status management on loose nodes. The loose nodes here can be user terminals, database nodes, etc. For example: the service terminal detects the online status of the database node by reading the time-stamped status file (also called the heartbeat packet file) uploaded by the database node; selects the database nodes participating in the single multi-party secure computation from the online database nodes, and uploads the selection results to the shared storage space; and so on. For different tasks, the selection method of the database nodes can be different. In query tasks, all participating nodes specified by the user can be selected from the online database nodes, and the selection results are published in the form of subtask files. In modeling tasks, the federated modeling tasks under the horizontal data structure can set the sampling rate, and randomly select the database nodes corresponding to the predetermined sampling rate from the online database nodes to participate. The federated modeling tasks under the vertical data structure can select all online database nodes, or select some online database nodes after removing duplicate features, or determine the online database nodes based on the feedback on whether the database nodes participate. I will not go into details here.

[0052] based on Figure 2 The architecture shown can execute joint data analysis tasks, joint modeling tasks, etc. Specifically, the execution process of a task may include the following steps: the task requester (such as Figure 2 The user (shown in the figure) submits a task request, which is sent as a file to the shared cloud data pipeline. The cloud service node initiates the task based on the task request and exchanges data with the database node through the shared cloud data pipeline for at least one round. The service node obtains the task result and feeds it back to the shared cloud data pipeline as a file. The task result recipient obtains the task result from the shared cloud data pipeline. The user who requests the task can be any network user or one of multiple database nodes, without limitation.

[0053] During a single interaction round between a cloud service node and a database node, the cloud service node determines the database nodes participating in the current task (which may include the node that sent the task request) and determines the subtasks to be executed for each database node. These subtasks are then provided to the shared cloud data pipeline in the form of files. Each database node then retrieves its local subtasks from the shared cloud data pipeline, executes the subtasks using its local private data, and sends the encrypted subtask results to the shared cloud data pipeline in the form of files. The cloud service node then retrieves the encrypted subtask results from the shared cloud data pipeline. This process continues for at least one more interaction round between the cloud service node and the database node until the cloud service node obtains the final encrypted task results.

[0054] Upon receiving a task request, the cloud service node and the database node begin the first round of interaction. The cloud service node initializes the task based on the task request, including initializing the dataset and functions. This initialization process may include, but is not limited to, at least one of the following: determining the data tables to be used, determining the features to be used, determining the functions or model structures to be used, and determining possible participants (i.e., database nodes).

[0055] For example, in a data query task, the request is "Query the number of park visitors in all cities last year." This task can specify: the data to be queried, such as the number of visitors to each city park per month or day last year; the data table to be queried, such as a statistical table of park visitor information for each city park; possible participants, such as each city park (a cloud-connected computing device); and the functions to be used, such as query functions, data retrieval functions, or count and sum functions. Based on the initialization results, subtasks can be generated for each database node, such as a subtask that uses a query function to perform data queries. Each database node then retrieves subtasks related to local data (such as queries, data retrieval, and counting) from the shared cloud data pipeline. After completing the subtask processing in the locally connected database and obtaining the subtask results, the node returns the subtask results in encrypted form to the shared cloud data pipeline as a file. The service node obtains the subtask results from the shared cloud data pipeline, completes data aggregation (such as summation), and determines whether to generate a subtask based on the task requirements, that is, whether the final task result has been obtained.

[0056] It's worth noting that when a service node assigns a subtask to a database node, it can establish a system task space that corresponds one-to-one with each database node and send a subtask request file for a single database node to the corresponding system task space, allowing the corresponding database node to retrieve the subtask request file from the corresponding system task space. The subtask request file includes various data and result information required to process the subtask, such as the database node identity tag, the user's cloud database connection information, the query data feature column names, and query operation information. The database node parses and executes the subtask based on the subtask request file, uploading the ciphertext of the subtask result in the form of a file to the corresponding system task space, from which the service node can retrieve the file containing the ciphertext of the subtask result.

[0057] In a possible embodiment, data between database nodes may also need to be aligned. This can be done, for example, in federated learning where data is vertically distributed. In this case, each database node holds different aspects of data about a broad range of data subjects (e.g., users). For example, if the data subject is a user identified by a mobile phone number or ID number, and one database node holds consumption-related feature data, while another holds location-based commuting feature data, data alignment is necessary to jointly complete the task.

[0058] At this point, the cloud service node can generate data sub-alignment tasks for each database node based on the initialized dataset and pass these sub-alignment tasks to the shared cloud data pipeline in the form of files. Each database node then retrieves the sub-alignment tasks from the shared cloud data pipeline, performs a Privacy Required Intersection (PSI) operation on each other, completes the data alignment, and feeds the alignment results back to the shared cloud data pipeline in the form of files in ciphertext form. After receiving the alignment results, the cloud service node can continue with task allocation and processing.

[0059] It can be understood that the service node can usually be connected to the database nodes corresponding to various data holders. Therefore, in a specific task, there may also be a database node sampling problem. In some embodiments, the task request sent by the user can include a specified data holder identifier, such as limiting data holders A, B, and C, and the service node can determine the database node corresponding to the current task based on the task request. In some embodiments, the task request sent by the user only includes the task content, and the service node can determine which database nodes are needed based on the task content. For example, in the example above, "Query the number of visitors to the city's parks last year", the service node can determine the data holder containing the information on the number of visitors to the city's parks in the connected database node based on the city to which the requester belongs, and thus determine the corresponding database node as a participant in the current task.

[0060] In addition, during the execution of a task, a single interaction cycle between a service node and a database node may also be subject to database node sampling. For example, in a federated learning scenario where data is horizontally distributed, if there are many database nodes or some database nodes are offline, the database nodes can be sampled to determine the database nodes for a single interaction cycle from the online database nodes. For example, if there are many database nodes, a predetermined number of database nodes can be randomly sampled. In complex federated learning scenarios, for database nodes with consistent data types (such as multiple database nodes that are locally horizontally distributed), the database nodes for each interaction cycle can be determined by sampling the database nodes.

[0061] In a possible embodiment, the service node also determines whether the subtask results fed back from the database node need to be aggregated. If aggregation is required, the data can be aggregated in an encrypted state to protect data privacy.

[0062] In some implementations, database nodes can also upload complex, costly multi-party joint operations in encrypted form to a shared cloud data pipeline, allowing service nodes to retrieve the encrypted data and perform auxiliary calculations in an encrypted state. Examples of complex operations include, but are not limited to, at least one of the following: division, square root, sorting, activation functions (such as sigmoid), and so on.

[0063] The above reference Figure 2 The serverless computing architecture under the technical concept of this specification is described. It is understandable that in the serverless computing architecture, computing is implemented in an event-driven mode, and the number of function instances can be dynamically adjusted (horizontally scaled) according to changes in user request traffic, achieving elastic scaling.

[0064] For service nodes, the number of function instances can be dynamically adjusted to achieve scalability when receiving task requests, triggering tasks, and interacting with database nodes during each interaction cycle. However, instance resource configurations (such as memory size and number of CPU cores) are typically statically preset. For example, each function instance is uniformly allocated 4GB (4 gigabytes) of memory, 2vCPUs (2 virtual processor cores), and a concurrency limit of 1 (a maximum of one process or request is allowed to run concurrently within an instance). This coarse-grained resource allocation scheme can lead to problems such as uneven resource utilization: Different task types (such as intensive compute and low-latency I / O) have significantly different resource requirements. Static configuration can result in some instances having redundant memory and fully loaded CPUs, or vice versa, with fully utilized memory and underutilized CPUs. Complex tasks (such as encryption aggregation and model training) can experience resource shortages or delays in individual instances due to varying input resources, while simple tasks (such as count queries) can suffer from unnecessary resource overload and waste.

[0065] In view of this, the technical concept provided in this specification can further dynamically adjust the amount of resources allocated to each instance through real-time monitoring of data, thereby realizing elastic resource configuration based on serverless computing to cope with dynamically changing computing needs.

[0066] Figure 3 This section illustrates a task processing flow for multi-party secure computing according to one embodiment of this specification. This task processing flow is based on serverless computing, and its execution entity can be any computer, device, or server with sufficient computing power. Specifically, it can be a service node in a serverless computing architecture.

[0067] As can be understood, a serverless computing architecture can include multiple service nodes and multiple database nodes. When a task requester sends a task request to a service node, at least one service node parses the task request and processes the task with at least one database node through at least one interaction cycle, obtaining the task processing result and providing it to the task requester. In a single interaction cycle, the service node completes the relevant operations in the task through instances of at least one type. Figure 3 Taking the case of adjusting the amount of resources allocated to an instance of a single type (such as the current type) by a service node in a single interaction cycle as an example, an embodiment of the technical concept of this specification is described.

[0068] like Figure 3 As shown, the task processing flow for multi-party secure computing may include the following steps: Step 301, obtaining the time series data stream of the current type of instance during the current task processing process, the time series data stream including the historical instance indicators of the current type of instance; Step 302, predicting the instance resource quantity within a predetermined time period based on the time series data stream; Step 303, performing resource configuration for the current type of instance within a predetermined time period based on the instance resource quantity.

[0069] First, in step 301, the time series data flow of the instance of the current type during the current task processing is obtained.

[0070] As you can understand, in a serverless computing architecture, functions are services, and instances are the specific functions that are executed. Different functions have different instance types. For example, an addition function executes an addition instance, a multiplication function executes a multiplication instance, and so on. The current type of instance can be any type of instance. Examples of instance types include addition instances and normalization instances. Depending on data traffic, a single function can correspond to one or more instances. For example, under high request volume, multiple addition instances can be executed simultaneously for a single addition calculation.

[0071] As the name suggests, a time series data stream is a sequence of data arranged in chronological order. In this specification, for the purpose of achieving elastic resource configuration for instances, this data can include historical instance metrics from current or past task processing. Historical instance metrics are metrics related to instances that have already been executed during the current task. Time series data streams can be collected by instance type.

[0072] Instance metrics may include, but are not limited to, at least one of the following: a single instance's processor quota (e.g., number of virtual cores) and usage (e.g., percentage), memory quota (bytes) and usage (percentage or bytes), call latency (time per call, in milliseconds), error rate (ratio of call errors), throughput (amount of data processed per unit time), and pending data in message queues or event sources. Instance metrics can be captured by the native monitoring interface of the cloud platform where the service node resides at predetermined intervals, such as 5–10 seconds.

[0073] The historical instance indicators may be instance indicators corresponding to historical instances that have been executed. The historical instances corresponding to a single type instance (such as recorded as the current type instance) may be instances of that type, for example, all are addition instances, etc. For the current type instance, various reasonable methods may be used to obtain the corresponding historical instance indicators as a time series data stream. In one embodiment, the historical instance indicators corresponding to the current type instance may include indicator data for all instances of the same type in the current task. In another embodiment, the historical instance indicators corresponding to the current type instance may include instance indicators obtained according to a predetermined time window or data volume window for instances of the same type in historical and current tasks, such as a time window of 1 day and a data volume window of 10 items.

[0074] In this way, the corresponding time series data stream can be obtained for each current type instance in the current task processing process.

[0075] Then, according to step 302, the instance resource quantity within a predetermined time period is predicted based on the time series data flow.

[0076] For the current instance type, the required instance resource amount can be predicted using the corresponding time series data stream. This prediction process can be performed using pre-built mappings or pre-trained resource prediction models, but this is not limited here. The required instance resource amount may include, but is not limited to, at least one of the following: memory quota, CPU quota, and the number of concurrent users within the instance.

[0077] Here, the current instance is the instance currently to be executed. It can be the instance to be executed within a subsequent scheduled time period, or it can be the instance to be executed immediately. The subsequent scheduled time period is, for example, 2 seconds, 5 seconds, etc.

[0078] When making predictions through a pre-built mapping relationship, a mapping relationship between the predetermined conditions satisfied by historical instance indicators and the actual required instance resource quantities can be set in advance. When the historical instance indicators meet a single predetermined condition, the actual required instance resource quantities are determined according to the corresponding mapping relationship.

[0079] When using a pre-trained resource prediction model for prediction, sample data can be collected in advance to train the resource prediction model. Sample data can be obtained by monitoring historical time series data streams. Each sample data item is labeled with the instance resource consumption of a single type of instance at a single moment, along with feature data extracted from the historical time series data streams prior to that moment.

[0080] As a specific example, historical data can be obtained through the cloud platform's monitoring tool and feature extraction can be performed to form training samples. In the process of obtaining historical data, the cloud platform's native monitoring interface can be used to collect the following instance indicators of various types of instances at predetermined time intervals (e.g., 5 minutes): CPU usage of a single instance (in percentage), memory usage (in megabytes), time taken for a single function call (in milliseconds), error rate, and the amount of data to be processed in the message queue or event source; the data is written to a time series database (TSDB) as historical data. Optionally, the data can be cleaned and normalized before being written to the time series database. According to some optional implementations, during the sample construction process, a sliding window of a predetermined size (e.g., N = 6 samples) can be used to extract the mean, variance, maximum / minimum value, and other features of the indicator values ​​of each instance within the sliding window. The variance, maximum / minimum value, etc. can capture short-term fluctuation features. In some embodiments, the instance indicators before the sliding window can be used as historical instance indicators of the training sample, the mean corresponding to the sliding window can be used as the label of the training sample, and the variance can be used to measure the availability of the label. In some embodiments, the label data can be filtered by variance, and label data with smaller fluctuations (e.g., smaller variances tend to have smaller fluctuations) can be selected to construct training samples. In a specific example, for the amount of resources predicted by the resource prediction model, the availability of the prediction results can be evaluated through a sliding window. Optionally, for loads with periodic characteristics (such as daily business peak hours), "timestamp period coding" and the like can be added as auxiliary features. The end of the sliding window is adjacent to the instance resource consumption of the instance as label data. It is worth noting that the above training samples are constructed separately according to the instance type, that is, a single training sample usually involves one type of instance. Training samples corresponding to various types of instances can be used to train the same resource prediction model.

[0081] Resource prediction models can be constructed using various networks with time series characteristics. For example, for shorter-term predictions (such as 10 seconds), lightweight networks such as recurrent neural networks such as LSTM and GRU networks can be used. In prediction scenarios with a large number of feature dimensions (such as greater than the predetermined dimension), time series encoders based on attention mechanisms (such as Transformer) can be used.

[0082] According to one possible design, the resource prediction model can be updated with parameters in the form of offline training and online fine-tuning to adapt to actual application scenarios. For example, historical data can be extracted from the TSDB according to a predetermined time period (such as daily) to construct a training set and a validation set. The model parameters are adjusted through cross-validation, with the training set trained until convergence and the validation set validated. This is until the resource prediction model meets the predetermined conditions in the validation set (such as the accuracy reaches a predetermined value, or the F1 score is greater than a predetermined value), resulting in a resource prediction model that can be loaded online. During the online fine-tuning phase, delayed feedback can be combined to perform supervised incremental training on the prediction results of the previous cycle using the actual collected resource usage data to improve the adaptability of online business.

[0083] Next, in step 303 , resource configuration is performed for the current type instance within a predetermined time period based on the instance resource quantity.

[0084] Here, it is possible to determine whether the predicted instance resource amount is consistent with the current configuration of each current type instance based on the comparison between the two. Generally, in the case of consistency, the resource configuration of the current type instance may not be adjusted, that is, the previous instance resource configuration is continued. In the case of inconsistency, the resource configuration of the current type instance may be adjusted to the predicted instance resource amount, that is, the resource configuration of the current type instance is adjusted to be consistent with the predicted instance resource amount. Among them, the current configuration of the current type instance may be the instance resource configuration of the current type instance during the previous execution. In a more specific example, a predetermined time period (such as 6 seconds, etc.) is regarded as the adjustment period of the resource configuration, and the current configuration can be understood as the resource configuration of the current type instance in the current cycle (or the last cycle that has been executed), and what is adjusted is the resource configuration of the next cycle.

[0085] The predicted instance resource amount may include at least one of the CPU, memory quota, and concurrency number of a single instance in various types of instances, and the resource configuration adjustment of the current instance may also include at least one of the CPU, memory quota, and concurrency number of the instance. In an optional embodiment, the resource configuration adjustment may adopt a smoothing strategy to avoid system "jitter" caused by frequent adjustments. The smoothing strategy may include setting at least one of the following for the scaling operation: a cool-down time, that is, an adjustment time interval (such as 10 seconds, etc.). If the time interval is less than the cool-down time, the resource configuration adjustment may not be performed; a minimum step size, used to control the adjustment amplitude. If the adjustment amplitude (the resource configuration amount of the current instance and the predicted instance resource amount) is less than the minimum step size, no adjustment is required; and so on.

[0086] refer to Figure 4As shown, as a specific example, the dynamic adjustment process may include: monitoring 401, the monitoring component collects instance resource configuration and resource usage data according to a predetermined detection cycle and writes it to TSDB; triggering 402, a timer trigger (or asynchronous event) calls the prediction service to obtain the predicted value of the instance resource quantity in the next time window; decision 403, using the automatic decision module to compare the predicted instance resource quantity with the current configuration of the corresponding type of instance to generate a resource adjustment command; execution 404, according to the resource adjustment command, the cloud platform resource configuration interface is called by the operation and maintenance controller to adjust the current configuration of various types of instances; feedback 405, after adjusting the current configuration of the instance, delay 1-2 monitoring cycles, re-evaluate the resource and load matching degree, and iterate the adjustment.

[0087] Compared with static resource configuration, real-time adjustment of instance configuration during task execution can maximize the use of instance resources based on task type and traffic pattern, achieving more efficient resource utilization.

[0088] In addition, when the serverless computing architecture adopts the "event-driven" mode, the interaction rounds of a single subtask between the service node and the database node are repeated. After the service node completes a subtask, the function instance is uniformly destroyed and restarted when it is next triggered. Although this method simplifies resource management, it may also have performance bottlenecks in some scenarios. For example, in short-term intensive interaction scenarios, such as longitudinal modeling (Split Learning), each database node quickly completes the calculation of a batch of training samples locally and sends the intermediate results to the shared cloud data pipeline. The service node obtains the intermediate results from the shared cloud data pipeline. Due to factors such as cold start and network communication delays, additional delays will be introduced due to the restart after the instance is destroyed, reducing the overall throughput. For another example, in high-frequency small task scenarios, the function execution time is much shorter than the cold start time (usually the execution time is tens of milliseconds, while the cold start takes hundreds of milliseconds). Multiple destruction and restart may generate repeated initialization overhead, making lightweight tasks execute slower.

[0089] In view of this, in a possible design, for a single type of instance (still recorded as the current type), the service node can predict the time interval between its next task and the current moment, and compare the predicted time interval with the instance's cold start duration, thereby making a dynamic decision on whether to destroy the instance based on the comparison result. Generally, if the predicted time interval is less than the cold start duration, the current type instance can be retained ("keep-alive mode"), actively waiting for new triggers, eliminating the restart overhead; conversely, if the predicted time interval is greater than the cold start duration, the current instance is destroyed ("saving mode") to free up resources and reduce costs.

[0090] Among them, for the current type instance, the time interval between the next task and the end time of the current task can be predicted by the task type and task parameters. Among them, the task type is usually the type of the task as a whole, for example, it can be one of the following: "query subtask", "horizontal modeling subtask", "vertical modeling subtask", etc. Task parameters can be specific details parameters involved in the task execution process, for example, they can include but are not limited to at least one of the following: task operation type (such as addition sum, mean avg, convolutional neural network training CNN Train), model parameter magnitude (such as 10 3 , 10 4 etc.), the amount of data input for a single calculation (such as 100 megabytes, etc.), etc.

[0091] The predicted time interval can be implemented through a time prediction model or according to a pre-set mapping relationship. When implemented through a mapping relationship, the mapping relationship between various task data combinations (such as a combination of specific task types and specific task parameters, etc.) and time intervals can be pre-set, and the corresponding time interval can be matched based on the currently detected task data combination. When implemented through a time prediction model, task features can be extracted from the task data, and the task features can be input into the time prediction model, and the time prediction model predicts the time interval (usually milliseconds, also known as trigger delay). Considering that time prediction models usually require fast response, a lightweight model can be used, such as a shallow multi-layer perceptron MLP, or a faster linear model or tree model. Taking a simple shallow MLP model as an example, it can include 2 fully connected hidden layers and an activation layer (such as the activation function ReLU).

[0092] The time prediction model can be trained by historical data, and the historical data can be obtained, for example, by historical scheduling logs. In an optional implementation, the time prediction model can be updated by two methods: offline training and online fine-tuning. Among them, the offline training process is supervised training, and the instance execution interval can be obtained as a label based on the historical scheduling log, and the task type and task parameters are used as feature data to construct a supervised training set and train the time prediction model. According to one embodiment, the time prediction model can also be strengthened by using the historical scheduling log as batch data on a regular basis (such as daily). Online fine-tuning can be performed in real time during the task execution process. For example, after a single task trigger is completed, the error between the actual time interval and the predicted time interval is calculated as the model loss, and a smaller learning rate (such as smaller than offline training) is used to incrementally update the parameters of the time prediction model to improve the adaptability of the time prediction model.

[0093] refer to Figure 5As shown in the figure, as an example, when the time prediction model is used to predict the time interval, a minimum task cycle in the online task processing process can be controlled by the following methods: Task end callback 501, after the local subtask is executed, the function instance notifies the scheduler through the internal callback or the middle layer, and records the trigger time at the same time; Model prediction 502, the scheduler calls the time prediction model, inputs the task characteristics, and obtains the estimated trigger time interval Δt pred ; Threshold comparison 503, preset cold start time threshold T cold (can be determined by querying the cloud platform detection interface); decide (504) whether to destroy the instance based on the comparison result, in Δt pred <T cold In the case of , the instance is not destroyed (keep-alive mode), the instance is kept alive and listens for the next trigger. pred >T cold In the case of , destroy the instance (saving mode), call the instance destruction interface to deregister the instance and release resources; error feedback fine-tuning 505, when the next task actually arrives, calculate the actual time interval Δt real , compare Δt pred and Δt real The gap is used to determine the error (i.e., loss) of the time prediction model, which is used to fine-tune and update the time prediction model online. Optionally, without destroying the instance (keep-alive mode), status monitoring can also be performed to continuously monitor the instance idle time. When the instance idle time exceeds the predetermined keep-alive time threshold (e.g., 2×T cold ), forced destruction to avoid long-term occupation.

[0094] In a possible design of the system architecture, the instance lifecycle management module can be used to determine whether an instance is destroyed. The instance lifecycle management module can be integrated into the task scheduler of the service node. The scheduler can usually maintain the creation and destruction of tasks and schedule concurrent requests to function instances for execution. The scheduler can also maintain a status table for each instance, including the last call time, the keep-alive deadline (determined according to a predetermined keep-alive duration threshold), and the current mode (keep-alive / save). The instance lifecycle management module can connect to the underlying interfaces of the cloud platform, such as SDKs and RESTful interfaces, to implement dynamic destruction and keep-alive operations.

[0095] Dynamically deciding whether to terminate instances significantly reduces latency and saves costs. Specifically, in scenarios like vertical modeling or high-frequency, small-scale queries, hot-starting instances improves task response speed. Dynamically releasing idle instances can save even more resource costs, especially during periods of low peak usage and prolonged idle time.

[0096] Recalling the process above, the task processing technology for multi-party secure computation provided by the embodiments of this specification is based on a serverless computing architecture. During task processing, the service node uses the time-series data stream of the task processing process to predict the resource requirements of various subsequent instance types and adjust the resource allocation of the current instance based on the prediction results. This allows real-time control of various instance types, maximizing instance resource utilization for the corresponding task type and traffic pattern.

[0097] In an optional embodiment, the life cycle of the instance is managed by predicting the time interval between the end time of the current task and the start time of the next task, judging the relationship between the time interval and the cold start duration, and managing whether the instance is destroyed. This improves the problem of slow task response in high-frequency task scenarios in the time-triggered mode of use-and-destroy.

[0098] According to another embodiment, a task processing device for multi-party secure computing is also provided. This task processing device for multi-party secure computing can be located in a service node of a serverless computing architecture. The serverless computing architecture includes multiple service nodes and multiple database nodes. When a task requester sends a task request to a service node, at least one service node parses the task request and performs at least one interaction cycle with at least one database node to obtain a task result and provide it to the task requester. The task requester can be any network user or one of multiple database nodes, without limitation.

[0099] In a single interaction cycle, the service node completes the relevant operations in the task through at least one type instance. For a single type instance, the service node can adjust the amount of resources allocated to it through the task processing device for multi-party secure computation.

[0100] like Figure 6 As shown, the task processing device 600 for multi-party secure computing may include: an acquisition unit 601, configured to obtain a time series data stream of an instance of a single type during the current task processing process, the time series data stream including historical instance indicators of the corresponding type of instance; a prediction unit 602, configured to predict the instance resource quantity of the above-mentioned single type instance within a predetermined time period based on the time series data stream; an alignment unit 603, configured to perform resource configuration for the above-mentioned single type within a predetermined time period based on the instance resource quantity.

[0101] In an optional embodiment, the device 600 may also include an instance lifecycle control unit (not shown), which is configured to: for a single type of instance, control the instance lifecycle in the following manner: predict the time interval between the start time of its next task and the end time of the current task to obtain a predicted time interval; compare the predicted time interval with the cold start duration of the above-mentioned single type of instance; and decide whether to destroy the instance based on the comparison result.

[0102] It is worth mentioning that Figure 6 The device 600 shown is Figure 3 The described method flow corresponds to Figure 3 The corresponding description in the illustrated method embodiment is also applicable to the apparatus 600 and will not be repeated here.

[0103] According to another embodiment, there is also provided a computer readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute a combination of Figure 3 The method described by et al.

[0104] According to another embodiment, a computing device is provided, including a memory and a processor, wherein the memory stores an executable code, and when the processor executes the executable code, the system realizes the combination of Figure 3 The method described by et al.

[0105] Those skilled in the art will appreciate that, in one or more of the above examples, the functions described in the embodiments of this specification may be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions may be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0106] The specific implementation methods described above further explain in detail the purpose, technical solutions and beneficial effects of the technical concept of this specification. It should be understood that the above description is only a specific implementation method of the technical concept of this specification and is not used to limit the protection scope of the technical concept of this specification. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of this specification should be included in the protection scope of the technical concept of this specification.

Claims

1. A task processing method for multi-party secure computing, the method being implemented based on a serverless computing architecture comprising multiple service nodes and multiple database nodes. Upon receiving a task request from a task requester, the service node parses the task request and performs task processing with at least one database node through at least one interaction cycle, obtaining a task processing result and providing it to the task requester. In a single interaction cycle, the service node completes the relevant operations in the task through at least one type of instance. For a single type of instance, the service node adjusts the amount of resources allocated to it in the following ways: Obtaining a time series data stream of a current type instance during the current task processing, wherein the time series data stream includes historical instance indicators of the current type instance; Predicting instance resource quantities within a predetermined time period based on the time series data stream; Based on the instance resource amount, resources are configured for the current type instance within a predetermined time period.

2. The method according to claim 1, wherein The operations completed by the service node through the instance include at least one of the following: parsing, calculation, and allocation of subtasks; the instance indicators include at least one of the following: the instance's processor quota, memory quota, call latency, throughput, and the amount of data to be processed in the message queue or event source; the task request, subtask data in the interaction cycle, and the task processing results are all transmitted in the form of files through a shared cloud data pipeline.

3. The method according to claim 1, wherein The historical instance indicators are captured at predetermined time intervals through the monitoring interface of the cloud platform where the service node is located and stored in a time series database. The time series data flow is: instance indicator data obtained from the time series database according to a predetermined time window or data volume window for the current type of instance.

4. The method according to claim 1, wherein The predicting, based on the time series data stream, the instance resource quantity within a predetermined time period includes: Extracting instance features from the time series data stream, the instance features including at least one of the following: processor usage, memory usage, single function call duration, error rate, and amount of data to be processed in a message queue or event source of a single instance; The instance features are processed by a pre-trained resource prediction model, and the instance resource amount within a predetermined time period is determined based on the output of the resource prediction model. The instance resource amount includes at least one of a memory quota, a processor quota, and a concurrency number within the instance.

5. The method according to claim 4, wherein: The resource prediction model includes one of a long short-term memory network (LSTM), a gated recurrent unit (GRU) network, and a temporal encoder based on an attention mechanism; The resource prediction model updates parameters in the form of offline training and online fine-tuning. The training samples used for parameter updating correspond to historical instance indicators and resource quantity labels as feature data. In the offline training phase, the label is determined by the mean of multiple samples of a single type of instance. The historical instance indicator is the instance indicator of the corresponding type of instance before the multiple samples used to determine the label. In the online fine-tuning phase, supervised incremental training is performed on the previous prediction result using the actual collected resource usage data as labels.

6. The method of claim 1, wherein: The configuring of resources for the current type instance within a predetermined time period based on the instance resource amount includes: Comparing the predicted instance resource amount with the current configuration of the current type instance to determine whether the two are consistent, where the current configuration is the instance resource configuration of the current type instance during the previous execution; The resource configuration for the next execution of the current type of instance is determined based on the comparison result. If the comparison result is consistent, the current configuration is continued; if the comparison result is inconsistent, the current configuration is adjusted to make it consistent with the predicted instance resource quantity.

7. The method of claim 1, wherein: The configuring of resources for the current type instance within a predetermined time period based on the instance resource amount includes: Adjust the resource configuration of the current type of instance according to a pre-set smoothing strategy. The smoothing strategy includes not adjusting the resource configuration if at least one of the following non-adjustment conditions is met: the time interval since the previous resource configuration adjustment is less than the cooldown period, and the difference between the current configured resource amount and the predicted instance resource amount is less than a preset step size.

8. The method of claim 1, wherein: The method further comprises: For the current type of instance, the service node controls the instance lifecycle in the following ways: Predict the time interval between the next task and the end time of the current task to obtain the predicted time interval; Compare the predicted time interval with the cold start duration of the current instance type; A decision is made on whether to destroy the instance based on the comparison result.

9. The method of claim 8, wherein: The prediction time interval is performed through a pre-trained time prediction model. The input data of the time prediction model includes task type and task parameters. The task type includes one of the query subtask, horizontal modeling subtask, and vertical modeling subtask. The task parameters include at least one of the following: task operation type, model parameter magnitude, and the amount of data input for a single calculation. The time prediction model is a lightweight multi-layer perceptron or tree model.

10. The method of claim 9, wherein: The method further comprises: For a single instance, when the next task arrives, calculate the actual time interval between the arrival time of the next task and the end time of its previous task; Compare the gap between the actual time interval and the predicted time interval; The model loss of the time prediction model is determined according to the comparison results, and the model loss is used to fine-tune the time prediction model online.

11. A task processing device for multi-party secure computing, disposed in a service node of a serverless computing architecture, the serverless computing architecture comprising multiple service nodes and multiple database nodes. The service node is configured to, upon receiving a task request from a task requester, parse the task request, execute at least one interaction cycle with at least one database node to perform task processing, and provide a task processing result to the task requester. In a single interaction cycle, the service node completes the relevant operations in the task through at least one type of instance; For a single type of instance, the service node adjusts the amount of resources allocated to it through the device; the device includes: an acquiring unit configured to acquire a time series data stream of the instance of the single type during the current task processing, wherein the time series data stream includes historical instance indicators of the instance of the corresponding type; a prediction unit configured to predict the instance resource quantity of the single type instance within a predetermined time period based on the time series data stream; The alignment unit is configured to perform resource configuration for the single type instance within a predetermined time period based on the instance resource quantity.

12. The apparatus according to claim 11, further comprising an instance lifecycle control unit configured to: For a single type of instance, the instance lifecycle is controlled in the following way: the time interval between its next task and the end of the current task is predicted to obtain a predicted time interval; the predicted time interval is compared with the cold start duration of the single type of instance; and a decision is made on whether to destroy the instance based on the comparison result.

13. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 10.

14. A computing device comprising a memory and a processor, characterized in that: The memory stores executable code, and when the processor executes the executable code, the method according to any one of claims 1 to 10 is implemented.

Images