Den Heiligen Gral freischalten: Herausforderungen und Lösungen der vollständig homomorphen Verschlüsselung in der Kette

)

Kernideen:

1. FHE verspricht, der „Heilige Gral der Kryptographie“ zu sein, allerdings gibt es viele Leistungs-, Entwicklererfahrungs- und Sicherheitsbedenken, die seine derzeitige Akzeptanz einschränken.

2. Wie in der obigen Grafik dargestellt, muss FHE zusammen mit ZKPs und MPC eingesetzt werden, um ein wirklich vertrauliches und sicheres, gemeinsames Staatssystem aufzubauen.

3.FHE entwickelt sich schnell weiter; Die Entwicklung neuer Compiler, Bibliotheken, Hardware etc. Ganz zu schweigen davon, dass FHE enorm von der Forschung und Entwicklung von Web2-Unternehmen (Intel, Google, DARPA usw.) profitiert.

4. Mit zunehmender Reife von FHE und dem umgebenden Ökosystem gehen wir davon aus, dass „überprüfbare FHE“ zum Standard wird. FHE-Anwendungen können sich dafür entscheiden, die Berechnung und Verifizierung an FHE-Coprozessoren auszulagern.

5. Eine grundlegende Einschränkung von On-Chain-FHE lautet: „Wer besitzt den Entschlüsselungsschlüssel?“ Threshold-Entschlüsselung und MPC bieten Lösungen, sind jedoch im Allgemeinen an einen Kompromiss zwischen Leistung und Sicherheit gebunden.

Vorstellung:

Die transparente Natur von Blockchains ist ein zweischneidiges Schwert; Obwohl seine Offenheit und Beobachtbarkeit schön ist, stellt es ein grundlegendes Hindernis für die Einführung in Unternehmen dar.

Der Datenschutz in der Kette ist seit fast einem Jahrzehnt eines der größten Probleme im Kryptobereich. Obwohl es viele Teams gibt, die ZK-basierte Systeme entwickeln, um den Datenschutz in der Kette zu gewährleisten; Sie können keinen gemeinsamen, verschlüsselten Zustand unterstützen. Warum? Die kurze Antwort lautet, dass diese Programme eine Funktion einer Reihe von ZKPs sind und es daher für niemanden möglich ist, willkürliche Logik auf den aktuellen Zustand anzuwenden. Was bedeutet das? Grundsätzlich können wir keine vertraulichen Shared-State-Anwendungen (denken Sie an privates Uniswap) nur mit ZKPs erstellen.

Jüngste Durchbrüche haben jedoch gezeigt, dass durch die Kombination von ZKPs mit vollständig homomorpher Verschlüsselung (FHE) ein vollständig verallgemeinerbares, vertrauliches DeFi erreicht werden könnte. Wie? FHE ist ein aufstrebendes Feld der Kryptographie, das beliebige Berechnungen über verschlüsselte Daten ermöglicht (klingt verrückt, oder?!). Wie in der Grafik oben gezeigt, können ZKPs die Integrität von Benutzereingaben und Berechnungen nachweisen und FHE kann die Berechnung selbst verarbeiten.

Während FHE verspricht, der „Heilige Gral der Kryptographie“ zu sein, versuchen wir, eine objektive Analyse des Fachgebiets und seiner verschiedenen Herausforderungen und möglichen Lösungen bereitzustellen. Wir behandeln die folgenden On-Chain-FHE-Themen:

• FHE-Systeme, Bibliotheken und Compiler
• Sichere Schwellenwert-Entschlüsselung
• ZKPs für Benutzereingaben + Computerparty
• Programmierbare, skalierbare DA-Schicht
• FHE-Hardware

FHE-Systeme, Bibliotheken und Compiler

Herausforderung: Neue FHE-Systeme, Bibliotheken und Compiler

Der grundlegende Engpass von On-Chain-FHE liegt in der rückständigen Entwicklertools/Infrastruktur. Im Gegensatz zu ZKPs oder MPC gibt es FHE erst seit 2009 und die Reifezeit war daher viel kürzer.

Die Haupteinschränkungen in FHE DevEx sind:

• Eine benutzerfreundliche Front-End-Sprache, mit der Entwickler ohne große Kenntnisse der Backend-Kryptografie programmieren können
• Ein voll funktionsfähiger FHE-Compiler, der die ganze Drecksarbeit erledigen kann. (Parameterauswahl, SIMD-Optimierung für BGV/BFV und parallele Optimierung)
• Bestehende FHE-Systeme (insbesondere TFHE) sind im Vergleich zur einfachen Berechnung etwa 1000-mal langsamer

Um die Feinheiten der FHE-Integration wirklich zu verstehen, gehen wir die Entwicklerreise durch:

Der erste Schritt zur Integration von FHE in Ihre Anwendung besteht darin, ein zu verwendendes FHE-Schema auszuwählen. In der folgenden Tabelle werden die wichtigsten Schemata erläutert:

Wie in der Tabelle oben gezeigt, verfügen boolesche Schaltkreise wie FHEW und TFHE über das schnellste Bootstrapping und können ein kompliziertes, recht komplexes Parameterauswahlverfahren vermeiden. Außerdem könnten sie in willkürlichen/generischen Berechnungen verwendet werden, sind aber relativ langsam; Während BGV/BFV für allgemeines DeFi geeignet sein könnten, da sie bei hochpräzisen arithmetischen Berechnungen effizienter sind, müssen Entwickler die Tiefe der Schaltung im Voraus kennen, um alle Parameter des Schemas einzurichten. Am anderen Ende des Spektrums unterstützt CKKS die homomorphe Multiplikation, bei der Präzisionsfehler zulässig sind, was sie optimal für nicht präzise Anwendungsfälle wie ML macht.

Als Entwickler müssen Sie eine FHE-Lösung sehr sorgfältig auswählen, da diese alle anderen Designentscheidungen und die zukünftige Leistung beeinflusst. Darüber hinaus gibt es mehrere Schlüsselparameter, die für die korrekte Einrichtung des FHE-Schemas von entscheidender Bedeutung sind, beispielsweise die Wahl der Modulgröße und die Rolle des Polynomgrades.

Kommen wir zu den Bibliotheken. Die Merkmale und Fähigkeiten der beliebten FHE-Bibliotheken können der folgenden Tabelle entnommen werden:

Die Bibliotheken haben aber auch unterschiedliche Beziehungen zu Schemata und Compilern, wie unten gezeigt:

Nach Auswahl der FHE-Lösung müssen Entwickler Parameter festlegen. Die richtige Auswahl der Parameter hat einen großen Einfluss auf die Leistung des FHE-Systems. Noch schwieriger ist es, dies erfordert ein gewisses Verständnis der abstrakten Algebra, FHE-spezifischer Operationen wie Neulinearisierung und Analog-Digital-Umschaltung sowie arithmetischer oder binärer Schaltkreise. Schließlich ist für eine effektive Parameterauswahl ein konzeptionelles Verständnis darüber erforderlich, wie sie sich auf das FHE-Schema auswirken.

An dieser Stelle fragen sich Entwickler möglicherweise:

Wie groß muss mein Klartextraum sein? Welche Größe von Chiffretexten ist akzeptabel? Wo kann ich Berechnungen parallelisieren? Und viele mehr…

Obwohl FHE beliebige Berechnungen unterstützen kann, müssen Entwickler außerdem ihre Denkweise beim Schreiben von FHE-Programmen ändern. Beispielsweise kann man keine Verzweigung (if-else) abhängig von einer Variablen im Programm schreiben, da Programme die Variablen nicht direkt wie einfache Daten vergleichen können. Stattdessen müssen Entwickler ihren Code von Verzweigungen auf eine Art Berechnung umstellen, die die Bedingungen aller Verzweigungen berücksichtigen kann. Ebenso wird dadurch verhindert, dass Entwickler Schleifen in ihren Code schreiben.

Kurz gesagt: Für einen Entwickler, der mit FHE nicht vertraut ist, ist es nahezu unmöglich, FHE in seine Anwendung zu integrieren. Es wird umfangreiche Entwicklungstools/Infrastruktur erfordern, um die Komplexität zu abstrahieren, die FHE mit sich bringt.

Lösung:

1. Web3-spezifische FHE-Compiler

Obwohl es bereits FHE-Compiler gibt, die von Unternehmen wie Google und Microsoft entwickelt wurden, handelt es sich dabei um:

• Nicht auf Leistung ausgelegt, sondern erhöht den 1000-fachen Mehraufwand im Vergleich zum direkten Schreiben von Schaltkreisen
• Optimiert für CKKS (auch bekannt als ML) und nicht so vorteilhaft für BFV/BGV, wie es für DeFi benötigt wird
• Nicht für Web3 erstellt. Unterstützt keine Kompatibilität mit ZKP-Schemata, Programmverkettung usw.

Das ist bis zum Sunscreen FHE-Compiler. Es handelt sich um einen nativen Web3-Compiler, der einige der besten Leistungen für arithmetische Operationen (denken Sie an DeFi) ohne Hardwarebeschleuniger bietet. Wie oben erläutert, ist die Parameterauswahl wohl der schwierigste Teil bei der Implementierung eines FHE-Schemas; Sunscreen verfügt nicht nur über eine automatisierte Parameterauswahl, sondern auch über Datenkodierung und Schlüsselauswahl, implementiert Relinearisierung und Modulumschaltung, richtet die Schaltkreise ein und implementiert SIMD-ähnliche Operationen.

Auf dem Weg in die Zukunft erwarten wir weitere Optimierungen nicht nur beim Sunscreen-Compiler, sondern auch bei anderen Teams, die ihre eigenen Implementierungen erstellen, die andere Hochsprachen unterstützen.

1. Neue FHE-Bibliothek

Während Forscher weiterhin neue leistungsstarke Schemata erforschen, können FHE-Bibliotheken mehr Entwicklern die Integration von FHE ermöglichen.

Nehmen wir als Beispiel FHE Smart Contracts. Obwohl es schwierig sein kann, aus verschiedenen FHE-Bibliotheken auszuwählen, wird es einfacher, wenn wir über On-Chain-FHE sprechen, da es in Web3 nur wenige dominierende Programmiersprachen gibt.

Beispielsweise integriert fhEVM von Zama Zamas Open-Source-Bibliothek TFHE-rs in eine typische EVM und stellt homomorphe Operationen als vorkompilierte Verträge bereit. Dadurch können Entwickler effektiv verschlüsselte Daten in ihren Verträgen verwenden, ohne dass Änderungen an den Kompilierungstools erforderlich sind.

Für andere spezifische Szenarien ist möglicherweise eine andere Infrastruktur erforderlich. Beispielsweise wird die in C++ geschriebene TFHE-Bibliothek nicht so gut gepflegt wie die Rust-Version. Obwohl TFHE-rs Exporte für C/C++ unterstützen können, müssen C++-Entwickler eine eigene Version der TFHE-Bibliothek schreiben, wenn sie eine bessere Kompatibilität und Leistung wünschen.

Schließlich ist ein Hauptgrund für den Mangel an FHE-Infrastruktur auf dem Markt, dass es uns an effizienten Möglichkeiten zum Aufbau von FHE-RAM mangelt. Eine mögliche Lösung besteht darin, an einem FHE-EVM ohne bestimmte Opcodes zu arbeiten.

Sichere Schwellenwert-Entschlüsselung

Herausforderung: Unsichere/zentralisierte Schwellenwert-Entschlüsselung

Jedes vertrauliche, gemeinsam genutzte Zustandssystem basiert auf einem Verschlüsselungs-/Entschlüsselungsschlüssel. Da keiner einzelnen Partei vertraut werden kann, wird der Entschlüsselungsschlüssel unter den Netzwerkteilnehmern aufgeteilt.

Einer der anspruchsvollsten Aspekte von On-Chain-FHE (Threshold FHE) ist der Aufbau eines sicheren und leistungsfähigen Schwellenwert-Entschlüsselungsprotokolls. Es gibt zwei Hauptengpässe: (1) FHE-basierte Berechnungen führen zu einem erheblichen Overhead und erfordern daher leistungsstarke Knoten, was zwangsläufig die potenzielle Größe des Validatorsatzes verringert. (2) Mit zunehmender Anzahl der am Entschlüsselungsprotokoll teilnehmenden Knoten erhöht sich die Latenz.

Zumindest im Moment stützen sich FHE-Protokolle auf eine ehrliche Mehrheit unter den Validatoren. Wie oben erwähnt, impliziert Threshold FHE jedoch einen kleineren Validatorsatz und daher eine höhere Wahrscheinlichkeit von Absprachen und böswilligem Verhalten.

Was passiert, wenn die Schwellenknoten zusammenarbeiten? Sie wären in der Lage, das Protokoll zu umgehen und im Grunde alles zu entschlüsseln, von Benutzereingaben bis hin zu jeglichen On-Chain-Daten. Darüber hinaus ist es wichtig zu beachten, dass das Entschlüsselungsprotokoll in aktuellen Systemen unbemerkt erfolgen kann (auch „stiller Angriff“ genannt).

Lösung: Verbesserte Schwellenwertentschlüsselung oder dynamisches MPC

Es gibt einige Möglichkeiten, möglicherweise die Mängel der Schwellenwertentschlüsselung zu beheben. (1) Aktivieren Sie einen n/2-Schwellenwert, der Absprachen erschweren würde. (2) Führen Sie das Schwellenwert-Entschlüsselungsprotokoll innerhalb eines HSM aus. (3) Verwenden Sie ein TEE-basiertes Schwellenwert-Entschlüsselungsnetzwerk, das von einer dezentralen Kette für die Authentifizierung gesteuert wird und Dynamik ermöglicht Schlüsselverwaltung.

Anstatt die Schwellenwertentschlüsselung zu nutzen, ist es möglich, stattdessen MPC zu verwenden. Ein Beispiel für ein MPC-Protokoll, das in On-Chain-FHE verwendet werden könnte, ist Odsys neuer 2PC-MPC, der erste nicht kollusive und massiv dezentralisierte MPC-Algorithmus.

Ein anderer Ansatz könnte darin bestehen, nur den öffentlichen Schlüssel des Benutzers zum Verschlüsseln der Daten zu verwenden. Die Validatoren verarbeiten dann die homomorphen Operationen und die Benutzer können das Ergebnis bei Bedarf selbst entschlüsseln. Obwohl dies nur für Nischenanwendungsfälle möglich ist, könnten wir die Schwellenwertannahme ganz vermeiden.

Zusammenfassend lässt sich sagen, dass On-Chain-FHE eine effiziente MPC-Implementierung benötigt, die: (1) auch dann funktioniert, wenn böswillige Akteure vorhanden sind, (2) eine minimale Latenz einführt und (3) den erlaubnislosen/flexiblen Zugriff auf Knoten ermöglicht.

Zero-Knowledge-Proof (ZKP) für Benutzereingaben und Computer

Herausforderung: Überprüfbarkeit von Benutzereingaben + Berechnung:

Wenn wir in web2 die Ausführung einer Rechenaufgabe anfordern, vertrauen wir voll und ganz darauf, dass ein bestimmtes Unternehmen die Aufgabe genau so ausführen wird, wie es es hinter den Kulissen versprochen hat. In web3 ist das Modell komplett umgedreht; Anstatt uns auf den Ruf eines Unternehmens zu verlassen und einfach darauf zu vertrauen, dass es ehrlich handelt, arbeiten wir jetzt in einer vertrauenslosen Umgebung, was bedeutet, dass Benutzer niemandem vertrauen sollten.

Während FHE die Verarbeitung verschlüsselter Daten ermöglicht, kann es weder die Richtigkeit von Benutzereingaben noch von Berechnungen überprüfen. Ohne die Möglichkeit, beides zu überprüfen, ist FHE im Kontext der Blockchain kaum nützlich.

Lösung: ZKPs für Benutzereingaben + Rechenpartei:

Während FHE es jedem ermöglicht, beliebige Berechnungen an verschlüsselten Daten durchzuführen, ermöglichen ZKPs den Beweis, dass etwas wahr ist, ohne die zugrunde liegenden Informationen selbst preiszugeben. Wie hängen sie zusammen?

Es gibt drei wesentliche Möglichkeiten, wie FHE und ZKPs zusammenpassen:

1. Der Benutzer muss einen Nachweis vorlegen, dass sein eingegebener Chiffretext wohlgeformt ist. Das bedeutet, dass der Chiffretext die Anforderungen des Verschlüsselungsschemas erfüllt und nicht nur aus willkürlichen Datenzeichenfolgen besteht.
2. Der Benutzer muss einen Nachweis vorlegen, dass sein eingegebener Klartext die Bedingungen einer bestimmten Anwendung erfüllt. Ex. Betrag_Kontostand > Betrag_Überweisung
3. Der Validierungsknoten (auch Computerpartei genannt) muss nachweisen, dass er die FHE-Berechnung korrekt ausgeführt hat. Dies wird als „überprüfbarer FHE“ bezeichnet und kann als Analogie zu den für Rollups benötigten ZKPs angesehen werden.

Um die Anwendungen von ZKP weiter zu erkunden:

1. ZKP von Geheimtext

FHE basiert auf gitterbasierter Kryptographie, was bedeutet, dass die Konstruktion des kryptografischen Grundelements Gitter umfasst, die PQ-sicher (Post-Quantum) sind. Im Gegensatz dazu basieren beliebte ZKPs wie SNARKS, STARKS und Bulletproofs nicht auf gitterbasierter Kryptographie.

Um zu beweisen, dass der FHE-Chiffretext des Benutzers wohlgeformt ist, müssen wir zeigen, dass er eine Matrix-Vektor-Gleichung mit Einträgen aus Ringen erfüllt und dass die numerischen Werte dieser Elemente klein sind. Im Wesentlichen benötigen wir ein kostengünstiges On-Chain-Verifizierungssystem, das für die Handhabung gitterbasierter Beziehungen ausgelegt ist, was ein offenes Forschungsgebiet ist.

1. ZKP der Klartexteingabe

Zusätzlich zum Nachweis eines wohlgeformten Chiffretextes muss der Benutzer nachweisen, dass sein eingegebener Klartext die Anforderungen einer Anwendung erfüllt. Glücklicherweise können wir im Gegensatz zum vorherigen Schritt allgemeine SNARKs verwenden, um die Gültigkeit von Benutzereingaben nachzuweisen, sodass Entwickler die vorhandenen ZKP-Schemata, Bibliotheken und Infrastruktur nutzen können.

Die Herausforderung besteht jedoch darin, dass wir die beiden Beweissysteme „verbinden“ müssen. Verbinden wie in: Wir müssen sicherstellen, dass der Benutzer für beide Beweissysteme dieselben Eingaben verwendet hat. Andernfalls könnte ein böswilliger Benutzer das Protokoll betrügen. Dies ist wiederum eine unglaublich schwierige kryptografische Leistung und ein offenes Feld früher Forschung.

Sunscreen hat auch mit seinem ZKP-Compiler den Grundstein gelegt, der Bulletproofs unterstützt, da er sich am einfachsten mit SDLP verbinden lässt. Zukünftige Entwicklungen werden durchgeführt, um den FHE- und ZKP-Compiler zu „verknüpfen“.

Mind Network leistet Pionierarbeit bei der Integration von ZKPs, um Zero-Trust-Ein- und -Ausgaben zu gewährleisten und gleichzeitig FHE für sichere Berechnungen zu nutzen.

1. ZKP der korrekten Berechnung

Der Betrieb von FHE auf vorhandener Hardware ist äußerst ineffizient und teuer. Wie wir die Dynamik des Skalierbarkeitstrilemmas bereits gesehen haben, können Netzwerke mit höheren Knotenressourcenanforderungen nicht auf ein ausreichendes Maß an Dezentralisierung skaliert werden. Eine mögliche Lösung könnte ein Prozess namens „Verifiable FHE“ sein, ein Prozess, bei dem die Computerpartei (Validator) einen ZKP einreicht, um die ehrliche Ausführung von Transaktionen nachzuweisen.

Ein früher Prototyp eines überprüfbaren FHE kann von einem Projekt namens SherLOCKED ausgestellt werden. Im Wesentlichen wird die FHE-Berechnung auf Risc ZEROs Bonsai ausgelagert, der die Berechnung über die verschlüsselten Daten außerhalb der Kette verarbeitet, das Ergebnis mit einem ZKP zurückgibt und den Status in der Kette aktualisiert.

Ein aktuelles Beispiel für die Nutzung eines FHE-Coprozessors ist die On-Chain-Auktionsdemo von Aztec. Wie bereits erwähnt, verschlüsseln bestehende FHE-Ketten den gesamten Zustand mit einem Schwellenwertschlüssel, was bedeutet, dass das System nur so stark ist wie sein Schwellenwertausschuss. Umgekehrt sind bei Aztec die Daten des Benutzers seine eigenen und unterliegen daher keinem Schwellenwert für die Sicherheit.

Abschließend ist es wichtig, zunächst anzusprechen, wo ein Entwickler überhaupt eine FHE-Anwendung erstellen kann. Entwickler können ihre Anwendungen entweder auf einem FHE-basierten L1, einem FHE-Rollup oder auf einer beliebigen EVM-Kette aufbauen und einen FHE-Coprozessor nutzen. Jedes Design bringt seine eigenen Kompromisse mit sich, wir neigen jedoch eher zu gut gestalteten FHE-Rollups (Pionier von Fhenix) oder FHE-Coprozessoren, da sie neben anderen Vorteilen auch die Sicherheit von Ethereum übernehmen.

Bis vor kurzem war es komplex, Betrugsnachweise für FHE-verschlüsselte Daten zu erhalten, aber kürzlich hat das Team von Fhenix.io demonstriert, wie man mithilfe des Arbitrum Nitro-Stacks gepaart mit der FHE-Logikkompilierung für WebAssembly Betrugsnachweise erhält.

Datenverfügbarkeitsschicht (DA) von FHE

Herausforderung: Mangelnde Anpassbarkeit und mangelnder Durchsatz

Während Speicher in Web2 zur Massenware geworden ist, gilt dies nicht für Web3. Angesichts der Tatsache, dass FHE eine große Datenmenge von mehr als 10.000x aufweist, müssen wir herausfinden, wo große FHE-Chiffretexte gespeichert werden sollen. Wenn jeder Knotenbetreiber in einer bestimmten DA-Schicht die Daten jeder FHE-Kette herunterladen und speichern würde, könnten nur institutionelle Betreiber mit der Nachfrage Schritt halten und riskieren eine Zentralisierung.

Was den Durchsatz angeht, erreicht Celestia eine Höchstgeschwindigkeit von 6,7 MB/s. Wenn wir FHEML in irgendeiner Form ausführen möchten, benötigen wir problemlos n GB/s+/s. Laut aktuellen Daten, die von 1k(x) geteilt werden, können bestehende DA-Schichten FHE aufgrund von Designentscheidungen, die den Durchsatz (absichtlich) begrenzen, nicht unterstützen.

Lösung: Horizontale Skalierung + Anpassbarkeit

Wir brauchen eine DA-Schicht, die horizontale Skalierbarkeit unterstützen kann. Bestehende DA-Architekturen geben alle Daten an jeden Knoten im Netzwerk weiter, was eine große Einschränkung für die Skalierbarkeit darstellt. Umgekehrt speichert bei horizontaler Skalierbarkeit jeder Knoten 1/ntel der Daten, wenn mehr DA-Knoten in das System eintreten, was die Leistung und die Kosten verbessert, da mehr Blockspeicherplatz zur Verfügung steht.

Unabhängig davon wäre es angesichts der erheblichen Datenmenge, die mit FHE verbunden ist, sinnvoll, Entwicklern ein höheres Maß an Anpassbarkeit rund um die Erasure-Coding-Schwellenwerte zu bieten. dh Mit welchem Umfang des DA-Systems fühlen Sie sich bei einer Garantie wohl? Ob anteilsbasierte Gewichtung oder dezentralisierungsbasierte Gewichtung.

Die Architektur von EigenDA dient als Grundlage dafür, wie eine DA-Schicht für FHE aussehen könnte. Seine Eigenschaften der horizontalen Skalierung, der strukturellen Kostenreduzierung, der Entkopplung von DA und Konsens usw. führen zu einem Maß an Skalierbarkeit, das eines Tages FHE unterstützen könnte.

Schließlich könnte eine übergeordnete Idee darin bestehen, optimierte Speicherplätze für die Speicherung von FHE-Chiffretexten zu bauen, da Chiffretexte einem bestimmten Kodierungsschema folgen. Optimierte Speicherplätze könnten also zu einer effizienten Speichernutzung und einem schnelleren Abruf beitragen.

Vollständig homomorphe Verschlüsselungshardware (FHE).

Herausforderung: FHE-Hardware mit geringer Leistung

Bei der Förderung von FHE-Anwendungen (Fully Homomorphic Encryption) in der Kette ist die erhebliche Latenz aufgrund des Rechenaufwands ein großes Problem, was die Ausführung von FHE auf jeder Standardverarbeitungshardware unpraktisch macht. Diese Einschränkung ergibt sich aus der großen Interaktion mit dem Speicher aufgrund der riesigen Datenmenge, die der Prozessor verarbeiten muss. Neben Speicherinteraktionen verursachen auch komplexe Polynomberechnungen und zeitaufwändige Operationen zur Geheimtextpflege einen hohen Overhead.

Um den Zustand von FHE-Beschleunigern besser zu verstehen, müssen wir den Designraum aufdecken: anwendungsspezifische FHE-Beschleuniger im Vergleich zu generalisierbaren FHE-Beschleunigern.

Der Kern der Rechenkomplexität und des Hardwaredesigns für FHE hängt immer mit der Anzahl der für eine bestimmte Anwendung erforderlichen Multiplikationen zusammen, die als „Tiefe der homomorphen Operation“ bezeichnet wird. Im anwendungsspezifischen Fall ist die Tiefe bekannt, sodass die Systemparameter und die damit verbundene Berechnung festgelegt sind. Daher ist das Hardwaredesign für diesen anwendungsspezifischen Fall einfacher und kann normalerweise für eine bessere Leistung optimiert werden als das verallgemeinerbare Beschleunigerdesign. Im allgemeinen Fall, in dem FHE eine beliebige Anzahl von Multiplikationen unterstützen muss, ist Bootstrapping erforderlich, um einen Teil des bei den homomorphen Operationen angesammelten Rauschens zu entfernen. Bootstrapping ist teuer und erfordert beträchtliche Hardwareressourcen, einschließlich On-Chip-Speicher, Speicherbandbreite und Rechenleistung, was bedeutet, dass sich das Hardwaredesign stark vom anwendungsspezifischen Design unterscheidet. Obwohl die Arbeit großer Akteure in diesem Bereich, darunter Intel, Duality, SRI, DARPA und viele andere, mit ihren GPU- und ASIC-basierten Designs zweifellos an die Grenzen geht, ist sie möglicherweise nicht 1:1 anwendbar Unterstützung von Blockchain-Anwendungsfällen.

Zu den Entwicklungskosten: Generalisierbare Hardware erfordert mehr Kapital für die Entwicklung und Herstellung als anwendungsspezifische Hardware, aber ihre Flexibilität ermöglicht den Einsatz der Hardware in einem breiteren Anwendungsbereich. Wenn sich beim App-spezifischen Design andererseits die Anforderungen einer Anwendung ändern und Unterstützung für tiefere homomorphe Berechnungen erfordern, müsste die App-spezifische Hardware mit einigen Softwaretechniken wie MPC kombiniert werden, um das gleiche Ziel zu erreichen generalisierbare Hardware.

Es ist wichtig zu beachten, dass On-Chain-FHE weitaus schwieriger zu beschleunigen ist als anwendungsspezifische Anwendungsfälle (z. B. FHEML), da es die Fähigkeit erfordert, allgemeinere Berechnungen im Vergleich zu einem Nischensatz zu verarbeiten. Zur Veranschaulichung: fhEVM devnet ist derzeit auf einstellige TPS beschränkt.

Da wir einen auf Blockchain zugeschnittenen FHE-Beschleuniger benötigen, stellt sich eine weitere Überlegung: Wie übertragbar ist die Arbeit von ZKP-Hardware auf FHE-Hardware?

Es gibt einige gemeinsame Module zwischen ZKP und FHE, wie etwa die zahlentheoretische Transformation (NTT) und die zugrunde liegenden Polynomoperationen. Die in diesen beiden Fällen verwendete Bitbreite von NTT ist jedoch unterschiedlich. In ZKP muss die Hardware einen großen Bereich an Bitbreiten für NTT unterstützen, beispielsweise 64-Bit und 256-Bit, während in FHE die Operanden für NTT kürzer sind, da sie im Restzahlensystem dargestellt werden. Zweitens ist der Umfang der im ZKP behandelten NTT im Allgemeinen höher als im FHE-Fall. Aus diesen beiden Gründen ist es nicht einfach, ein NTT-Modul zu entwerfen, das sowohl für ZKP als auch für FHE eine zufriedenstellende Leistung erzielt. Abgesehen von NTT gibt es in FHE einige andere Rechenengpässe, wie z. B. Automorphismus, die in ZKPs nicht vorhanden sind. Eine naive Möglichkeit, ZKP-Hardware auf die FHE-Einstellung zu übertragen, besteht darin, die NTT-Rechenaufgabe auf die ZKP-Hardware auszulagern und die CPU oder andere Hardware für die restliche Berechnung in FHE zu verwenden.

Um die Herausforderungen abzurunden, war die Berechnung verschlüsselter Daten mit FHE früher 100.000-mal langsamer als die Berechnung von Klartextdaten. Dank der neueren Verschlüsselungsschemata und der jüngsten Entwicklungen bei der FHE-Hardware hat sich die aktuelle Leistung jedoch dramatisch verbessert und ist etwa 100-mal langsamer als bei Klartextdaten.

Lösungen:

1. Verbesserung der FHE-Hardware

Es gibt viele Teams, die aktiv an der Entwicklung von FHE-Beschleunigern arbeiten. Sie arbeiten jedoch nicht an FHE-Beschleunigern, die spezifisch für verallgemeinerbare Blockchain-Berechnungen sind (d. h TFHE). Ein Beispiel für einen Blockchain-spezifischen Hardwarebeschleuniger ist FPT, ein Fixed-Point-FPGA-Beschleuniger. FPT ist der erste Hardwarebeschleuniger, der das in FHE-Berechnungen vorhandene inhärente Rauschen stark ausnutzt, indem er TFHE-Bootstrapping vollständig mit angenäherter Festkomma-Arithmetik implementiert. Ein weiteres Projekt, das für FHE nützlich sein könnte, ist BASALISC, eine Architekturfamilie von Hardwarebeschleunigern, die darauf abzielt, FHE-Berechnungen in der Cloud erheblich zu beschleunigen.

Wie bereits erwähnt, ist einer der größten Engpässe beim FHE-Hardwaredesign die massive Interaktion mit dem Speicher. Um diese Barriere zu umgehen, besteht eine mögliche Lösung darin, die Interaktion mit dem Gedächtnis so weit wie möglich zu reduzieren. Die Processing-in-Memory (PIM) oder Near-Memory-Berechnung ist in diesem Szenario wahrscheinlich hilfreich. PIM ist eine vielversprechende Lösung zur Bewältigung der „Memory Wall“-Herausforderungen für zukünftige Computersysteme, die es dem Speicher ermöglicht, sowohl Rechen- als auch Speicherfunktionen zu erfüllen, was eine radikale Erneuerung der Beziehung zwischen Berechnung und Speicher verspricht. Im letzten Jahrzehnt wurden enorme Fortschritte bei der Entwicklung nichtflüchtiger Speicher für diesen Zweck erzielt, wie z. B. Widerstands-RAM, Spin-Transfer-Drehmoment-Magnet-RAM und Phasenwechselspeicher. Unter Verwendung dieses speziellen Speichers wurden Arbeiten durchgeführt, die erhebliche Rechenverbesserungen beim maschinellen Lernen und der gitterbasierten Public-Key-Verschlüsselung zeigten.

1. Optimierte Software und Hardware

In jüngsten Entwicklungen wurde Software als entscheidende Komponente im Hardwarebeschleunigungsprozess anerkannt. Beispielsweise verwenden bekannte FHE-Beschleuniger wie F1 und CraterLake Compiler für einen hybriden Software-/Hardware-Co-Design-Ansatz.

Mit der Weiterentwicklung des Weltraums können wir davon ausgehen, dass voll funktionsfähige Compiler gemeinsam mit Blockchain-spezifischen FHE-Compilern entwickelt werden. FHE-Compiler können FHE-Programme basierend auf dem Kostenmodell des jeweiligen FHE-Schemas optimieren. Diese FHE-Compiler könnten in FHE-Beschleuniger-Compiler integriert werden, um die End-to-End-Leistung durch die Einbeziehung eines Kostenmodells auf Hardwareebene zu verbessern.

1. Vernetzung von FHE-Beschleunigern: Der Wandel vom Scale-up zum Scale-out

Bestehende FHE-Hardwarebeschleunigungsbemühungen konzentrieren sich größtenteils auf „Scale-up“, was bedeutet, dass man sich auf die vertikale Verbesserung eines einzelnen Beschleunigers konzentriert. Andererseits liegt der Schwerpunkt beim „Scale-out“ auf der Verbindung mehrerer FHE-Beschleuniger durch horizontale Vernetzung, was die Leistung drastisch verbessern könnte, ähnlich wie bei der parallelen Proof-Generierung mit ZKPs.

Eine der Hauptschwierigkeiten bei der FHE-Beschleunigung ist das Problem der Dateninflation: Bezieht sich auf die erhebliche Zunahme der Datengröße, die während der Verschlüsselung und Berechnung auftritt, was eine Herausforderung für die effiziente Datenbewegung zwischen On-Chip- und Off-Chip-Speichern darstellt.

Die Dateninflation stellt eine erhebliche Herausforderung für die horizontale Vernetzung mehrerer FHE-Beschleuniger dar. Daher wird das gemeinsame Design von FHE-Hardware und Netzwerk eine vielversprechende Richtung zukünftiger Forschung sein. Ein Beispiel könnte ein adaptives Netzwerk-Routing für FHE-Beschleuniger sein: Implementierung eines Routing-Mechanismus, der Datenpfade zwischen FHE-Beschleunigern basierend auf der Echtzeit-Rechenlast und dem Netzwerkverkehr dynamisch anpasst. Dies würde optimale Datenübertragungsraten und eine effiziente Ressourcennutzung gewährleisten.

Abschluss

FHE wird die Art und Weise, wie wir Daten plattformübergreifend sichern, grundlegend neu überdenken und den Weg für eine neue Ära beispielloser Privatsphäre ebnen. Der Aufbau eines solchen Systems erfordert erhebliche Fortschritte nicht nur bei FHE, sondern auch bei ZKPs und MPC.

Wenn wir uns in diese neuen Grenzen vorwagen, werden gemeinsame Anstrengungen zwischen Kryptographen, Software-Ingenieuren und Hardware-Spezialisten unerlässlich sein. Ganz zu schweigen von Gesetzgebern, Politikern usw., denn die Einhaltung gesetzlicher Vorschriften ist der einzige Weg zur allgemeinen Akzeptanz.

Letztendlich wird FHE an der Spitze einer transformativen Welle digitaler Souveränität stehen und eine Zukunft einläuten, in der Datenschutz und Sicherheit sich nicht mehr gegenseitig ausschließen, sondern untrennbar miteinander verbunden sind.

Besonderen Dank:

Vielen Dank an Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) für die Rezension. Wir freuen uns darauf, von der beeindruckenden Arbeit und den Bemühungen zu lesen, die diese Personen in diesem Bereich leisten!

Haftungsausschluss:

1. Dieser Artikel wurde von [HashKey Capital] nachgedruckt. Alle Urheberrechte liegen beim ursprünglichen Autor [Jeffrey Hu、Arnav Pagidyala]. Wenn Sie Einwände gegen diesen Nachdruck haben, wenden Sie sich bitte an das Gate Learn- Team, das sich umgehend darum kümmern wird.
2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verbreiten oder Plagiieren der übersetzten Artikel verboten.