Das Aptos-Mainnet wird sehr bald 🔒 vertrauliche Vermögenswerte 💸 ermöglichen!! d.h. verschlüsselte Salden & Transaktionsbeträge 🔐, jedoch mit öffentlich sichtbaren 🌍 Absender- & Empfängeradressen! (Einen Schritt nach dem anderen, Leute...) So funktionieren sie! 🤓👇

Aptos vertrauliche Vermögenswerte bauen auf früheren Arbeiten auf und erweitern diese. Wir verschlüsseln Salden on-chain mit Twisted ElGamal, ähnlich wie PGC (). Dies lässt sich gut mit Bulletproofs kombinieren, um zu beweisen, dass ein verschlüsselter Saldo nach einem vertraulichen Senden/Abheben korrekt belastet wurde.

Oder, wie ich oft zu sagen pflege [und dafür mittlerweile ausgelacht werde]... "Sieh dir meinen Blog an!"

*Merkmal 1:* Im Gegensatz zu PGC und Solana sind unsere Twisted ElGamal-Ciphertexts _aggressiv in Blöcke unterteilt_, um eine super-schnelle Entschlüsselung bei der Verarbeitung von Salden und Beträgen von ~256 Bit zu gewährleisten. Wir nennen dies *chunked'n'twisted ElGamal.* Übrigens benötigt Aptos nur 128-Bit-Salden und 64-Bit-Beträge.

Für Aptos garantiert Chunking, dass die maximale diskrete Logarithmus (DL) Instanz, die während der Entschlüsselung gelöst werden muss, im schlimmsten Fall 32-Bit beträgt (und im Durchschnitt viel kleiner ist). => leicht lösbar in 2^16 elliptischen Kurvenaddition mit einfachen Algorithmen wie Baby-Step Giant-Step (BSGS)👇

*Merkmal 2:* Wir beschleunigen BSGS für unsere Wahl der elliptischen Kurve Ristretto255 durch gebündelte Kompressionen. Wir reduzieren auch die Größe der vorab berechneten Tabelle um das 4-fache (=> verringert die Größe und Latenz des SDKs vertraulicher dapps) Wir nennen diesen neuen Algorithmus *truncated BSGS-k (TBSGS-k).*

Ich habe diesen Algorithmus schon früher behandelt: ...aber versäumt, das *Warum* zu betonen: TBSGS-k ist deterministisch => einfacher zu implementieren und zu testen. TBSGS-k ist nur ~2x langsamer (10,6 ms vs 4,8 ms) als der komplexere [BL12]-Algorithmus und hat nur 2x größere Tabellen.

*Funktion 3:* Wenn die Prüfung aktiviert ist, halten wir eine nachweislich korrekte Verschlüsselung des (verfügbaren) Guthabens jedes Benutzers unter dem Verschlüsselungsschlüssel des Prüfers (EK). Dies schließt aus, dass Prüfer die TXNs der Benutzer scannen, um ihr Guthaben zu rekonstruieren. Schlüssel: Es ermöglicht die Rotation des Prüfer-EKs 👌

*Merkmal 4:* In Aptos ist die Rotation des _Signatur_-Schlüssels eine zentrale Sicherheitsfunktion. Also: Wir haben auch vertrauliche Vermögenswerte entworfen, um die Rotation des *Entschlüsselungs*-Schlüssels zu unterstützen! Im Moment liegen die Schlüsselverwaltungsrichtlinien bei den Anwendungen/Wallets (berühmte letzte Worte 🤞).

Die gute Nachricht: Schlüssellose vertrauliche dapps können sicher ihr 🌶️ als Entschlüsselungsschlüssel wiederverwenden! () ==> keine zusätzliche Schlüsselverwaltungsbelastung für solche Anwendungen eingeführt ==> der einfachste Weg, eine vertrauliche dapp zu erstellen, ist als schlüsselose dapp; keine [Unterstützung] für Wallets erforderlich!

*Merkmal 5:* Die Implementierung von Krypto(*graphie*), die echte Benutzerfonds sichert, ist beängstigend. Um Fehler zu minimieren (🤞), verwenden wir eine weitgehend übersehene Methodik zum sicheren Entwerfen und Komponieren von Sigma-Protokollen: Das *Homomorphismus-Rahmenwerk,* das ich in @danboneh's Buch entdeckt habe 🙏

*Merkmal 6:* Die erste produktionsbereite Implementierung von vertraulichen Vermögenswerten in Move. Der Code ist derzeit privat, während er geprüft wird, wird aber bald veröffentlicht. Hier ist ein Vorgeschmack darauf, wie einfach eine vertrauliche Übertragung sein kann 👇

Außerdem, weil ich nicht anders kann, hier ist ein Teil unseres Sigma-Protokoll-Homomorphismus-Frameworks, das in Move implementiert ist 😍

*Merkmal 7:* Vollständige kryptografische Spezifikation mit Sicherheitsnachweisen. (Vielleicht können wir es ja in @leanprover codieren?) Demnächst, mit den pikanten Details, in einem eprint neben dir 👇

Zuletzt, Anerkennung, wo Anerkennung gebührt: Aptos vertrauliche Vermögenswerte bauen auf Ideen auf und erweitern diese, die in früheren Arbeiten eingeführt wurden 👇 1. Zether (): behebt das "Front-Running"-Problem des festen Kontomodells durch ausstehende Salden

2. PGC (): schlägt Twisted ElGamal + Bulletproofs als einfachere Alternative zu \Sigma-bullets vor. Dies reduziert die Implementierungskomplexität drastisch: Wir müssen uns nur darauf konzentrieren, unsere Sigma-Protokolle korrekt zu entwerfen! Die sichere Zusammensetzung wird unten argumentiert 👇

3. Solana (): erlaubte 48-Bit übertragene Beträge, indem der ausstehende Saldo in einen "hohen" 32-Bit Abschnitt und einen "niedrigen" 16-Bit Abschnitt aufgeteilt wurde. Wir erlauben größere Beträge, indem wir eine höhere Anzahl von Abschnitten verwenden und zusätzlich den verfügbaren Saldo ebenfalls aufteilen.

Zu guter Letzt möchte ich @mstrakastrak und den Leuten von @distributedlab danken, die bei der Gestaltung der ersten Version des vertraulichen Vermögensprotokolls geholfen und es in Move und TypeScript implementiert haben 🖖 Haltet Ausschau nach unserem gemeinsamen Papier, das bald veröffentlicht wird!