Trwałe nonce: podpisywanie dwoma urządzeniami w Solanie
SSP to portfel 2 z 2. Każda transakcja wymaga dwóch podpisów: jednego z Wallet, rozszerzenia przeglądarki na twoim komputerze, i jednego z SSP Key na twoim telefonie. Na tym właśnie polega cały sens tego projektu — złodziej, który ukradnie jedno urządzenie, i tak nie ruszy twoich środków. Ale to rodzi bardzo ludzki problem. Komputer buduje i podpisuje transakcję w ułamku sekundy. Telefon może współpodpisać dopiero dwie albo trzy minuty później, bo człowiek musi wziąć telefon, spojrzeć na żądanie i dotknąć zatwierdź.
W Solanie ta przerwa jest problemem. Ten artykuł wyjaśnia dlaczego i jak SSP rozwiązuje to bez przechowywania niczego kruchego.
Blockhash, który wygasa
Każda zwykła transakcja Solany niesie ze sobą dane zwane niedawnym blockhashem. To odcisk palca niedawnego bloku łańcucha i pełni dwa zadania naraz. Dowodzi, że transakcja powstała niedawno, i powstrzymuje tę samą podpisaną transakcję przed wiecznym odtwarzaniem.
Haczyk tkwi w słowie niedawny. Blockhash jest ważny tylko przez około 150 bloków. W Solanie bloki przychodzą szybko, więc 150 bloków to zaledwie około 60 do 90 sekund. Po tym oknie sieć odrzuca transakcję wprost — nie dlatego, że coś jest nie tak z podpisami, lecz dlatego, że blockhash jest przeterminowany.
Postaw teraz przepływ podpisywania SSP naprzeciw tego zegara. Wallet buduje transakcję, ustala świeży blockhash i podpisuje. Następnie użytkownik dostaje powiadomienie na telefonie. Jeśli odpowie w ciągu 90 sekund — dobrze. Jeśli jest na spotkaniu, telefon leży w innym pokoju albo po prostu chce spokojnie przeczytać transakcję, blockhash cicho umiera. Podpis Wallet jest wciąż kryptograficznie ważny, ale transakcja, do której był dołączony, jest teraz bezwartościowa. Całość trzeba zbudować i podpisać od nowa.
Dla portfela z jednym podpisującym, który podpisuje i rozgłasza jednym tchem, okno 90 sekund jest hojne. Dla portfela 2 z 2, w którym między dwoma podpisami stoi człowiek, jest to wyścig, który użytkownik wciąż przegrywa.
Czym jest trwałe nonce
Solana ma na to wbudowaną odpowiedź, starszą niż SSP: trwałe nonce. Pomysł polega na zastąpieniu wygasającego blockhasha wartością, która nie wygasa.
Trwałe nonce żyje we własnym małym koncie na łańcuchu — koncie nonce. To konto należy do systemu, przechowuje tylko 80 bajtów danych, a jedną z tych danych jest sama wartość nonce: długowieczny zastępca blockhasha. Transakcję można zbudować tak, by używała wartości konta nonce zamiast niedawnego blockhasha. Ponieważ ta wartość nie starzeje się, transakcja pozostaje ważna tak długo, jak trzeba — minuty, godziny, dni.
Nic jednak nie jest za darmo, a nonce potrzebuje zabezpieczenia przed odtworzeniem. Tym zabezpieczeniem jest zasada: każda transakcja używająca trwałego nonce musi nieść konkretną instrukcję, nonceAdvance, jako swoją pierwszą instrukcję. Gdy transakcja w końcu wyląduje, nonceAdvance zużywa bieżącą wartość nonce i obraca konto na nową. Nonce jest jednorazowe. Transakcja, którą podpisałeś w poniedziałek, może czekać do środy, ale gdy raz się wykona, dokładnie to nonce nigdy więcej nie autoryzuje innej transakcji. Jeśli chcesz przeczytać własny opis tego mechanizmu autorstwa Solany, dokumentacja trwałych nonce transakcji jest źródłem pierwotnym.
Tak więc trwałe nonce kupuje czas, nie kupując ryzyka odtworzenia. To dokładnie ta właściwość, której potrzebuje portfel z dwoma urządzeniami.
Sztuczka SSP: konto nonce, którego nigdy nie musisz przechowywać
Trwałe konto nonce wciąż pozostaje kontem, a w Solanie każde konto ma adres. Naiwne podejście to utworzyć konto nonce pod jakimś losowym adresem, a potem pieczołowicie pamiętać ten adres na zawsze — zapisać go w lokalnej pamięci portfela, zrobić kopię zapasową, mieć nadzieję, że przetrwa reset urządzenia. To kolejna krucha rzecz do utracenia.
SSP odmawia jego przechowywania. Zamiast tego program multisig SSP dla Solany zawiera instrukcję o nazwie provision_nonce, i tworzy ona konto nonce pod wyprowadzonym adresem. Adres pochodzi z deterministycznego przepisu: jest obliczany z samego konta multisig, ze stałej etykiety tekstowej "nonce" oraz z Programu Systemowego Solany. Ten sam multisig na wejściu, ten sam adres nonce na wyjściu — za każdym razem.
To ma znaczenie z powodu tego, co reszta tej serii już ustaliła. Multisig SSP dla Solany wyprowadza adres multisig ze zbioru członków i wyprowadza adres skarbca z multisig. (Jeśli te wyprowadzenia są dla ciebie nowe, artykuł samoinicjujący multisig Solany przechodzi przez każde z nich.) Konto nonce dołącza teraz do tej samej rodziny: ono również jest czystym wyprowadzeniem. Każde urządzenie SSP — twój komputer, twój telefon, świeżo przeinstalowany portfel — może przeliczyć adres konta nonce od zera. Nie ma tajnego adresu do utracenia, bo nie ma w ogóle żadnego przechowywanego adresu.
Z projektu wynika kilka praktycznych uwag. provision_nonce jest bez zezwolenia (permissionless): każdy może zapłacić mały czynsz (około 0,00144 SOL), by konto nonce zaistniało, a kto płaci, staje się jego początkowym organem — w praktyce paymaster relaya SSP. Ten organ może być później przypisany na nowo, a adres konta nigdy się nie zmienia, więc adres, który wyprowadzasz dziś, pozostaje poprawny, nawet jeśli stojący za nim klucz operacyjny się obróci. Położenie konta nonce jest zakotwiczone w twoim multisig, a nie w tym, kto je sfinansował.
Spokojny przepływ podpisywania
Złóż elementy razem, a wyścig znika. Wallet buduje transakcję, która używa wyprowadzonego konta nonce zamiast niedawnego blockhasha, umieszcza nonceAdvance jako pierwszą instrukcję i podpisuje. Powiadomienie push trafia na telefon. Użytkownik zatwierdza, kiedy jest gotowy — żaden zegar nie tyka przeciwko niemu. SSP Key dodaje drugi podpis, a w pełni podpisana transakcja zostaje rozgłoszona. Ponieważ zbudowano ją na trwałym nonce, jest wciąż ważna, a nonceAdvance obraca nonce, by transakcji nie dało się odtworzyć.
Jest jeszcze jedno ograniczenie warte nazwania. Solana ogranicza pojedynczą transakcję do 1232 bajtów. Transakcja multisig musi zmieścić listę członków i instrukcje wydatków w tym limicie, dlatego SSP używa kompaktowego formatu transakcji wersjonowanej Solany i przekazuje dane tak zwięźle, jak to możliwe. Trwałe nonce nie zmienia budżetu rozmiaru; zmienia tylko budżet czasu.
Wyprowadzaj wszystko, nie przechowuj niczego
To nić, która przewija się przez całą serię Multisig na Solanie, na sposób SSP. Adres multisig, skarbiec, który trzyma twoje środki, i teraz konto nonce, które daje dwóm urządzeniom czas na uzgodnienie — żadne z nich nie jest wartością, którą SSP musi zapisywać i chronić. Każde jest przeliczane na żądanie z danych, które portfel i tak zna. Mniej jest do zarchiwizowania, mniej może wyciec i mniej może pójść źle przy resecie urządzenia. Projekty multisig oparte na tej idei, jak podejście SSP multisig z jednym podpisującym, zwykle mają najmniej ruchomych części, które mogą się zepsuć.
Uwaga końcowa w tym samym duchu szczerości co reszta serii: program multisig SSP dla Solany jest obecnie wdrożony wyłącznie na devnecie i oczekuje na zewnętrzny audyt bezpieczeństwa przed jakimkolwiek wydaniem na mainnecie. Opisany tu projekt — w tym provision_nonce i jego wyprowadzone konto nonce — jest realny i czytelny w otwartoźródłowym programie, ale nie jest jeszcze infrastrukturą produkcyjną. Jeśli sam model dwóch urządzeń SSP jest dla ciebie nowy, artykuł wprowadzający czym jest multisig 2 z 2 jest miejscem na początek.
Trwałe nonce to mały i stary kawałek hydrauliki Solany. Wkładem SSP jest uczynienie z jego adresu kolejnej rzeczy, której nigdy nie musisz pamiętać.
