Solana w SSP

Solana jest szybka, tania i coraz częściej to właśnie tam realnie krążą stablecoiny. Jest też łańcuchem, na którym multisig w samodzielnym przechowywaniu historycznie najtrudniej było zrobić dobrze — nie dlatego, że kryptografia jest trudna, lecz dlatego, że model kont Solany czyni z „adresu kontrolowanego przez kilka stron” obiekt znacznie dziwniejszy niż na Bitcoinie.

SSP trzyma SOL i tokeny SPL w tym samym multisigu 2 z 2, którego używasz już do Bitcoina i Ethereum: jeden klucz w rozszerzeniu przeglądarki, drugi w telefonie, oba wymagane przy każdej transakcji. Ten artykuł wyjaśnia, co to oznacza konkretnie na Solanie — jak wyprowadzany jest adres, kto płaci opłaty, co weryfikują twoje urządzenia i które elementy naprawdę różnią się od łańcuchów, które już znasz.

Czym jest Solana z perspektywy samodzielnego przechowywania

Solana to jedna globalna maszyna stanów, która przetwarza transakcje równolegle, a nie po kolei. Dla osoby trzymającej własne klucze trzy właściwości liczą się bardziej niż nagłówek o przepustowości.

Po pierwsze, wszystko jest kontem. Twoje saldo, mint tokena, kod programu i dane przez ten program przechowywane — wszystko to mieszka w kontach mających adres i właściciela. Po drugie, konta kosztują czynsz: aby istnieć on-chain, konto musi utrzymywać minimalne saldo SOL proporcjonalne do swojego rozmiaru. Ten depozyt podlega zwrotowi po zamknięciu konta, ale to prawdziwe pieniądze, które muszą skądś pochodzić. Po trzecie, transakcje szybko wygasają — zwykła transakcja Solany odwołuje się do świeżego blockhasha i po mniej więcej minucie przestaje być ważna.

Każda z tych cech ma bezpośrednie konsekwencje dla podpisywania dwoma urządzeniami i każda jest w SSP obsłużona wprost, a nie zamalowana. Własna dokumentacja Solany jest źródłem pierwotnym dla modelu kont i czynszu, jeśli chcesz wersję surową.

Adres bez twórcy

W większości projektów multisiga na Solanie portfel trzeba utworzyć. Ktoś wysyła transakcję, która go ustanawia, a powstały adres zależy od danych wybranych w trakcie tej transakcji — zwykle losowego klucza jednorazowego. Praktyczny skutek jest taki, że adres nie istnieje, dopóki twórca nie powoła go do życia, i wcześniej nie może przyjąć środków.

Program on-chain SSP działa inaczej. Adres twojego skarbca to odcisk palca posortowanego zbioru członków plus progu zatwierdzeń — i nic więcej. Każdy, kto wie, kim są członkowie i ile zatwierdzeń jest potrzebnych, może wyliczyć adres offline, zanim cokolwiek dotknie łańcucha. Rejestracja jest bezuprawnieniowa: program sprawdza jedynie, czy przedstawieni członkowie faktycznie hashują się do deklarowanego adresu, więc rejestracja niczego nie zmienia w kwestii tego, kto może wydawać.

Dlatego nie ma twórcy, któremu trzeba by ufać, nie ma uprzywilejowanego rejestrującego ani klucza administratora. Wydatki reguluje wyłącznie sprawdzenie progu wewnątrz programu. Jeśli chcesz pełny obraz, dlaczego adresy multisig na Solanie są trudne omawia problem u podstaw, samoinicjujący się multisig Solany omawia sam program, a SSP kontra Squads V4 to porównanie punkt po punkcie.

Jeśli sam model 2 z 2 jest dla ciebie nowy, zacznij od czym jest multisig 2 z 2.

Dlaczego dwa urządzenia potrzebowały trwałego nonce'a

Oto problem, który tworzy wygasanie. Twoje rozszerzenie buduje i podpisuje transakcję. Telefon musi ją potem zatwierdzić. Jeśli wyjdziesz z pokoju, zjesz obiad i wrócisz, blockhash, do którego odwoływała się transakcja, dawno jest martwy i całość trzeba zbudować od nowa.

SSP rozwiązuje to kontem trwałego nonce'a wyprowadzonym z twojego adresu multisig. Zamiast świeżego blockhasha transakcja odwołuje się do nonce'a, który przesuwa się dopiero wtedy, gdy transakcja faktycznie trafi na łańcuch. Okno podpisu przestaje być stoperem. Możesz zatwierdzić na telefonie minuty albo godziny później, a transakcja wciąż będzie ważna — ale nadal da się jej użyć tylko raz, ponieważ wykonanie przesuwa nonce.

Konto nonce'a powstaje przy pierwszym wysłaniu i jest jednym z dwóch kont, których czynsz pojawia się w koszcie tego pierwszego wysłania. Trwałe nonce'y i podpisywanie dwoma urządzeniami wchodzi głębiej.

Kto płaci opłaty

Na Solanie konto płacące opłatę za transakcję to fee payer i musi ono złożyć podpis. Dla świeżego multisiga tworzy to niewygodny problem rozruchu: skarbiec potrzebuje SOL, aby opłacić transakcję, która przeniosłaby jego SOL, a konta wymagające czynszu jeszcze nie istnieją.

SSP używa paymastera. Relay SSP prowadzi konto, które podpisuje się jako fee payer, wykłada opłatę sieciową i ewentualny czynsz, a zwrot otrzymuje od twojego skarbca wewnątrz tej samej transakcji. Nie ma osobnego kroku, nie ma udzielonego kredytu i nie ma sposobu, by zwrot nastąpił bez twoich dwóch podpisów — jedzie on w propozycji, którą zatwierdzają twoje urządzenia.

Dwie konsekwencje warto sobie przyswoić:

• Nie musisz wcześniej zasilać adresu SOL-em na gaz. Odbierz SOL, wyślij SOL. To przy pierwszym wysłaniu tworzą się konta.
• Pierwsze wysłanie kosztuje więcej niż kolejne. Pierwsze wysłanie opłaca stały czynsz konta multisig i konta nonce'a; późniejsze płacą niewiele ponad opłatę sieciową. Dokładne liczby są w artykule o opłatach z tej serii.

Jeśli paymastery jako pojęcie są ci obce, sponsorowanie gazu i paymastery, wyjaśnione opisuje ogólny wzorzec — SSP stosuje ten sam pomysł już na łańcuchach EVM, co opisano w Ethereum w SSP.

Co możesz trzymać

Solana w SSP obsługuje natywny SOL i tokeny SPL. Domyślnie obejmuje to oficjalny mint USDC od Circle oraz FLUX na Solanie, a SSP rozpoznaje też inne tokeny SPL, które znajdzie w twoim skarbcu.

Rozróżnienie, o które wielu się potyka: na Solanie nie trzymasz tokena pod swoim głównym adresem. Każdy token mieszka we własnym powiązanym koncie tokena, należącym do twojego adresu, po jednym na mint. To konto również potrzebuje czynszu i właśnie dlatego wysłanie tokena SPL komuś, kto nigdy go nie posiadał, kosztuje odrobinę więcej: płacisz za powołanie jego konta tokena do istnienia. SSP tworzy je automatycznie w ramach przelewu, zamiast kończyć błędem, a artykuł o kontach tokenów z tej serii rozkłada szczegóły na czynniki pierwsze.

Co sprawdzają twoje urządzenia, zanim podpiszesz

Transakcje Solany są nieprzejrzyste w sposób, w jaki transakcje Bitcoina nie są. To, co robi transakcja, siedzi w danych instrukcji, a portfel musi je zdekodować, zanim powie ci o nich cokolwiek prawdziwego. Portfel, który po prostu wyświetla to, co powiedział mu serwer, prosi cię o zaufanie serwerowi.

SSP dekoduje transakcję na twoich własnych urządzeniach, bajt po bajcie, korzystając z otwartoźródłowej biblioteki @runonflux/solana-multisig. Odbiorca, kwota i mint tokena są odczytywane z surowych bajtów i porównywane z tym, co jest wyświetlane. Jeśli się rozjeżdżają, podpisywanie zostaje wprost zablokowane — rozbieżność w tym miejscu wskazuje na aktywny atak, a nie na usterkę wyświetlania. Przy przelewach SPL liczba miejsc dziesiętnych tokena jest wpisana w samą podpisaną instrukcję, więc mint deklarujący inne miejsca dziesiętne sprawia, że program on-chain odrzuca transakcję.

Ta sama zasada rządzi programem: buildy mainnetu są odtwarzalne z opublikowanych źródeł, więc bajtkod wdrożony pod SSPWVu7dtTDkZYmDx73StqV46PioSmdiNE7igpjHK1r można niezależnie zbudować na nowo i porównać. Twierdzenie o bezpieczeństwie jest warte dokładnie tyle, ile twoja zdolność do samodzielnego sprawdzenia go.

Jak zacząć

Zaktualizuj SSP Wallet i SSP Key do najnowszej wersji, a następnie włącz Solanę w selektorze łańcuchów. Dzięki synchronizacji zbiorczej w v2 możesz włączyć ją razem z dowolnymi innymi łańcuchami jednym zatwierdzeniem na telefonie. Jeśli w ogóle nie masz jeszcze skonfigurowanego SSP, konfiguracja pierwszego portfela SSP to miejsce na start.

Od tego momentu Solana zachowuje się jak każdy inny łańcuch w SSP: wlicza się do sumy twojego portfolio, przelewy przechodzą tę samą ścieżkę utwórz → sprawdź → zatwierdź z pełnym adresem odbiorcy na ekranie, a każdą transakcję współpodpisują oba twoje urządzenia. Ogłoszenie startu mainnetu opisuje, co i kiedy trafiło do wydania.