Główna sieć Aptos wkrótce umożliwi 🔒 poufne aktywa 💸!! tzn. zaszyfrowane salda i kwoty transakcji 🔐, chociaż z publicznie widocznymi 🌍 adresami nadawcy i odbiorcy! (Jeden krok na raz, ludzie...) Oto jak to działa! 🤓👇

Aptos tajne aktywa opierają się na wcześniejszych pracach i je rozszerzają. Szyfrujemy salda na łańcuchu za pomocą Twisted ElGamal, jak PGC (). Dobrze komponuje się to z Bulletproofs, aby udowodnić, że zaszyfrowane saldo zostało poprawnie obciążone po tajnym wysłaniu/wypłacie.

Albo, jak często lubię mówić [i z tego powodu się ze mnie śmieją]... "Zobacz mój blog!"

*Cech 1:* W przeciwieństwie do PGC i Solany, nasze szyfrogramy Twisted ElGamal są _agresywnie dzielone_ w celu zapewnienia super szybkiego odszyfrowania podczas obsługi sald i kwot o długości ~256 bitów. Nazywamy to *chunked'n'twisted ElGamal.* Dla informacji, Aptos potrzebuje tylko sald 128-bitowych i kwot 64-bitowych.

Dla Aptos, dzielenie na kawałki gwarantuje, że maksymalna instancja dyskretnego logarytmu (DL), która musi być rozwiązana podczas deszyfrowania, wynosi 32 bity, w najgorszym przypadku (i znacznie mniej w średnim przypadku). => łatwo rozwiązywalne w 2^16 dodaniach krzywych eliptycznych przy użyciu prostych algorytmów, takich jak baby-step giant-step (BSGS)👇

*Cecha 2:* Przyspieszamy BSGS dla naszego wyboru krzywej eliptycznej Ristretto255 za pomocą zbiorczych kompresji. Redukujemy również rozmiar jego wstępnie obliczonej tabeli o 4x (=> zmniejszamy rozmiar SDK poufnych dapps i opóźnienie) Nazywamy ten nowy algorytm *skróconym BSGS-k (TBSGS-k).*

Już wcześniej mówiłem o tym algorytmie: ...ale nie podkreśliłem *dlaczego*: TBSGS-k jest deterministyczny => prostszy do wdrożenia i testowania. TBSGS-k jest tylko ~2x wolniejszy (10,6 ms vs 4,8 ms) niż bardziej złożony algorytm [BL12], i ma tylko 2x większe tabele.

*Funkcja 3:* Gdy audyt jest włączony, utrzymujemy udowodnioną poprawność szyfrowania dostępnego salda każdego użytkownika pod kluczem szyfrowania audytora (EK). To uniemożliwia audytorom skanowanie transakcji użytkowników w celu rekonstrukcji ich salda. Klucz: umożliwia rotacje klucza EK audytora 👌

*Funkcja 4:* W Aptos rotacja klucza _podpisu_ użytkownika jest centralną funkcją bezpieczeństwa. Zatem: zaprojektowaliśmy również poufne aktywa, aby wspierać rotację klucza *deszyfrowania* użytkownika! Na razie polityki zarządzania kluczami pozostawiono aplikacjom/portfelom (słynne ostatnie słowa 🤞).

Dobra wiadomość: Kluczowe, poufne dappsy mogą bezpiecznie ponownie używać swojego 🌶️ jako klucza deszyfrującego! () ==> nie wprowadza dodatkowego obciążenia zarządzania kluczami dla takich aplikacji ==> najłatwiejszym sposobem na zbudowanie poufnego dappa jest stworzenie dappa bezkluczowego; nie jest potrzebne [wsparcie] portfela!

*Cech 5:* Wdrażanie kryptografii, która zabezpiecza prawdziwe środki użytkowników, jest przerażające. Aby zminimalizować błędy (🤞), używamy w dużej mierze pomijanej metodologii do bezpiecznego projektowania i komponowania protokołów Sigma: *ramy homomorficzne,* które odkryłem w książce @danboneh 🙏

*Cechy 6:* Pierwsza gotowa do produkcji implementacja aktywów poufnych w Move. Kod jest obecnie prywatny, podczas gdy przechodzi audyt, ale wkrótce zostanie udostępniony. Oto zapowiedź, jak proste może być poufne przekazanie 👇

Również, ponieważ nie mogę się powstrzymać, oto część naszego frameworku homomorfizmu protokołu Sigma zaimplementowanego w Move 😍

*Cech 7:* Pełna specyfikacja kryptograficzna z dowodami bezpieczeństwa. (Może uda nam się to zakodować w @leanprover?) Już wkrótce, z pikantnymi szczegółami, w eprint obok Ciebie 👇

Na koniec, należy się uznanie tam, gdzie jest to zasłużone: poufne aktywa Aptos opierają się na i rozwijają pomysły wprowadzone w wcześniejszych pracach 👇 1. Zether (): rozwiązuje problem "front-running" w modelu stałego konta za pomocą sald oczekujących

2. PGC (): zaproponowano Twisted ElGamal + Bulletproofs jako prostszą alternatywę dla \Sigma-bullets. To drastycznie redukuje złożoność implementacji: musimy skupić się tylko na poprawnym zaprojektowaniu naszych protokołów Sigma! Bezpieczna kompozycja jest omawiana poniżej 👇

3. Solana (): umożliwiła transfery kwot 48-bitowych, dzieląc oczekującą równowagę na "wysoki" 32-bitowy kawałek i "niski" 16-bitowy kawałek. Umożliwiamy większe kwoty, używając większej liczby kawałków oraz dodatkowo dzieląc dostępną równowagę.

Na koniec, chciałbym podziękować @mstrakastrak i ekipie z @distributedlab, którzy pomogli w zaprojektowaniu początkowej wersji protokołu aktywów poufnych i wdrożeniu go w Move i TypeScript 🖖 Uważajcie na naszą wspólną pracę, która wkrótce się ukaże!