Secret 2.0: Aufbau der nächsten Generation von Web3-Datenschutz
Neue kryptographische Lösungen, Companion-Netzwerke, Enklavenverstärkungen und mehr. Werfe einen ersten Blick auf Secret 2.0, eine gewaltige Weiterentwicklung unserer Architektur als Datenschutz-Hub für Web3!
Hallo an die Community!
Heute schreibe ich, um über die Vergangenheit, Gegenwart und Zukunft von Secret Network zu sprechen — und um einige Pläne zu teilen, die bis jetzt noch nie geteilt wurden.
Das Secret-Ökosystem war schon immer stolz auf unsere Fähigkeit, schnell zu iterieren und an der Spitze pragmatischer Technologien zum Schutz der Privatsphäre zu stehen, die in der Produktion eingesetzt werden können. Vor sieben Jahren waren wir das erste Team, das überhaupt über Datenschutz für Web3 sprach, als ich meine ursprünglichen Whitepaper veröffentlichte (einschließlich „Decentralizing Privacy“, jetzt mit über 2.000 Zitaten und dem derzeit am häufigsten zitierten Papier über Datenschutz in der Blockchain). Vor über zwei Jahren wurde Secret der erste die Privatsphäre wahrende Smart Contract L1, was auch noch bis heute gilt.
Aber da Secret Network zusammen mit Web3 selbst wächst, ist es an der Zeit, über unsere Vision für Privatsphäre nachzudenken und sicherzustellen, dass wir immer an der Spitze von Forschung und Entwicklung stehen. Wir wollen nie in einem lokalen Maximum stecken bleiben; Vielmehr wollen wir immer Marktführer bei Web3-Datenschutzlösungen sein, die in der Produktion aktiv sind. Wir wollen unsere Lösungen immer sicherer, leistungsstärker, schneller und kostengünstiger machen — insbesondere bei steigender Akzeptanz.
Wir bezeichnen die gesamte Entwicklung bis zu diesem Punkt als „Secret 1.0“: eine lebende Layer-1-Blockchain und ein relativ ausgereiftes Ökosystem von Anwendungen zur Wahrung der Privatsphäre in der Produktion. Heute sprechen wir über „Secret 2.0“: Wohin neue Forschung und Entwicklung das Ökosystem als nächstes führt.
Eine vollständige Veröffentlichung der kollektiven Secret 2.0-Vision würde ein ausführliches Whitepaper erfordern, das alles von technischen Details bis hin zu wirtschaftlichen Aspekten enthält. Heute ist nicht diese Veröffentlichung. Aber in diesem Beitrag möchte ich ein paar wichtige Teile einer Roadmap teilen, um die Datenschutzlösungen von Secret noch weiter zu verbessern:
- Erstellung eines Companion-Netzwerks, Threshold Fully Homomorphic Encryption (FHE) Layer-1, das zusammen mit Enklaven eine erstklassige Datenschutzlösung bietet.
- Stärkung von SGX (und anderen unterstützten Enklaven) unter Verwendung sowohl kryptografischer Techniken als auch praktischer Engineering-Techniken
Mit diesen Verbesserungen sieht die Zukunft von Secret eher wie eine leuchtende Konstellation miteinander verbundener Datenschutzlösungen aus und nicht wie ein einzelner Stern. Werfen wir einen Blick auf die beiden oben genannten strategischen Pfade und wie sie dazu beitragen werden, Secret als Datenschutzzentrum für das gesamte Web3 zu definieren!
Am Ende dieses Beitrags werden wir auch einen Aufruf zum Handeln für Forscher, Entwickler und Partner einfügen, die daran interessiert sind, zu Secret 2.0 beizutragen. Wenn Sie ein unabhängiger Forscher, Entwickler oder ein Team sind, das daran interessiert ist, sich diesen Bemühungen anzuschließen, wenden Sie sich bitte per E-Mail an SCRT Labs: info@scrtlabs.com
Möchtet ihr mehr darüber erfahren, wo Secret bereits heute ist? Taucht hier ein.
Threshold Fully Homomorphic Encryption (FHE) für Secret Contracts
Wir haben immer gesagt, dass die Mission von Secret darin besteht, die pragmatischsten und praktischsten Datenschutzlösungen in Produktionssysteme zu bringen. Datenschutz ist zu wichtig, um nur in einem akademischen Rahmen diskutiert zu werden — das wird von den Benutzern heute benötigt. Wir behalten jedoch alle neuen akademischen Fortschritte sehr genau im Auge, um zu verstehen, wann und wie neue Lösungen in der Produktion zum Nutzen von Entwicklern und Benutzern eingesetzt werden könnten. Sicherheit ist ein sich ständig weiterentwickelnder Bereich!
Wir haben in der Vergangenheit kommentiert, dass sichere Enklaven die einzige Technologie waren (und wirklich immer noch sind), die derzeit für den Einsatz in einem verallgemeinerbaren Smart-Contract-Netzwerk bereit ist. Enklaven bieten eine schnellere Leistung bei geringeren Kosten für mehr Anwendungsfälle. Aus diesem Grund haben wir uns in Secret 1.0 auf ihre Verwendung konzentriert.
Wir haben jedoch immer darüber nachgedacht, wie die Kombination mehrerer Technologien zu besseren produktionsreifen Lösungen führen könnte. Dank der jüngsten Fortschritte untersuchen wir jetzt die vollständig homomorphe Verschlüsselung (FHE) als ernsthafte Option zur Stärkung von Secret als Datenschutzzentrum.
Ein neues FHE-basiertes Companion-Netzwerk (Name wird noch bekannt gegeben) soll Secret sehr ähnlich aussehen und sich auch so anfühlen, und wir arbeiten derzeit an einer interessanten Möglichkeit, die beiden auf wechselseitig vorteilhafte Weise miteinander zu verbinden. Aber für den Zweck dieses Blogbeitrags möchte ich mich auf das technische Design einer solchen Kette konzentrieren und darauf, wie sie die sicherste Lösung zur Lösung des Datenschutzproblems bieten kann.
Das Netzwerk nutzt die vollständig homomorphe Verschlüsselung für den Datenschutz, ein Schema, mit dem man über verschlüsselte Daten rechnen kann. Im Wesentlichen behält es die Invariante bei:
FHE-Systeme haben die Leistung in den letzten Jahren sprunghaft verbessert, und der Trend scheint sich fortzusetzen. Durch die Verwendung von GPUs, FPGAs und schließlich ASICs können wir in den nächsten Jahren mit einer 1.000- bis 10.000-fachen Steigerung rechnen. Die Fortschritte sind vielversprechend und es gibt guten Grund zu der Annahme, dass FHE in relativ kurzer Zeit skalierbar genug werden kann.
Aber es gibt ein Problem. FHE selbst kann nur mit einem einzigen Schlüssel arbeiten, wie gehen wir also mit einer Mehrbenutzerumgebung um, wie dies bei Blockchains der Fall ist? Wir müssen im Wesentlichen eine Multi-Party-Computation (MPC)-Variante von FHE namens Threshold FHE verwenden. Wie der Name schon sagt, ermöglicht Threshold FHE jedem Server, beliebige Berechnungen über die verschlüsselten Daten auszuführen, aber um die Ausgabe zu entschlüsseln, muss eine bestimmte Schwelle von Knoten beim Entschlüsseln zusammenarbeiten.
Wie passt das also in unser Companion-Netzwerk? Im Wesentlichen können wir mit einem geeigneten Schwellenwert-FHE-Schema die Validatoren den geheimen Verschlüsselungsschlüssel untereinander teilen lassen. Dies kann ziemlich einfach mit einem einfachen DKG-Protokoll erreicht werden, das hocheffizient ist. Durch das proaktive Teilen von Secrets auf Mobilgeräten können wir im Wesentlichen Freigaben von Validatoren, die das Unternehmen verlassen, auf diejenigen verschieben, die beitreten. Der „proaktive“ Teil würde sicherstellen, dass ein Angreifer die Validatoren nicht im Laufe der Zeit langsam korrumpieren kann, da die Validatoren ihre Anteile des Schlüssels nach jeder bestimmten Anzahl von Blöcken aktualisieren müssen.
Mit diesem Setup ist das Senden einer Smart-Contract-Transaktion an das Netzwerk ziemlich trivial:
- Der Benutzer sendet eine Transaktion, die eine Funktion in einem bestimmten Vertrag aufruft, während er alle seine Daten mit dem öffentlichen Schlüssel des gemeinsamen Netzwerkschlüssels verschlüsselt.
- Alle Validatoren führen wie gewohnt einen Konsens durch, während sie die verschlüsselten Daten berechnen. Dies ähnelt im Grunde der Funktionsweise von Secret heute, außer dass die Berechnung direkt mit den verschlüsselten Daten durchgeführt wird, ohne sie in einer Enklave zu entschlüsseln.
- Mit diesem Schema können wir Eingabe-, Status- und Ausgabe-Privatsphäre erreichen, genau wie in Secret heute. (Für die Privatsphäre der Ausgabe sollten alle Validatoren ein Schlüsselwechselprotokoll ausführen, das eine Schwellwert-Proxy-Neuverschlüsselung durchführt, um die Ausgabe so umzuschalten, dass sie mit einem Schlüssel entschlüsselbar ist, der nur dem Benutzer bekannt ist.)
Ein wichtiger Hinweis ist, dass jeder Validator einen Anteil des Entschlüsselungsschlüssels entsprechend seinem Einsatz erhält. Es würde 67% der Staking-Power erfordern, um das Netzwerk zu entschlüsseln. Diese Zahl entspricht der Anzahl der Stimmen zur Genehmigung eines Blocks, daher ist sie sinnvoll.
Ein Problem bei diesem Design besteht darin, dass Validator geheime Absprachen treffen können, und Absprachen sind trivial und nicht nachweisbar (ein paar Codezeilen schreiben, die es Validatoren ermöglichen, die geheimen Schlüsselanteile außerhalb der Kette auszutauschen). Aus diesem Grund glauben wir, dass wir für diese Arbeit diese kryptografischen Techniken mit SGX oder einem ähnlichen TEE (idealerweise mehrere TEEs mit mehreren Architekturen) kombinieren müssen. Dadurch erhöhen wir die Angriffsbarriere — man muss jetzt alle Validatoren dazu bringen, Absprachen zu treffen, was bei TEE äußerst unwahrscheinlich wird.
Es ist jedoch auch wichtig zu beachten, dass es wahrscheinlich keine gute Idee ist, FHE innerhalb einer Enklave auszuführen. Wie bereits erwähnt, wird die Skalierung von FHE selbst auf die Unterstützung von GPUs, FPGAs oder ASICs angewiesen sein, was heute nicht mit Enklaven kompatibel ist. Glücklicherweise sollte leicht ersichtlich sein, dass wir den Schwellwert-Entschlüsselungsschlüssel immer nur im Falle eines Schlüsselwechsels oder einer Schwellwert-Entschlüsselung benötigen. Die gesamte tatsächliche verschlüsselte Berechnung kann außerhalb der Enklave erfolgen, was die Leistung erheblich verbessern würde. Auch bedeutet die Beschränkung der Enklaven selbst, sich auf das Speichern eines Schlüsselanteils zu konzentrieren und ein bestimmtes Schlüsselschalter-/Schwellwert-Entschlüsselungsprotokoll auszuführen, dass es viel einfacher wäre, diese Enklave vor möglichen Angriffen zu schützen.
Stärkung von SGX und anderen Enklaven
Die Einführung kryptografischer Lösungen wie FHE in unsere Datenschutzkonstellation wird das Angebot von Secret für Entwickler und Benutzer gleichermaßen erheblich verbessern. In der Zwischenzeit können wir jedoch noch viel mehr tun, um unser bestehendes Netzwerk zu härten — und seine Flexibilität für die Zukunft zu verbessern. Die meisten dieser Ideen befassen sich auch mit der Kombination von fortschrittlicherer Kryptografie mit SGX auf eine Weise, die die Vorteile sicherer Enklaven nutzt, sich aber nicht ausschließlich auf sie verlässt.
Thresholding des Hauptschlüssels
Ich habe kürzlich einen Forumsbeitrag geschrieben, in dem beschrieben wurde, wie wir ein aktuelles Papier von Momeni et al. nachrüsten können, das die identitätsbasierte Verschlüsselung (IBE) mit geheimer Weitergabe nutzt, um den Hauptschlüssel von Secret zu verteilen, der die Hauptquelle von ist Entropie, die zum Generieren von Verschlüsselungsschlüsseln für Benutzertransaktionen, Zustandsverschlüsselung, Intranet-Zufälligkeit usw. verwendet wird.
Die vorgeschlagene Idee teilt im Wesentlichen den aktuellen Hauptschlüssel, der in jeder Enklave vorhanden ist (und daher würde das Aufbrechen einer einzelnen Enklave ausreichen, um alle Daten zu entschlüsseln), in Anteile des Schlüssels auf, sodass man die Anteile von 67 % benötigen würde Validatoren, um den Schlüssel tatsächlich lernen zu können. Da alle diese Anteile auch in Enklaven leben, gilt das gleiche Argument wie bei der Threshold FHE-Kette oben: Die Notwendigkeit, die Enklaven des Großteils des Netzwerks aufzubrechen, ist wahrscheinlich in jeder Situation unpraktisch.
Der Secret gemeinsame Hauptschlüssel wird dann verwendet, um einen abgeleiteten Schlüssel für jeden Block zu generieren. Der interessante Teil ist, dass Benutzer den entsprechenden öffentlichen Schlüssel a priori und unabhängig für jeden Block generieren können, wodurch die clientseitige Verschlüsselung von Transaktionen wie heute nicht interaktiv bleibt. Darüber hinaus können alle Validatoren ihren abgeleiteten Anteil des geheimen Schlüssels auch unabhängig voneinander generieren und diesen als Teil des Konsensmechanismus für jeden Block anhängen. Das bedeutet, dass Enklaven den Schlüssel eines bestimmten Blocks gerade rechtzeitig lernen, um die Berechnungen auszuführen, aber sie lernen nie den Hauptschlüssel!
Wir können dieselbe mobile proaktive Secret-Sharing-Technik aus der FHE-Kette verwenden, um sicherzustellen, dass die Hauptschlüsselfreigaben regelmäßig aktualisiert und von alten Validatoren auf neue verschoben werden, um sowohl die Sicherheit als auch die Verfügbarkeit zu verbessern.
Forward Secrecy?
Das obige Schema verwendet im Wesentlichen homomorphe Verschlüsselung und Multi-Party Computation (MPC), um ein potenzielles Leck des Hauptschlüssels selbst in einer SGX-Katastrophe zu verhindern. In ähnlicher Weise schützt es besser vor Absprachen, für die alle MPC-Techniken anfällig sind, indem alle ihre Schlüsselanteile in ihrer Enklave gehalten werden.
Das ist großartig, aber es gibt noch eine große Herausforderung zu bewältigen. Validatoren lernen den Schlüssel eines Blocks einmal pro Block. Wenn ein Angreifer in einer kompromittierten Enklave sitzt, kann er langsam Schlüssel sammeln und Blöcke entschlüsseln. Dies ist immer noch begrenzt, wenn Sie davon ausgehen, dass es ein begrenztes Zeitfenster zwischen der Möglichkeit gibt, eine Enklave zu kompromittieren und sie zu reparieren. Im Laufe der Jahre, da Enklaven immer kampferprobter werden, sollten diese selten und unwahrscheinlich werden, aber sie sind immer noch eine Form des Angriffs. Vielleicht noch besorgniserregender ist, dass ein neuer Validator, der gerade erst anfängt und alle historischen Zustände verarbeiten möchte, sofort eine kompromittierte Enklave einnehmen und die gesamte Geschichte lernen kann.
Dieses Problem muss mit einer Form von Forward Secrecy für Blockchains zum Schutz der Privatsphäre angegangen werden und ist wahrscheinlich relevant, ob Sie Enklaven reiner kryptografischer Lösungen verwenden, die Schlüssel im Netzwerk speichern müssen. Vorwärtsgeheimnis bedeutet im Wesentlichen, dass jeder spezifische Schlüssel, der leckt, nicht mehr als ein bisschen Information preisgeben sollte (z. B. eine einzelne Transaktion oder einen Datenblock). Dies wird bis zu einem gewissen Grad durch meinen obigen Vorschlag erreicht, aber es sollte auch einen Mechanismus geben, der die Fähigkeit einschränkt, alle Schlüssel auf einmal abzurufen.
Dies ist derzeit ein offenes Forschungsthema, das wir untersuchen und andere Forscher einladen, mit uns zusammenzuarbeiten! Es hat möglicherweise auch viele andere Auswirkungen.
Two-Party Computations
Secret 1.0 hat eine sehr interessante und eigentümliche Eigenschaft — es kann private Daten speichern und verarbeiten, während es, wie jede Blockchain, sicherstellt, dass es den Vertragscode immer ordnungsgemäß ausführt. Außerdem ist sie, wie jede andere Blockchain, immer online.
Dies stellt eine wirklich interessante Art von Anwendungen dar, insbesondere für extrem sensible Daten wie Brieftaschen und kryptografische Schlüssel, Passwörter und Seeds, bei denen wir SGX vielleicht nicht vollständig vertrauen wollen — aber in ähnlicher Weise würden die Benutzer selbst dies nicht wollen darauf vertrauen, diese Schlüssel richtig zu verwalten.
Der interessanteste und nützlichste aktuelle Anwendungsfall, den wir dafür sehen, ist der von unaufhaltsamen Schwellenwert-Wallets, aber dies sollte nur als Beispiel dienen. Diese Brieftaschen teilen im Wesentlichen den Brieftaschenschlüssel zwischen einem Benutzer und Secret auf — jeder erhält einen Anteil. Auf Secret kann ein Benutzer eine Zugriffsrichtlinie definieren, sodass die Kette ein verdächtiges Verhalten bemerkt (z. B. wenn jemand versucht, ihre Brieftasche zu leeren) und es blockieren würde, wenn sein Schlüssel vollständig kompromittiert ist. Andererseits ist es ziemlich vernünftig anzunehmen, dass kein Angreifer in der Lage sein wird, sowohl die im Netzwerk gespeicherte Freigabe als auch den Anteil des Benutzers an der Brieftasche zu kompromittieren, insbesondere wenn wir weiterhin Techniken wie das proaktive Teilen von Geheimnissen verwenden, die die Freigaben nach und nach aktualisieren häufig.
Um diese Technik zu ermöglichen, müssten wir Unterstützung hinzufügen und mehrere Bausteine in Secret einbauen, wie z. B. additiv homomorphe Verschlüsselung und Threshold-Signing-Protokolle. Wir müssen sie nachrüsten, damit sie funktionieren, ohne in WASM für Leistungs-/Gaskostenprobleme kompiliert zu werden (ähnlich wie Ethereum es in der Vergangenheit mit der On-Chain-Verifizierung bestimmter Zero-Knowledge-Beweise getan hat). Ein solches Pilotprojekt ist derzeit mit einem Designpartner geplant.
Dies sollte eine viel größere Klasse von Zwei-Parteien-Berechnungen veranschaulichen, bei denen das sensible Material eines Benutzers zwischen dem Benutzer selbst und Secret aufgeteilt wird.
Was jetzt?
Hier werde ich wiederholen, was schon immer Teil unserer Mission als Secret Network war: pragmatische Datenschutzlösungen auf den Markt zu bringen, damit sie von Millionen von Benutzern weltweit in der Produktion eingesetzt werden können.
Das Secret-Ökosystem — von seinen Kernentwicklern über seine Validatoren bis hin zu seinen dApps und seinen leidenschaftlichen Benutzern — hat bewiesen, dass wir alles tun werden, um sicherzustellen, dass unsere Vision einer sichereren Web3-Zukunft Wirklichkeit wird. Das bedeutet, dass wir in den letzten Jahren Anwendungen entwickelt und genutzt haben, die auf dem neuesten Stand unserer Branche sind. Jetzt bitten wir euch, uns anzuschließen, während wir unser Netzwerk von seiner ersten Iteration bis zu seiner nächsten, leistungsstärkeren Form stärken: eine Konstellation miteinander verbundener Datenschutzlösungen, die das kollektive Fundament immer stärker macht.
Es gibt viele andere Themen, die wir in diesem Beitrag hätten ansprechen können, darunter die vertikale Skalierung über Rollups, die horizontale Skalierung über IBC und vieles mehr. Dies ist nur ein erster Blick auf Secret 2.0, das ein hochkomplexes Unterfangen sein wird, das erhebliche Anstrengungen der Community beinhaltet.
Heute haben wir Dutzende von Live-dApps, die standardmäßig privat sind und Secret Network nutzen; in ein paar Jahren wollen wir Tausende haben. Heute haben wir 250.000 Konten auf Secret; Wir wollen viele Millionen mehr hinzufügen. Durch die Kombination dieser technischen Verbesserungen mit einem aggressiven Ansatz für Entwickler- und Benutzerwachstum können wir sicherstellen, dass jeder Web3-Benutzer Zugang zu starken Datenschutzlösungen hat.
Ein stärker dezentralisiertes Internet erfordert, dass die Privatsphäre wirklich ermächtigt. In ähnlicher Weise erfordern Datenschutzlösungen eine Dezentralisierung, um nachhaltig zu sein. Secret Network ist der Schnittpunkt von Dezentralisierung und Datenschutz — und bietet Benutzern jetzt und in Zukunft die richtige Grundlage.
Unsere Kontakte
Vieles von dem, was oben vorgeschlagen wurde, ist bereits ein aktiver Bereich der Forschung und Entwicklung, aber wir sind ständig auf der Suche nach den allerbesten Partnern, während wir dieses Ziel der globalen Einführung weiter verfolgen. Wenn Sie ein unabhängiger Forscher, Entwickler oder ein Team sind, das daran interessiert ist, sich diesen Bemühungen anzuschließen oder an einem Joint Venture teilzunehmen, wenden Sie sich bitte per E-Mail an SCRT Labs: info@scrtlabs.com
Secret Network bietet auch Zuschüsse und andere Ressourcen für Entwickler an, die zu unserer Datenschutzmission beitragen möchten. Wenn ihr daran interessiert seid, eure eigenen Secret Apps zu erstellen, seht euch unsere Ressourcen für Entwickler an und erfahrt, wie ihr Fördermittel zur Unterstützung eurer Projekte erhalten könnt!
Wenn ihr euch leidenschaftlich dafür einsetzt, sicherzustellen, dass Web3-Benutzer den Datenschutz erhalten, den sie benötigen und verdienen, werdet Secret Agenten! Es ist unsere Mission, sicherzustellen, dass das dezentrale Web, das wir aufbauen, eines ist, das wirklich ermächtigt — und eines, das für alle zugänglich ist. Von Sensibilisierung und Bildung bis hin zu internationalem Wachstum und Universitäts-Beziehungen gibt es viele Möglichkeiten, das Secret-Ökosystem und die globale Verfügbarkeit von Datenschutztechnologien im Web3 zu erweitern.
Schaut euch das Secret Agents-Programm an und tretet einer der besten und engagiertesten Communities im gesamten Blockchain-Bereich bei!
Vorwärts und aufwärts!
Um über Secret Network und Secret Apps zu diskutieren, besucht unsere Community-Kanäle:
