A memory-efficient fully homomorphic encryption processing method and device

Abstract

This invention proposes a memory-efficient fully homomorphic encryption processing method and apparatus, comprising: maintaining an ID mapping table for logical variables, the ID mapping table recording the IDs and state information of logical variables involved in the fully homomorphic encryption calculation; the host querying the ID mapping table according to the current variable, assembling the FHE operation command and sending it to the command buffer of the accelerator; the homomorphic encryption paging memory management unit (HEPMU) of the accelerator quickly finding the physical storage address of the RNS component page corresponding to the logical variable ID in the ciphertext table (CT) and key table (KT) managed internally according to the logical variable ID provided in the FHE operation command; and loading the RNS component page at the physical storage address into the register file of the arithmetic logic unit (ALU) within the accelerator; the accelerator passing the operation type and operand address of the FHE operation command to the ALU, and the ALU using the RNS component data loaded into the register file to perform the FHE operation.

Description

Technical Field

[0001] This invention relates to the fields of privacy protection and encryption acceleration hardware design technology, and particularly to a memory-efficient fully homomorphic encryption processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Fully homomorphic encryption (FHE), as an emerging privacy-preserving computing paradigm, allows for an unlimited number of addition and multiplication operations on encrypted data without decryption, thus demonstrating great potential in various application scenarios. However, a significant characteristic of FHE is that its operations lead to a dramatic increase in data volume and computational complexity, typically reaching 10,000 to 100,000 times the original data. This characteristic places enormous pressure on the memory systems and computing power of general-purpose computing hardware, making it difficult for general-purpose processors to efficiently handle FHE computations.

[0003] To address this challenge, academia and industry have proposed a variety of dedicated FHE accelerator architectures, which are primarily based on field-programmable gate arrays (FPGAs) and application-specific integrated circuits (ASICs).

[0004] FPGA-based FHE accelerators, such as Poseidon and FAB, offer advantages in terms of relatively low cost and programmability. This programmability allows for flexible iteration and upgrades of hardware designs to adapt to evolving FHE algorithms, enabling rapid deployment and verification.

[0005] ASIC solutions: ASIC-based FHE accelerators, such as CraterLake, ARK, and Sharp, typically offer higher computing performance and lower power consumption. To mitigate the overhead caused by large data transfers between off-chip memory and compute units (CUs), ASIC designs often incorporate large-capacity on-chip memory (e.g., 180MB to 512MB of scratchpad). However, most of these ASIC solutions are currently still in the simulation and prototyping stage and are far from large-scale deployment.

[0006] Traditional FHE accelerators mostly employ a "host + accelerator" (Host + ACC) topology. In this architecture, the accelerator (ACC) acts as a coprocessor connected to the host CPU. The design focus of this type of architecture is typically on improving the accelerator's own computational performance and the efficient utilization of on-chip caches, often assuming that large amounts of encrypted data are pre-loaded and stored in the accelerator's local memory (such as DDR or HBM). In practice, the user application runs on the host. When FHE computation is required, the relevant encrypted data and keys must first be transferred from the host memory to the accelerator's memory via the PCIe (Peripheral Component Interconnect Express) bus. After computation, the results are then returned to the host memory via the PCIe bus.

[0007] Despite the progress made in improving the computational performance of FHE, the following key issues and shortcomings still need to be addressed:

[0008] PCIe Bus Bottleneck and High Communication Overhead: Existing Host+ACC architectures heavily rely on the PCIe bus for data transfer between the host and accelerator. In FHE applications, the ciphertext and key volumes are typically very large, often far exceeding the capacity of the accelerator's on-chip memory. This results in frequent and extensive PCIe communication between the host and accelerator during application execution. The bandwidth and latency characteristics of the PCIe bus make it a major performance bottleneck for the entire FHE acceleration system. Even for highly computationally efficient ASIC accelerators, PCIe transmission overhead can account for more than 96% of the total execution time (e.g., the phenomenon observed in the evaluation of ResNet-20 applications based on the SEAL library). FPGA-based accelerators, due to their typically limited onboard memory capacity, also face similar, or even more severe, PCIe communication bottleneck problems. Figure 1 The right half of the graph clearly shows the significant increase in PCIe communication overhead under different onboard memory sizes, indicating that memory capacity limitations drastically increase communication throughput. Previous research has often underestimated the impact of this system-level bottleneck on the actual performance of FHE applications.

[0009] Inefficient use of off-chip memory: While existing FHE accelerator designs focus on improving computational efficiency and optimizing the use of on-chip memory (such as cache and Scratchpad), they often neglect the utilization efficiency of off-chip memory (such as onboard DDR / HBM). Due to the massive amount of data in FHE, the effective bandwidth and management efficiency of off-chip memory are crucial to overall performance.

[0010] Memory fragmentation: In widely adopted FHE schemes based on Residual Number Systems (RNS), ciphertext and key are typically represented in polynomial form, the size of which (i.e., the number of polynomial coefficients and the number of RNS components) changes dynamically during computation. For example, after ciphertext multiplication or during modulus switching, the number of RNS components required to represent the same data may decrease. If fixed-size memory blocks are used to manage these dynamically changing ciphertext and key, a large number of unused RNS components will still occupy valuable memory space, resulting in severe memory fragmentation and significantly reducing actual memory utilization (e.g., ...). Figure 3 As shown, the number of RNS components in ciphertexts Ct-a and Ct-b may change after homomorphic computation, leading to gaps in memory. This inefficient memory usage is particularly prominent in FHE applications based on the CKKS scheme (such as ResNet-20 and logistic regression training LR-Train), which not only wastes storage resources but also further exacerbates the problem of frequent data swapping in and out due to insufficient memory, thereby indirectly increasing PCIe communication overhead.

[0011] Idealized assumptions about data location: Many previous FHE accelerator studies have often assumed that large amounts of ciphertext and keys are pre-loaded and reside in the accelerator's local high-capacity storage such as DDR / HBM. However, when dealing with complex or large-scale FHE applications, the total amount of data required often far exceeds the actual capacity of the accelerator's onboard memory. This assumption is too idealistic and fails to reflect the data management challenges in real-world application scenarios. Summary of the Invention

[0012] This invention aims to address the main technical problems faced by existing fully homomorphic encryption (FHE) accelerators when processing FHE applications, specifically including: high PCIe communication overhead and data transmission bottlenecks, low off-chip memory utilization efficiency and memory fragmentation.

[0013] To address the shortcomings of existing technologies, such as Figure 7 As shown, this invention proposes a memory-efficient fully homomorphic encryption method, which includes:

[0014] The initial steps involve fully homomorphic encryption hardware, including a host and an accelerator, maintaining an ID mapping table for logical variables. This ID mapping table records the IDs and status information of the logical variables involved in the fully homomorphic encryption computation. The status information includes whether the RNS component pages of the logical variables have been loaded into the local memory of the accelerator. The logical variable to be fully homomorphically encrypted is then obtained as the current variable.

[0015] In the startup process, the host queries the ID mapping table based on the current variable, assembles the FHE operation command, and sends it to the command buffer of the accelerator.

[0016] In the acceleration step, the homomorphic encrypted paging memory management unit (HEPMU) of the accelerator quickly finds the physical storage address of the RNS component page corresponding to the logical variable ID in the ciphertext table (CT) and key table (KT) managed internally based on the logical variable ID provided in the FHE operation command; and loads the RNS component page at the physical storage address into the register file of the arithmetic logic unit within the accelerator.

[0017] In the operation steps, the accelerator passes the operation type and operand address of the FHE operation command to the arithmetic logic unit. The arithmetic logic unit uses the RNS component data loaded into the register file to perform the FHE operation and writes the result back to the register file. The HEPMU allocates storage space for the operation result and records its metadata, and updates the ciphertext table CT and the key table KT.

[0018] In the feedback step, the accelerator generates an interrupt signal to notify the host that the FHE operation has been completed, and returns the ID of the operation result and its physical address in memory.

[0019] The memory-efficient fully homomorphic encryption method described herein includes the following startup step:

[0020] The host queries the ID mapping table based on the current variable and finds that the RNS component page of the current variable is not in the local memory. Then the host transfers the RNS component page of the current variable from the host memory to the accelerator's local memory; the accelerator updates the ID mapping table, the ciphertext table CT, or the key table KT.

[0021] The memory-efficient fully homomorphic encryption processing method described above uses a Page Management Finite State Machine (PMFSM) as the central control logic core of the Hepto-Electronic Memory Unit (HEPMU). The PMFSM switches between different working states based on the FHE operation and the current state of the local memory.

[0022] The memory-efficient fully homomorphic encryption processing method further includes an accelerator: an ID management unit responsible for performing the conversion from logical variable ID to the actual storage address of its corresponding RNS component page in physical memory; when a variable needs to be accessed, the ID management unit queries the corresponding ciphertext table CT or key table KT to obtain the physical address information of its RNS component page, depending on whether the logical variable is ciphertext or key.

[0023] The ciphertext table CT or key table KT is stored in the on-chip register file of the accelerator, and the size of the on-chip register is configured according to the ciphertext table CT or key table KT.

[0024] The accelerator also includes a page processing unit (PPU) for retrieving the required RNS component pages from the host memory and loading these data pages into the accelerator's register file for computation by the arithmetic logic unit. When the local register file is insufficient, one or more sacrifice pages are selected according to a preset page replacement strategy. If the content of the sacrifice page has been modified, the PPU is responsible for writing its content back to the host memory and updating its status information in the CT or KT.

[0025] like Figure 8 As shown, this invention also proposes a memory-efficient fully homomorphic encryption processing device, comprising:

[0026] The initial module, the fully homomorphic encryption hardware, includes a host and an accelerator. It maintains an ID mapping table for logical variables. This ID mapping table records the IDs and status information of the logical variables involved in the fully homomorphic encryption calculation. The status information includes whether the RNS component pages of the logical variables have been loaded into the local memory of the accelerator; and obtains the logical variable to be fully homomorphically encrypted as the current variable.

[0027] The startup module queries the ID mapping table based on the current variable, assembles the FHE operation commands, and sends them to the accelerator's command buffer.

[0028] The acceleration module, the homomorphic encrypted paging memory management unit (HEPMU) of the accelerator, quickly finds the physical storage address of the RNS component page corresponding to the logical variable ID in the ciphertext table CT and key table KT managed internally based on the logical variable ID provided in the FHE operation command; and loads the RNS component page at the physical storage address into the register file of the arithmetic logic unit in the accelerator.

[0029] The accelerator passes the operation type and operand address of the FHE operation command to the arithmetic logic unit. The arithmetic logic unit uses the RNS component data loaded into the register file to perform the FHE operation and writes the result back to the register file. The HEPMU allocates storage space for the result and records its metadata, and updates the ciphertext table CT and the key table KT.

[0030] The feedback module generates an interrupt signal to notify the host that the FHE operation has been completed, and returns the ID of the operation result and its physical address in memory.

[0031] The aforementioned memory-efficient fully homomorphic encryption processing device, wherein the startup module includes:

[0032] The host queries the ID mapping table based on the current variable and finds that the RNS component page of the current variable is not in the local memory. Then the host transfers the RNS component page of the current variable from the host memory to the accelerator's local memory; the accelerator updates the ID mapping table, the ciphertext table CT, or the key table KT.

[0033] The aforementioned memory-efficient fully homomorphic encryption processing device includes a Page Management Finite State Machine (PMFSM) which serves as the central control logic core of the Hepto-Electronic Memory Unit (HEPMU). The PMFSM switches between different operating states based on the FHE operation and the current state of the local memory.

[0034] The accelerator also includes: an ID management unit, which is responsible for performing the conversion from logical variable ID to the actual storage address of its corresponding RNS component page in physical memory; when a variable needs to be accessed, the ID management unit queries the corresponding ciphertext table CT or key table KT to obtain the physical address information of its RNS component page, depending on whether the logical variable is ciphertext or key.

[0035] The ciphertext table CT or key table KT is stored in the on-chip register file of the accelerator, and the size of the on-chip register is configured according to the ciphertext table CT or key table KT.

[0036] The accelerator also includes a page processing unit (PPU) for retrieving the required RNS component pages from the host memory and loading these data pages into the accelerator's register file for computation by the arithmetic logic unit. When the local register file is insufficient, one or more sacrifice pages are selected according to a preset page replacement strategy. If the content of the sacrifice page has been modified, the PPU is responsible for writing its content back to the host memory and updating its status information in the CT or KT.

[0037] The present invention also proposes an electronic device, including the aforementioned memory-efficient fully homomorphic encryption processing device, which may be connected to an information display device, the information display device being used to display the ID of the calculation result and its physical address in memory using user-set display parameters, attributes, or through an artificial intelligence model.

[0038] The present invention also proposes a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the memory-efficient fully homomorphic encryption processing method.

[0039] The present invention also proposes a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, it implements the steps of the memory-efficient fully homomorphic encryption processing method.

[0040] As can be seen from the above solutions, the advantages of the present invention are:

[0041] The Hypnos memory-efficient homomorphic encryption processing unit and its paging memory management method proposed in this invention, by integrating a CPU on an accelerator to achieve direct access and management of encrypted data, and introducing an innovative homomorphic encryption paging memory management system (HEPMU) at the RNS component granularity, together bring the following significant overall beneficial effects:

[0042] Significantly Improved Performance in FHE Applications: Especially for data-intensive FHE applications (such as ResNet-20-based image recognition, Private Set Intersection (PSI), and Private Information Retrieval (PIR), the Hypnos architecture can significantly reduce end-to-end execution time. Compared to state-of-the-art (SOTA) ASIC and FPGA-based FHE accelerator solutions, Hypnos achieves performance improvements of up to 2.58x and 4.43x, respectively. This demonstrates that this invention can more effectively address the massive data processing challenges posed by FHE.

[0043] Significantly reduced communication overhead: By optimizing the data flow paths between the host and the accelerator, as well as between components within the accelerator, and especially by reducing unnecessary data transfers through direct data management by the on-chip CPU and fine-grained memory management by the HEPMU, Hypnos achieves a 3.78-fold reduction in overall communication overhead compared to traditional Host+ACC accelerator architectures. This directly alleviates the PCIe bottleneck that has long plagued FHE acceleration.

[0044] Significantly Improved System Energy Efficiency: The improved performance and reduced communication overhead have also led to improved energy efficiency. Using the Energy-Delay Product (EDP), a metric for measuring the energy efficiency of computing tasks (lower is better), Hypnos demonstrates energy efficiency improvements of up to 27.6 times and 19.06 times compared to existing ASIC-based Crater Lake and FPGA-based Poseidon accelerators, respectively, when processing applications such as ResNet-20. This means that the present invention consumes less energy to complete the same FHE computing task.

[0045] Memory utilization is substantially optimized: HEPMU performs fine-grained paging memory management based on RNS components, which effectively overcomes the memory fragmentation problem caused by traditional fixed-size memory allocation strategies when processing dynamically changing FHE data, significantly improves the actual utilization efficiency of off-chip memory, and greatly reduces the number of memory variable swaps caused by insufficient memory.

[0046] Hypnos enhances the practicality and deployability of FHE technology: Successful prototyping on a commercial FPGA card (Qiankun FPGA Card) demonstrates not only the practical feasibility of the proposed architecture and method but also its potential for deployment on existing hardware platforms. Compared to ASIC solutions, which suffer from long development cycles, high costs, and difficulty in modification after implementation, the FPGA-based implementation platform offers lower costs and greater flexibility for the rapid evolution of FHE algorithms and iterative updates to hardware designs.

[0047] These combined effects have propelled FHE technology toward wider practical applications. By effectively addressing the two key challenges of memory and I / O bottlenecks, Hypnos provides a more efficient and energy-saving computing platform for deploying and running complex FHE applications in sensitive fields with high data privacy requirements, such as healthcare, financial services, and cloud computing. In particular, its FPGA-based implementation is of significant practical importance in the current stage where FHE standards and algorithms are still rapidly evolving, as it allows researchers and developers to experiment with and deploy new FHE solutions at a lower cost and in a shorter timeframe. Attached Figure Description

[0048] Figure 1 A schematic diagram illustrating the impact of different onboard memory sizes on PCIe communication overhead.

[0049] Figure 2 This is a comparison diagram of the Hypnos architecture of this invention and the traditional accelerator architecture;

[0050] Figure 3 This is a diagram illustrating memory space usage.

[0051] Figure 4 This is a diagram of the overall hardware architecture of Hypnos in this invention;

[0052] Figure 5 A schematic diagram of the HEPMU microarchitecture;

[0053] Figure 6 Here is a flowchart of the HE paging memory management system workflow;

[0054] Figure 7 This is a flowchart of the method of the present invention;

[0055] Figure 8 This is a block diagram of the device of the present invention;

[0056] Figure 9 This is a schematic diagram of the structure of the first electronic device of the present invention;

[0057] Figure 10 This is a schematic diagram of the application environment structure of the first electronic device of the present invention;

[0058] Figure 11 This is a schematic diagram of the structure of the second electronic device of the present invention.

[0059] Figure label:

[0060] A - First electronic device;

[0061] B-Memory-efficient fully homomorphic encryption processing device;

[0062] C-Data acquisition equipment;

[0063] D-Information display device;

[0064] 1000 - Second electronic device;

[0065] Ⅰ-Computational Unit;

[0066] II-ROM;

[0067] III-RAM;

[0068] N-bus;

[0069] V-Interface;

[0070] VI - Input Unit;

[0071] VII - Output Unit;

[0072] VIII - Storage medium;

[0073] IX - Communication Unit. Detailed Implementation

[0074] It should be noted that, in this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0075] In the absence of further restrictions, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0076] The processor described in this invention is the control center of an electronic device. It can be a single processor or a collective term for multiple processing elements. For example, it can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of this invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0077] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory and by calling data stored in memory.

[0078] In a specific implementation, as one example, the processor may include one or more CPUs. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" can refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions). Electronic devices may include servers, desktop computers, laptops, smartphones, tablets, embedded computers, etc., where the embedded computer includes vehicles and robots, etc.

[0079] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. For specific implementation methods, please refer to the above method embodiments, which will not be repeated here.

[0080] It should be noted that the structure of the electronic device shown in the accompanying drawings of this invention does not constitute a limitation thereof. The actual knowledge structure recognition device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0081] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are 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 website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0082] It should also be understood that the term "and / or" in this article is merely a description of 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. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0083] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0084] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0085] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0087] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0088] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0089] During their in-depth research and analysis of existing FHE accelerator technologies, the inventors discovered that although the peak performance of the computing units themselves is continuously improving, the actual application performance improvement of the entire FHE acceleration system is severely limited by the inherent PCIe communication bottleneck of the traditional Host+ACC architecture, as well as the low memory utilization and severe memory fragmentation caused by poor management of the dynamic changes in FHE data. A core technical challenge is that simply increasing the computing power of the computing cores can no longer effectively solve this system-level bottleneck caused by inefficient data movement and management. Especially in data-intensive FHE applications, the cost of moving data in the storage hierarchy (time overhead and energy consumption) may even exceed the cost of the actual computation itself.

[0090] Existing technical solutions fail to adequately consider the following aspects:

[0091] (1) As the main data path between the host and the accelerator, the inherent bandwidth and latency limitations of the PCIe bus become a fundamental constraint when facing scenarios with extremely large data volumes such as FHE.

[0092] (2) In the RNS-based FHE scheme, the dynamic change of data (ciphertext and key) size poses a severe challenge to the traditional fixed-size memory management strategy, resulting in low actual memory utilization and indirectly exacerbating the pressure of data transmission.

[0093] To address the aforementioned problems, the inventors, through meticulous research and exploration, realized that innovation at the architectural level of the FHE accelerator was necessary to effectively overcome existing bottlenecks. The specific development approach is as follows:

[0094] First, to avoid or significantly reduce reliance on the inefficient PCIe bus, the inventors considered integrating some of the control and data management functions traditionally handled by the host CPU directly to the accelerator side. By integrating a CPU with sufficient processing power (such as an ARM processor) onto the accelerator hardware, it can directly manage and schedule the flow of encrypted data and execute high-level logic for FHE applications, thereby reducing unnecessary interactions with the host CPU and redundant data transfers via the PCIe bus. This design approach is reflected in… Figure 2 In the Hypnos architecture shown in the lower half, data processing is performed directly under the coordination of the CPU within the acceleration device, no longer entirely dependent on the host CPU and the system PCIe bus.

[0095] Secondly, addressing the memory fragmentation and low utilization issues caused by dynamic data changes in RNS schemes, the inventors observed that although the size of the entire ciphertext or key is variable, the size of the fundamental unit constituting them—the RNS component (i.e., the representation of a polynomial at various moduli)—is usually fixed (e.g., determined by the polynomial degree and the modulus bit width). This characteristic makes finer-grained memory management possible. Based on this, the inventors proposed a novel paging memory management system based on "Homomorphic Encryption Pages (HE pages)." This system uses a single or a few RNS components as the basic unit of memory allocation and management (i.e., a "page"), rather than the entire ciphertext or key. In this way, the actual amount of data required can be matched more precisely, thereby significantly improving memory space utilization, reducing waste caused by storing unused RNS components, and consequently reducing unnecessary data transfer.

[0096] This comprehensive solution, which optimizes both system-level communication bottlenecks and micro-level memory management efficiency, forms the core of this invention. The technical challenge lies not only in designing an efficient on-chip CPU integration scheme and fine-grained paged memory management hardware (HEPMU), but also in how to enable these two components, as well as the FHE computing unit, to work efficiently together to serve complex FHE applications.

[0097] In summary, to achieve the above-mentioned technical effects, the present invention proposes the following key technical points:

[0098] Key Point 1: A novel architecture for Hypnos, a memory-efficient homomorphic encryption processing unit, is proposed to significantly reduce PCIe communication dependency. By integrating a CPU on the accelerator side for direct data management and task scheduling, Hypnos effectively eliminates complete dependence on the host CPU and can bypass congested system PCIe buses for most data operations, thus significantly reducing the amount of ciphertext and keys transmitted between the host and accelerator via PCIe. Compared to the traditional Host+ACC architecture, communication overhead is reportedly reduced by 3.78 times. Improved overall system performance: Even compared to ASIC accelerators with stronger raw computing power, Hypnos can improve the practical application performance of the entire FHE acceleration system by significantly optimizing PCIe communication efficiency, as communication time is often the dominant factor in many data-intensive FHE applications.

[0099] Key Point 2: A novel paging memory management system based on homomorphic encrypted pages was designed and implemented to significantly improve memory utilization. This invention manages memory in smaller, relatively fixed-size RNS components, allowing the HEPMU to store data more compactly and significantly reducing memory fragmentation caused by storing unused or partially used RNS components, thereby greatly improving the actual utilization of off-chip memory. It further reduces data transfer volume and the number of exchanges: High memory utilization means that more effective data can be accommodated within a limited memory capacity, thus reducing the frequency and total amount of data exchange with the host due to insufficient memory. Existing technologies, for simplicity, use coarser-grained units for memory management to reduce the number of managed variables and eliminate the need to consider memory waste. This invention, to manage memory in smaller, relatively fixed-size RNS components, requires additional, more complex hardware circuitry. Furthermore, due to the increased number of things to be managed, simple hardware circuitry cannot handle the complex logic of this function; therefore, software design is needed to assist in achieving finer-grained memory management.

[0100] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.

[0101] Hypnos overall hardware architecture (refer to) Figure 4 )

[0102] The Hypnos memory-efficient homomorphic encryption processing unit proposed in this invention is deployed on a heterogeneous ARM+FPGA computing platform, such as Ant Group's Qiankun FPGA card. This card uses AMD Xilinx Versal ACAP series chips and integrates a powerful processing system (PS) and flexible programmable logic (PL) resources. The overall architecture of Hypnos mainly consists of three regions: processing system (PS), programmable logic (PL), and on-chip network (NOC).

[0103] FHE Execution & Controller Unit

[0104] Hypnos employs an abstract approach to operational-level operators in designing its FHE computational units (CUs), rather than directly exposing the FHE algorithm to upper-level control by breaking it down into very small, fundamental atomic operators (such as single number-theoretic transformations (NTTs), modular multiplication (MM), and modular addition (MA)). This design choice aims to simplify the CPU's programming model and instruction-deploying complexity, while allowing the hardware to perform deep optimizations internally for these coarser-grained, common FHE compound operations. For example, a "ciphertext multiplication" operator might contain a series of sub-steps, including multiple NTTs, coefficient-to-dot multiplication (modular multiplication), inverse NTTs, and possible modular switching. The paper mentions that Hypnos provides, for example, 64 such parallel processing units to achieve high throughput.

[0105] Within these operational architectures, the basic arithmetic logic units that constitute them (such as butterfly units performing NTT, units performing modular multiplication, etc.) are efficiently arranged and operate in a pipelined or cascaded manner. Each parallel processing unit has its own independent local cache for storing frequently accessed coefficients, twiddle factors, or intermediate results, thereby effectively reducing the number of accesses to main memory (whether on-chip shared BRAM or off-chip DDR), which is crucial for improving request processing efficiency and the overall performance of the entire system.

[0106] The FHE controller plays a crucial scheduling and control role within the CU. It retrieves FHE operation commands from the PS-side CPU via the command buffer, then parses these commands using an internal command decoder, and assigns the specific computational tasks to the corresponding functional units or parallel processing pipelines within the CU. If the system supports multi-issue, the multi-issue order unit will distribute the processed and scheduled command information to multiple available computational units simultaneously, further enhancing parallelism. After computation, the results are temporarily stored in a write-back buffer and eventually written back to a designated register file or memory location. This operational-level abstraction and internal optimization allows the CPU to focus on higher-level logic control and data flow orchestration, while delegating the complex low-level FHE computational details to highly optimized hardware execution units—an effective way to achieve high-performance FHE acceleration.

[0107] HEPMU microarchitecture (Homomorphic Encryption Page Management Unit) reference Figure 5 ).

[0108] The Homomorphic Encryption Paged Memory Management Unit (HEPMU) is a core innovation in the Hypnos architecture for achieving memory efficiency. It uses RNS (Residual Number System) components as the basic granularity to perform paged memory management of the ciphertext and key data involved in the FHE computation process. Its microarchitecture mainly includes the following components:

[0109] Configuration Registers: The HEPMU contains a set of configuration registers that allow the system to flexibly configure the granularity of memory management (e.g., how many RNS components a "HE page" contains) and the size and number of entries in internal management tables (such as CT and KT) according to the specific needs of the currently running FHE application and the selected security parameters. This configuration information is written to the HEPMU by the CPU in the PS area via the AXI4-Lite bus during initialization or application switching. During FHE application execution, the HEPMU operates according to these configuration parameters. Simultaneously, the CPU can also read these configuration registers and the HEPMU's status information via the same bus to understand its current operating status.

[0110] Because fully homomorphic encryption involves a wide variety of parameters, this invention considered scalability requirements from the initial hardware design stage. Therefore, in some application scenarios where it is not necessary or the requirements are not high, the granularity of memory management can be flexibly adjusted according to the trade-off between overhead and performance. In addition, for some applications that may need to manage fewer items, the size of the internal management table can be set from the configuration stage, thereby reducing overhead in a more customized manner.

[0111] Page Management Finite State Machine (PMFSM): The PMFSM is the central control logic core of the Hepburn Memory Execution Unit (HEPMU). Based on the command sequence received from the FHE controller (e.g., reading / writing a specific RNS component of a ciphertext) and the current state of the memory system (e.g., cache), it switches between different operating states (e.g., Idle, Write, Eviction, Read, etc.). The PMFSM is responsible for coordinating the task scheduling and collaborative work of various components within the HEPMU (e.g., ID management, PPU, etc.) to ensure the correct and orderly execution of memory operations.

[0112] ID Management: In FHE applications, each ciphertext or key is typically assigned a unique identifier (ID). The ID management unit is responsible for performing the translation from this logical ID to the actual physical memory address of its corresponding RNS component page. When a variable needs to be accessed, the ID management unit queries the corresponding Ciphertext Table (CT) or Key Table (KT) to obtain the physical address information of its RNS component page, depending on whether the variable is ciphertext or key. The retrieved address is then written to the address buffer for use by the Page Processing Unit (PPU). An important design feature is that the CT and KT are stored in an on-chip register file within the HEPMU, rather than in slower off-chip memory. This is done to achieve extremely fast address lookup speeds. Furthermore, since different FHE parameter configurations (such as polynomial degree N, modulus chain length L, etc.) can cause the required size of the CT and KT to change dynamically, storing them in a flexibly configurable register file helps to adapt to these changes. For example, the paper mentions that when the modular chain length L = 32 and the system memory is 16GB, the sizes of CT and KT are approximately 69KB and 17.25KB, respectively. This on-chip, fast, and configurable table storage mechanism is key to the efficient operation of HEPMU.

[0113] Page Processing Unit (PPU): The PPU is the unit that actually performs operations related to the RNS page table. Based on the physical address information provided by the ID management unit, it retrieves the required RNS component pages from external DDR memory and loads these data pages into the local high-speed register file of the FHE compute unit (CU). Figure 5 In the diagram (Bank0, Bank1, Bank2), the arithmetic logic unit (ALU) performs calculations. When the CU's local register file space is insufficient and space needs to be freed up for new data pages, the replacement unit within the PPU selects one or more "sacrificial" pages according to a preset page replacement strategy (e.g., LRU - Least Recently Used algorithm). If the selected sacrificial page is a "dirty" page (i.e., its content has been modified), the PPU is responsible for writing its content back to external DDR memory and updating its status information in the CT or KT. The paper mentions that after evaluating different replacement strategies, the LRU strategy's performance in ResNet-20 applications is closest to the ideal optimal (OPT) strategy, and therefore it was adopted by Hypnos's HEPMU.

[0114] Data path and interface: The HEPMU interacts with the CU's register file and external DDR system memory through its internal address logic, address buffer, transfer switch, and a DDR controller to achieve efficient read and write operations of RNS component pages.

[0115] HE Paged Management System Workflow (see reference) Figure 6 )

[0116] The homomorphic encrypted paging memory management system proposed in this invention achieves efficient memory management of data in FHE applications at the RNS component granularity through close collaboration between the CPU (software level) on the PS side and the computing unit CU (hardware level, especially its internal HEPMU) on the PL side. Its typical workflow is as follows:

[0117] CPU-side operations:

[0118] The FHE application first undergoes specialized compilation and linking on the CPU in the PS region before execution.

[0119] Phase 1 (Querying Variable Status and Command Generation): When the application reaches a point where a homomorphic operation needs to be performed via the FHE hardware accelerator (CU) (e.g., multiplying two ciphertexts encrypted1 and encrypted2), the CPU first queries an ID map maintained at the software level. This ID map records the IDs of the various logical variables (ciphertexts or keys) involved in the current FHE computation, as well as some of their status information, such as whether their corresponding RNS component pages have been loaded into the CU's local memory (i.e., the memory area managed by the HEPMU).

[0120] It's important to note that the multiplication of encrypted1 and encrypted2 described above is merely an example to illustrate the workflow of our designed hardware-software co-processing system. This invention accelerates the computational process between encrypted data and can therefore be applied to all computations in fully homomorphic encryption. The data in homomorphic encryption can be any data worthy of computation, such as encrypted images, audio, video, and text.

[0121] Phase 2 (Sending commands or handling page faults):

[0122] Cache Hit Situation: If a query of the ID Map reveals that the RNS component pages of all operands required for the operation (such as encrypted1 and encrypted2) already exist in the CU's local memory (i.e., a "hits"), the CPU will directly assemble an FHE operation command. This command typically includes an opcode (indicating the type of operation to be performed, such as ciphertext multiplication), the logical IDs (Var IDs) of the operands, the logical ID for storing the result (Result ID), and an important parameter—the computation level. The Level parameter is crucial in the RNS-FHE scheme; it indicates the modulus chain level of the current ciphertext and directly relates to which RNS components need to be used for computation. Figure 6 As shown, the command may be a fixed-length format (e.g., 8 bytes). The CPU then sends this command to the CU's command buffer via a bus such as AXI4-Lite, and the CPU can then enter a wait state, waiting for the CU to return a signal that the operation is complete (e.g., via an interrupt).

[0123] Cache Miss / Page Fault: If a query of the ID Map reveals that one or more required operand variables' RNS component pages are not currently in the CU's local memory (i.e., a "miss" or "page fault"), the CPU is responsible for handling this page fault. The CPU first transfers the RNS component data of these missing variables from the system shared memory (Homomorphic Encryption Shared Memory, located in main DDR) to the CU's local memory area via DMA (Direct Memory Access). Simultaneously or after initiating the DMA transfer, the CPU also needs to notify the HEPMU that new data pages have been loaded. The HEPMU will correspondingly update its internal ID Map (or its hardware copy), Ciphertext Table (CT), or Key Table (KT), recording metadata such as the IDs of these newly loaded variables, their physical locations in local memory, and their levels. During this data paging process, the CPU primarily processes the variable IDs, levels, and other metadata, and initiates the DMA transfer; it does not directly manipulate the encrypted content itself. After data preparation is complete, the CPU sends the FHE operation command to the CU and waits for the interrupt upon completion of the computation.

[0124] Computational unit (CU) side operations (primarily driven by the HEPMU):

[0125] Phase 3 (Command Execution and Result Write-back): The CU's FHE controller retrieves the FHE operation command sent by the CPU from the command buffer and decodes it.

[0126] Based on the operand IDs provided in the command, HEPMU quickly locates the physical storage address of the corresponding RNS component pages in the CU's local memory (or the pages that need to be loaded from DDR) in its internally managed Ciphertext Table (CT) and Key Table (KT). The Level parameter helps HEPMU determine which specific RNS components need to participate in the current computation (because in the RNS scheme, different computation stages may use different subsets of the modulus).

[0127] HEPMU is responsible for loading the located RNS component pages that actually participate in the computation from its managed local cache (if a hit) or from external DDR (if a miss, a paging operation is performed) into the high-speed register file of the CU's internal execution unit.

[0128] The FHE controller passes the decoded operation type (such as multiplication, addition) and related auxiliary information (such as level, operand address, etc.) to the arithmetic logic unit (i.e., the Execution Unit in the diagram) in the CU.

[0129] The arithmetic logic unit uses RNS component data loaded into the register file to perform specified FHE operations.

[0130] After the operation is complete, the result (usually a new ciphertext, identified by the Result ID specified in the command) and its associated metadata (e.g., the new Level, as some operations such as multiplication can change the Level of the ciphertext) are written back to the CU's register file. Simultaneously, the HEPMU updates its CT or KT, allocates storage space for this new result, and records its metadata.

[0131] Finally, the CU notifies the CPU on the PS side by generating an interrupt signal, informing it that the requested FHE operation has been completed, and may also return information such as the result's ID, its physical address in memory (or a handle / pointer), etc. After receiving the interrupt, the CPU can retrieve the operation result from the specified location as needed, thus completing the entire command execution cycle.

[0132] This hardware-software collaborative data orchestration mechanism is key to Hypnos's high efficiency. The CPU, acting as the manager of high-level applications, is responsible for application flow control and initiating data transfer when data is missing. The CU (especially the HEPMU), on the other hand, acts as a dedicated data manager and computation executor, handling fine-grained mapping, cache management, and actual FHE computation at the page level for all RNS components. This division of labor makes complex memory management transparent to FHE application developers and automates execution at the hardware level, while allowing the CPU to effectively guide data management through high-level instructions (such as Level information). For example, Level information is crucial for RNS-FHE because it determines the set of currently active RNS moduli in the ciphertext, directly affecting which RNS components are necessary. The HEPMU can use this information to acquire and process only the necessary data, avoiding unnecessary memory accesses and computations.

[0133] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.

[0134] like Figure 8 As shown, this invention also proposes a memory-efficient fully homomorphic encryption processing device, comprising:

[0135] The initial module, the fully homomorphic encryption hardware, includes a host and an accelerator. It maintains an ID mapping table for logical variables. This ID mapping table records the IDs and status information of the logical variables involved in the fully homomorphic encryption calculation. The status information includes whether the RNS component pages of the logical variables have been loaded into the local memory of the accelerator; and obtains the logical variable to be fully homomorphically encrypted as the current variable.

[0136] The startup module queries the ID mapping table based on the current variable, assembles the FHE operation commands, and sends them to the accelerator's command buffer.

[0137] The acceleration module, the homomorphic encrypted paging memory management unit (HEPMU) of the accelerator, quickly finds the physical storage address of the RNS component page corresponding to the logical variable ID in the ciphertext table CT and key table KT managed internally based on the logical variable ID provided in the FHE operation command; and loads the RNS component page at the physical storage address into the register file of the arithmetic logic unit in the accelerator.

[0138] The accelerator passes the operation type and operand address of the FHE operation command to the arithmetic logic unit. The arithmetic logic unit uses the RNS component data loaded into the register file to perform the FHE operation and writes the result back to the register file. The HEPMU allocates storage space for the result and records its metadata, and updates the ciphertext table CT and the key table KT.

[0139] The feedback module generates an interrupt signal to notify the host that the FHE operation has been completed, and returns the ID of the operation result and its physical address in memory.

[0140] The aforementioned memory-efficient fully homomorphic encryption processing device, wherein the startup module includes:

[0141] The host queries the ID mapping table based on the current variable and finds that the RNS component page of the current variable is not in the local memory. Then the host transfers the RNS component page of the current variable from the host memory to the accelerator's local memory; the accelerator updates the ID mapping table, the ciphertext table CT, or the key table KT.

[0142] The aforementioned memory-efficient fully homomorphic encryption processing device includes a Page Management Finite State Machine (PMFSM) which serves as the central control logic core of the Hepto-Electronic Memory Unit (HEPMU). The PMFSM switches between different operating states based on the FHE operation and the current state of the local memory.

[0143] The accelerator also includes: an ID management unit, which is responsible for performing the conversion from logical variable ID to the actual storage address of its corresponding RNS component page in physical memory; when a variable needs to be accessed, the ID management unit queries the corresponding ciphertext table CT or key table KT to obtain the physical address information of its RNS component page, depending on whether the logical variable is ciphertext or key.

[0144] The ciphertext table CT or key table KT is stored in the on-chip register file of the accelerator, and the size of the on-chip register is configured according to the ciphertext table CT or key table KT.

[0145] The accelerator also includes a page processing unit (PPU) for retrieving the required RNS component pages from the host memory and loading these data pages into the accelerator's register file for computation by the arithmetic logic unit. When the local register file is insufficient, one or more sacrifice pages are selected according to a preset page replacement strategy. If the content of the sacrifice page has been modified, the PPU is responsible for writing its content back to the host memory and updating its status information in the CT or KT.

[0146] like Figure 9As shown, in another embodiment of the present invention, a first electronic device A is also proposed, including the aforementioned memory-efficient fully homomorphic encryption processing device B.

[0147] like Figure 10 As shown, the first electronic device A can also be connected to the data acquisition device C and the information display device D through a wired or wireless information transmission scheme. The data acquisition device C is used to acquire encrypted data to be homomorphically encrypted, such as video, and the information display device D is used to display the encryption operation results obtained by the present invention.

[0148] The information display device D can process and organize the data output by the first electronic device A based on an information display mechanism to improve the readability of the data. This information display mechanism can be manually preset, for example, visualizing the data output by the first electronic device A. It can present the user with the specified key information based on user-defined display parameters and / or attributes, such as the data range and font, color, and scrolling options. Users can access this information more quickly without needing to navigate to secondary pages or scroll through pages, saving them time and effort. Alternatively, the information display mechanism can be an artificial intelligence (AI) display model that learns the user's key information interests based on past usage habits, such as viewing time, click count, and edit count, and automatically presents rich and necessary key information.

[0149] The present invention also provides a computer program product, which includes a computer program that can be stored on a readable storage medium. When the computer program is executed by a processor, the computer is able to execute the memory-efficient fully homomorphic encryption processing method provided by the above methods.

[0150] In another embodiment, the present invention also proposes a storage medium VIII for storing a computer program that performs the memory-efficient fully homomorphic encryption processing method. It should be understood that the storage medium in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0151] Figure 11 A schematic block diagram of a second electronic device 1000 that can be used to implement embodiments of the present invention is shown. The second electronic device 1000 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The second electronic device 1000 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein. The second electronic device 1000 may be the same as or different from the first electronic device A.

[0152] The second electronic device 1000 includes a computing unit I, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory II (ROM) or a computer program loaded from storage medium VIII into random access memory (RAM) III. The RAM III may also store various programs and data required for the operation of the device 1000. The computing unit I, ROM II, and RAM III are interconnected via bus IV. An input / output (I / O) interface V is also connected to bus IV.

[0153] Multiple components in the second electronic device 1000 are connected to I / O interface V, including: input unit VI, such as a keyboard, mouse, etc.; output unit VII, such as various types of displays, speakers, etc.; storage medium VIII, such as a disk, optical disk, etc.; and communication unit IX, such as a network card, modem, wireless transceiver, etc. Communication unit IX allows the second electronic device 1000 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0154] The computing unit I can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit I include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit I performs the various methods and processes described above, such as method steps S1-S5. For example, in some embodiments, the methods can be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage medium VIII. In some embodiments, part or all of the computer program can be loaded and / or installed on device 1000 via ROM II and / or communication unit IX. When the computer program is loaded into RAM III and executed by computing unit I, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, computing unit I can be configured to perform methods by any other suitable means (e.g., by means of firmware).

[0155] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A memory-efficient fully homomorphic encryption method, characterized in that, include: The initial steps involve fully homomorphic encryption hardware consisting of a host and an accelerator. The accelerator maintains an ID mapping table for logical variables, which records the IDs and status information of the logical variables involved in the fully homomorphic encryption calculation. The status information includes whether the RNS component pages of the logical variables have been loaded into the accelerator's local memory. The logical variable to be fully homomorphically encrypted is then obtained as the current variable. In the startup process, the host queries the ID mapping table based on the current variable, assembles the FHE operation command, and sends it to the command buffer of the accelerator. In the acceleration step, the homomorphic encryption paging memory management unit (HEPMU) of the accelerator quickly finds the physical storage address of the RNS component page corresponding to the logical variable ID in the local memory in the ciphertext table (CT) and key table (KT) managed internally based on the logical variable ID provided in the FHE operation command. The RNS component page of the physical storage address is then loaded into the register file of the arithmetic logic unit within the accelerator. In the operation steps, the accelerator passes the operation type and operand address of the FHE operation command to the arithmetic logic unit. The arithmetic logic unit uses the RNS component data loaded into the register file to perform the FHE operation and writes the result back to the register file. The HEPMU allocates storage space for the operation result and records its metadata, and updates the ciphertext table CT and the key table KT. In the feedback step, the accelerator generates an interrupt signal to notify the host that the FHE operation has been completed, and returns the ID of the operation result and its physical address in memory.

2. The memory-efficient fully homomorphic encryption method as described in claim 1, characterized in that, The startup process includes: The host queries the ID mapping table based on the current variable and finds that the RNS component page of the current variable is not in the local memory. Then the host transfers the RNS component page of the current variable from the host memory to the accelerator's local memory; the accelerator updates the ID mapping table, the ciphertext table CT, or the key table KT.

3. The memory-efficient fully homomorphic encryption method as described in claim 1, characterized in that, The Page Management Finite State Machine (PMFSM) is the central control logic core of the HepMule (HEPMU). The PMFSM switches between different working states based on the FHE operation and the current state of local memory.

4. The memory-efficient fully homomorphic encryption method as described in claim 1, characterized in that, The accelerator also includes: an ID management unit, which is responsible for performing the conversion from logical variable ID to the actual storage address of its corresponding RNS component page in physical memory; when a variable needs to be accessed, the ID management unit queries the corresponding ciphertext table CT or key table KT to obtain the physical address information of its RNS component page, depending on whether the logical variable is ciphertext or key. The ciphertext table CT or key table KT is stored in the on-chip register file of the accelerator, and the size of the on-chip register is configured according to the ciphertext table CT or key table KT. The accelerator also includes a page processing unit (PPU) for retrieving the required RNS component pages from the host memory and loading these data pages into the accelerator's register file for computation by the arithmetic logic unit (ALU). When the accelerator's local register file space is insufficient, one or more sacrifice pages are selected according to a preset page replacement strategy. If the content of the sacrifice page has been modified, the PPU is responsible for writing its content back to the host memory and updating its status information in the CT or KT.

5. A memory-efficient fully homomorphic encryption processing device, characterized in that, include: The initial module, the fully homomorphic encryption hardware includes a host and an accelerator. The accelerator maintains an ID mapping table for logical variables. This ID mapping table records the IDs and status information of the logical variables involved in the fully homomorphic encryption calculation. The status information includes whether the RNS component pages of the logical variables have been loaded into the local memory of the accelerator; and obtains the logical variable to be fully homomorphically encrypted as the current variable. The startup module queries the ID mapping table based on the current variable, assembles the FHE operation commands, and sends them to the accelerator's command buffer. The acceleration module, the Homomorphic Encryption Paging Memory Management Unit (HEPMU) of the accelerator, quickly finds the physical storage address of the RNS component page corresponding to the logical variable ID in the ciphertext table CT and key table KT managed internally based on the logical variable ID provided in the FHE operation command. The RNS component page of the physical storage address is then loaded into the register file of the arithmetic logic unit within the accelerator. The accelerator passes the operation type and operand address of the FHE operation command to the arithmetic logic unit. The arithmetic logic unit uses the RNS component data loaded into the register file to perform the FHE operation and writes the result back to the register file. The HEPMU allocates storage space for the result and records its metadata, and updates the ciphertext table CT and the key table KT. The feedback module generates an interrupt signal to notify the host that the FHE operation has been completed, and returns the ID of the operation result and its physical address in memory.

6. The memory-efficient fully homomorphic encryption processing device as described in claim 5, characterized in that, This startup module includes: The host queries the ID mapping table based on the current variable and finds that the RNS component page of the current variable is not in the local memory. Then the host transfers the RNS component page of the current variable from the host memory to the accelerator's local memory; the accelerator updates the ID mapping table, the ciphertext table CT, or the key table KT.

7. The memory-efficient fully homomorphic encryption processing device as described in claim 5, characterized in that, The Page Management Finite State Machine (PMFSM) is the central control logic core of the HepMule (HEPMU). The PMFSM switches between different operating states based on the FHE (Functional Heap) operation and the current state of local memory. The accelerator also includes: an ID management unit, which is responsible for performing the conversion from logical variable ID to the actual storage address of its corresponding RNS component page in physical memory; when a variable needs to be accessed, the ID management unit queries the corresponding ciphertext table CT or key table KT to obtain the physical address information of its RNS component page, depending on whether the logical variable is ciphertext or key. The ciphertext table CT or key table KT is stored in the on-chip register file of the accelerator, and the size of the on-chip register is configured according to the ciphertext table CT or key table KT. The accelerator also includes a page processing unit (PPU) for retrieving the required RNS component pages from the host memory and loading these data pages into the accelerator's register file for computation by the arithmetic logic unit (ALU). When the accelerator's local register file space is insufficient, one or more sacrifice pages are selected according to a preset page replacement strategy. If the content of the sacrifice page has been modified, the PPU is responsible for writing its content back to the host memory and updating its status information in the CT or KT.

8. An electronic device, characterized in that, The device includes a memory-efficient fully homomorphic encryption processing apparatus as described in any one of claims 5-7, wherein the electronic device is connected to an information display device, which is used to display the ID of the calculation result and its physical address in memory using user-set display parameters, attributes, or through an artificial intelligence model.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the memory-efficient fully homomorphic encryption processing method of any one of claims 1-4.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the memory-efficient fully homomorphic encryption processing method described in any one of claims 1-4.

Images