Helius uruchamia szyfrowane płatności Solana w sieci mainnet – zaufanie do operatora wciąż wymagane

Helius uruchomił swoje permissionless Privacy Ring w sieci mainnet Solany 10 listopada, szyfrując aktywa i kwoty płatności, przy czym adresy portfeli nadawcy i odbiorcy pozostają widoczne. Udokumentowany domyślny prover systemu – usługa konstruująca dowody zerowej wiedzy – dodaje wymóg sprzętowy: poufne dane wejściowe transakcji są przetwarzane wewnątrz zaświadczonego enclave AWS Nitro, izolowanego środowiska obliczeniowego.

Ponieważ rejestr Solany jest publiczny, a zapisane w nim transfery może obserwować każdy, szyfrowanie aktywów i kwot obejmuje najbardziej bezpośrednio wrażliwe pola płatności, nawet gdy adresy po obu stronach pozostają widoczne.

Solana może zweryfikować, że transfer spełnia zasady protokołu, ale ochrona danych wejściowych podczas generowania dowodu zależy od izolacji provera, jego kodu i polityk wdrożeniowych.

Co trafia do usługi dowodowej

Dla deweloperów portfeli integrujących to rozwiązanie praktycznym pytaniem jest, które z tych zabezpieczeń ich oprogramowanie może faktycznie zweryfikować. Ich wybory – lokalne lub delegowane deszyfrowanie, zdalne lub klientowe generowanie dowodów – determinują, którym częściom transakcji ich użytkownicy muszą ufać innym.

Przewodnik integracji portfela Heliusa stwierdza, że generowanie dowodu wymaga danych wejściowych w postaci jawnego tekstu obejmujących kompletne dane transakcji oraz klucze nullifier, i wskazuje zaświadczone enclave AWS Nitro jako domyślny prover SDK.

Specyfikacja protokołu wymienia prywatne dane wejściowe obejmujące aktywo, kwotę, wartości blindujące i sekret nullifier dla wydawanych not, a także ścieżki dowodzące, że te noty należą do drzewa stanu. Dowód obejmuje również aktywa wyjściowe, kwoty i wartości blindujące.

Te dane wejściowe stają się czytelne dla kodu dowodowego wewnątrz enclave. Udokumentowany klient chroni je przed operatorem hosta, szyfrując żądania kluczem przechowywanym przez zaświadczone enclave. Sekret nullifier służy również do wywodzenia znaczników zapobiegających ponownemu wydawaniu środków.

W natywnej integracji portfela portfel zachowuje klucz podpisujący, a TypeScript SDK pozostawia podpisanie gotowej transakcji Solana signerowi aplikacji. Helius dokumentuje dwa tryby deszyfrowania: deszyfrowanie lokalne, które utrzymuje klucz podglądu na urządzeniu, oraz deszyfrowanie delegowane, które udostępnia klucz podglądu autoryzowanemu dostawcy. Delegacja daje temu dostawcy dostęp do odczytu sald i historii bez nadawania uprawnień do wydawania środków.

Jak działa model enclave

AWS opisuje Nitro Enclaves jako izolowane środowiska, do których pamięci procesy lub administratorzy instancji nadrzędnej nie mają dostępu. Enclave nie mają trwałego magazynu, dostępu interaktywnego ani sieci zewnętrznej. Podpisany dokument attestation AWS zawiera kryptograficzne odciski obrazu i oprogramowania enclave.

Ponieważ konstrukcja dowodu to etap, na którym prywatne dane wejściowe istnieją w postaci jawnego tekstu, środowisko provera jest miejscem, w którym projekt enclave koncentruje swoje zabezpieczenia.

Udokumentowane testy Privacy Rings weryfikują łańcuch certyfikatów, odpowiedź na challenge i jej świeżość, zatwierdzone pomiary oraz powiązanie klucza szyfrującego żądania. Oznaczony SDK odrzuca żądanie do zdalnego provera bez attestation przed wykonaniem jakiegokolwiek wywołania HTTP. Portfel może przypiąć poddaną przeglądowi politykę wydawniczą lub przyjąć politykę sieciową uwierzytelnioną przez przypiętych sygnatariuszy SDK. Podpisane polityki są odświeżane podczas attestation i wygasają po użyciu.

Gdzie zaufanie nadal spoczywa

Portfel może automatycznie potwierdzić, że enclave odpowiada zatwierdzonemu obrazowi oprogramowania i kluczowi szyfrującemu, jednak decyzja, który obraz zatwierdzić, nadal wymaga zaufania do kodu i jego recenzentów.

Zgodnie z przewodnikiem wdrożenia Nitro mierzony obraz obejmuje prover, skrypt startowy, pakiet certyfikatów, dozwolonych hostów zewnętrznych, URL indeksera i tożsamość klucza KMS. Projekt wykorzystuje AWS Key Management Service do udostępniania współdzielonego ziarna szyfrowania wyłącznie enclave o zgodnym attestation. Klienci nie mogą odczytać polityki klucza KMS – zgodnie z przewodnikiem polegają w tej kwestii na wdrożeniu operatora. Przewodnik wskazuje AWS KMS, AWS Support, sprzęt Nitro oraz operatora jako korzenie zaufania podczas początkowego powiązania polityk.

Nawet poprawnie zaszyfrowane żądania pozostawiają metadane widoczne dla instancji nadrzędnej, w tym ścieżki, zapytania, chronometraż i rozmiary; ścieżka ujawnia kształt obwodu dowodu.

Wersjonowany przewodnik TEE odnotowuje build mainnet oparty na v0.6.0-alpha z pochodzeniem measured-build, odmienny od tagu dokumentacji ts-sdk-v0.8.0-alpha. Specyfikacja dopuszcza dowody po stronie klienta, a repozytorium dostarcza narzędzia localnet oraz do pobrania pliki binarne provera.

Ogłoszenie premierowe Heliusa podaje, że programy i obwody audytowały firmy Certora, zkSecurity i OtterSec. Jego strona bezpieczeństwa wymienia audit Certory w październiku i zkSecurity w sierpniu, oznaczając raport OtterSec jako oczekujący. Dla zespołów oceniających to wydanie udokumentowane elementy do śledzenia to: oczekujący raport OtterSec, rozbieżność między buildem mainnet v0.6.0-alpha a tagiem dokumentacji ts-sdk-v0.8.0-alpha oraz to, czy integracje przyjmą przypięte polityki wydawnicze, polityki sieciowe czy opcję dowodów po stronie klienta ze specyfikacji.

To wydanie pozostawia deweloperom portfeli decyzję zaufania: który kod i która polityka wdrożeniowa zostaną przez nich zatwierdzone do obsługi danych wejściowych dowodów.

Źródło: CryptoNewsNet | Pierwotnie doniósł CryptoSlate