Adres portfela wygląda na coś prostego: ciąg znaków, który kopiujesz, wklejasz i na który wysyłasz pieniądze. W Bitcoinie jest niemal tak prosty. W Solanie umieszczenie współdzielonego portfela — multisig — za adresem jest zaskakująco trudne. Ten artykuł wyjaśnia dlaczego i stawia pytanie, na które odpowiada reszta tej serii.
Co musi obiecać adres multisig
Portfel multisig jest kontrolowany przez kilka kluczy, z których ustalona liczba musi się zgodzić, zanim pieniądze się przemieszczą. Multisig „2 z 3" ma na przykład trzy klucze i wymaga, by dowolne dwa zatwierdziły płatność. Celem jest usunięcie pojedynczych punktów awarii: tracisz jeden klucz albo jeden klucz zostaje skradziony, a Twoje środki nadal są bezpieczne.
Aby było to przydatne, adres musi dotrzymać dwóch obietnic. Po pierwsze, musi być znany z wyprzedzeniem — chcesz przekazać komuś adres depozytowy, zanim skończysz cokolwiek konfigurować. Po drugie, musi być uczciwy: każdy, kto wyśle pieniądze na ten adres, powinien móc ufać, że tylko uzgodniona grupa kluczy, według uzgodnionej reguły, będzie kiedykolwiek mogła z niego wydawać. Zapamiętaj te dwie obietnice. Są nicią przewodnią wszystkiego, co następuje.
W Bitcoinie adres jest regułą
Bitcoin sprawia, że wygląda to łatwo. Multisig w Bitcoinie opisuje mały skrypt: lista kluczy publicznych plus reguła „M z N". Aby uzyskać adres, bierzesz ten skrypt i go haszujesz. Adres (adres P2WSH) dosłownie jest haszem reguł wydawania.
Ma to cicho potężną konsekwencję. Każdy może obliczyć adres offline, na laptopie bez internetu, zanim zostanie nadana choćby jedna transakcja. Nie ma kroku „utwórz portfel" — portfel nie musi istnieć w sieci, by otrzymywać pieniądze. Skrypt jest ujawniany dopiero później, przy wydawaniu środków, a sieć sprawdza, czy ujawniony skrypt pasuje do adresu i czy jest wystarczająco wiele ważnych podpisów. Adres znany z wyprzedzeniem: tak. Uczciwy: tak — ponieważ adres wywodzi się z samej reguły, inny zestaw kluczy daje inny adres.
W Solanie adres to konto, które trzeba utworzyć
Solana działa inaczej. W Solanie wszystko jest kontem — slotem pamięci on-chain z właścicielem. Twoje środki żyją na kontach, programy żyją na kontach, a konfiguracja multisig również żyje na koncie. Co kluczowe, konta nie pojawiają się za darmo. Konto musi zostać wyraźnie utworzone i opłacone: ktoś finansuje je niewielką ilością SOL zwaną „czynszem", aby sieć przechowywała jego dane.
Multisig w Solanie nie jest zatem tylko adresem — to konto kontrolowane przez program, zawierające listę członków i próg. A to konto musi zostać utworzone transakcją, zanim multisig będzie mógł cokolwiek zrobić. To źródło trudności: współdzielony portfel w Solanie ma krok konfiguracji, którego Bitcoin po prostu nie ma.
PDA: adresy bez klucza prywatnego
Solana ma jednak eleganckie narzędzie do tego, zwane Program Derived Address, czyli PDA. Zwykły adres Solany ma odpowiadający mu klucz prywatny — kto ma klucz, kontroluje adres. PDA jest celowo zbudowany tak, by leżał poza krzywą: to wyglądający poprawnie adres, dla którego żaden klucz prywatny nie istnieje i nie może istnieć. Nikt nie może osobiście podpisać się za niego.
Zamiast tego PDA jest wyprowadzany w sposób deterministyczny. Bierzesz kilka wartości wejściowych — zwanych „nasionami" (seeds) — plus identyfikator programu, przepuszczasz je przez funkcję jednokierunkową i wychodzi adres. Te same nasiona i ten sam program zawsze dają ten sam PDA, więc każdy może go odtworzyć. A ponieważ nie ma klucza prywatnego, tylko program będący właścicielem może autoryzować działania dla tego adresu, co robi za pomocą mechanizmu zwanego wywołaniem między programami z invoke_signed: program przedstawia nasiona środowisku uruchomieniowemu Solany, a środowisko nadaje mu uprawnienia do podpisywania dla PDA. Nigdy nie powstaje podpis kryptograficzny — prawo do działania bierze się ze znajomości nasion, a nie z posiadania klucza.
PDA jest dokładnie właściwym domem dla multisig: adresem kontrolowanym przez logikę programu, a nie przez jedną osobę. Jak dotąd dobrze. Trudna część to to, co zostaje wybrane jako nasiona.
Problem finansowania przed utworzeniem
Tu właśnie dominujące multisig Solany napotykają kłopot. W odróżnieniu od deterministycznego modelu Bitcoina, najczęściej używane multisig Solany — Squads V4 to wiodący przykład, dojrzały i mocno audytowany — wyprowadzają adres multisig ze świeżo wygenerowanej wartości losowej wybranej w momencie tworzenia, a nie z zestawu członków. W Squads V4 ta wartość nazywa się create_key, ulotny klucz powstający, gdy twórca uruchamia transakcję tworzenia.
Wyprowadzanie adresu z losowego create_key to celowy, rozsądny wybór projektowy — omija niewygodny przypadek brzegowy, w którym dwie różne grupy chcą dokładnie tego samego składu członków. Ma jednak dwie konsekwencje, które warto jasno zrozumieć:
- Nie możesz poznać adresu z wyprzedzeniem. Nasiono nie istnieje, dopóki ktoś nie uruchomi transakcji tworzenia, więc adres także nie. Nie ma sposobu, by wydrukować adres depozytowy i sfinansować go przed konfiguracją — problem finansowania przed utworzeniem. Pierwsza obietnica się łamie.
- Twórca jest pojedynczym punktem zaufania na etapie konfiguracji. Konkretne konto musi uruchomić tę transakcję tworzenia i wybrać tę wartość losową. Przez krótkie okno konfiguracji ufasz, że ta strona zrobi to poprawnie.
Nic z tego nie czyni Squads V4 niebezpiecznym — to najbardziej sprawdzony w boju multisig Solany, zabezpieczający bardzo duże sumy. To po prostu inny kształt zaufania niż w Bitcoinie. Adres nie jest już „haszem reguły"; jest „tym, co akurat wyprodukowała transakcja tworzenia".
Ethereum znalazł drogę pośrednią
Ethereum stanęło wobec podobnego problemu i odpowiedziało na niego funkcją zwaną CREATE2. Pozwala ona obliczyć adres inteligentnego kontraktu zanim kontrakt zostanie wdrożony, na podstawie stałych danych wejściowych. Portfele takie jak Safe używają tego, by dać Ci tzw. adres kontrfaktyczny: prawdziwy, dający się sfinansować adres, którym możesz się dzielić i na którym możesz odbierać pieniądze, podczas gdy właściwy kontrakt jest wdrażany leniwie — dopiero gdy środki muszą się po raz pierwszy przemieścić. Nowszy standard abstrakcji kont, ERC-4337, formalizuje tę samą ideę. Ethereum odzyskuje w ten sposób obietnicę „znany z wyprzedzeniem", choć — jak Solana — ostatecznie potrzebuje istnienia obiektu on-chain.
Pytanie, na które odpowiada ta seria
Postaw trzy modele obok siebie. Bitcoin: adres jest haszem reguły — poznawalny offline, uczciwy z konstrukcji, bez kroku tworzenia. Ethereum: adres kontrfaktyczny — znany z wyprzedzeniem, z odroczonym wdrożeniem. Ogólne multisig Solany: adres pochodzi z losowości z momentu tworzenia — niepoznawalny z wyprzedzeniem, z twórcą, któremu trzeba ufać przy konfiguracji.
Oto więc pytanie. Solana potrzebuje kont, a konta trzeba tworzyć — to nie zniknie. Ale czy multisig Solany musi zrezygnować z własności Bitcoina? Czy adres mógłby zamiast tego być wyprowadzany czysto z zestawu członków i progu — z samej reguły — tak by był poznawalny offline, możliwy do sfinansowania przed konfiguracją i uczciwy, ponieważ inna grupa kluczy daje inny adres?
To dokładnie ta własność, którą zespół SSP wbudował we własny program multisig dla Solany. Następny artykuł pokazuje jak: adres, który jest zestawem członków, skarbiec, który możesz sfinansować, zanim cokolwiek zostanie zarejestrowane on-chain, oraz krok rejestracji, który nie potrzebuje żadnego twórcy. Projekt został wydany razem ze wsparciem dla Solany w SSP Wallet — zobacz ogłoszenie wydania — i, zgodnie z tym, jak SSP traktuje bezpieczeństwo, program jest obecnie wyłącznie na devnecie i czeka na zewnętrzny audyt przed mainnetem. Jeśli sam multisig jest dla Ciebie wciąż nowy, zacznij od czym jest multisig i dlaczego ma znaczenie; w przeciwnym razie czytaj dalej.
