Multisig single-signer: jak SSP sprawia, że dwa urządzenia czują się jak jeden portfel

Jeśli jesteś z tą serią od czym jest multisig, znasz protokół: więcej niż jeden klucz prywatny musi podpisać, zanim pieniądze się ruszą. Widziałeś wybór m-of-n, okablowanie BIP48, horyzont agregacji Schnorra, i porównanie z social-recovery. Wszystko to jest maszynerią. Ten artykuł jest o doświadczeniu.

Uczciwa historyczna krytyka multisig jest taka, że był niegościnny w użyciu. Wiele portfeli, ręczna wymiana PSBT, oprogramowanie koordynacyjne, imprezy podpisowe — protokół był solidny, ale UX była karą. Single-signer multisig to idea produktowa, która to naprawia: portfel, który używa pełnej reguły wydatkowej multisig on-chain, ale czuje się — dla osoby, która go używa — jak jeden portfel z jednym przyciskiem. SSP jest zbudowane wokół tej idei.

TL;DR

• „Single-signer" nie oznacza jednego klucza. Oznacza, że protokół wciąż ma m z n kluczy, ale UX podpisu jest zwinięte w jeden przepływ. Użytkownik podpisuje w jednym miejscu; portfel obsługuje koordynację urządzenie-urządzenie.
• Konkretny kształt SSP: jedno rozszerzenie przeglądarki, jedna aplikacja mobilna (SSP Key), jedna tożsamość portfela. Klikasz Send, potwierdzasz na telefonie, transakcja jest emitowana. Dwa podpisy się dzieją; ty doświadczasz jednego.
• Wygraną jest to, że korzyść z progu (odporność na kradzież, brak single-point-of-failure) jest zachowana, podczas gdy koszt koordynacji spada blisko UX single-sig.
• Kosztem jest to, że to działa tylko tak długo, jak oba twoje urządzenia są osiągalne. W chwili, gdy UX musi ujawnić wieloskładnikowość — odzyskiwanie, wymiana urządzenia, przywracanie u strony trzeciej — abstrakcja pęka, z założenia.
• Ten wzorzec to najbliższe podejście do „bezkompromisowej" odpowiedzi dla solo self-custody w skali retail. To zakład SSP i coraz częściej zakład każdego nowoczesnego produktu multisig (Coinbase Wallet, ewoluująca historia custody Phantoma, przepływ smart-account Safe na Ethereum).

Ideał single-signer: czego użytkownicy naprawdę chcą

Jeśli zapytasz użytkownika self-custody, czego chce, dostajesz odpowiedzi, które sobie przeczą:

• „Chcę, żeby moje monety były bezpieczne." — Implikuje multisig, hardware, redundancję.
• „Chcę podpisać transakcję w pięć sekund." — Implikuje jedno urządzenie, jedno dotknięcie.
• „Chcę odzyskać, jeśli coś stracę." — Implikuje backupy seed, redundancję.
• „Nigdy więcej nie chcę spisywać seeda." — Implikuje custody klucza zarządzaną przez platformę.
• „Chcę, żeby to było tanie." — Implikuje minimalny ślad on-chain.

Te cele nie wszystkie się układają. Historia projektowania portfeli self-custody to historia, które cele honorować, a które uprzejmie odrzucić. Hardware wallets honorują bezpieczeństwo i odzyskiwanie kosztem UX. Portfele smart-contract honorują UX i odzyskiwanie kosztem zasięgu cross-chain. Czyste hot wallety honorują UX i taniość kosztem bezpieczeństwa.

Single-signer multisig to próba uhonorowania wszystkich pięciu — częściowo — przez oddzielenie semantyki protokołu od semantyki interfejsu. Portfel wciąż wykonuje pełny taniec multisig on-chain; użytkownik po prostu nie musi uczestniczyć w tym tańcu więcej niż raz na transakcję.

Jak SSP to dostarcza

Konkretna implementacja SSP, w prostym języku:

1. Przy konfiguracji instalujesz rozszerzenie przeglądarki i aplikację mobilną (SSP Key). Każde generuje własny seed, który backupujesz osobno (to krok z checklisty pierwszych 1000). Dwa urządzenia wymieniają klucze publiczne; od tego momentu współdzielą tożsamość portfela na poziomie protokołu.
2. Przy codziennym podpisywaniu klikasz Send w rozszerzeniu przeglądarki, przeglądasz transakcję i zatwierdzasz. Rozszerzenie konstruuje częściowo podpisaną transakcję i wysyła powiadomienie do twojego telefonu. Aplikacja mobilna pokazuje szczegóły transakcji, stukasz zatwierdź, a aplikacja produkuje drugi podpis. Rozszerzenie łączy oba podpisy i emituje. Całkowity czas: około 8 sekund, gdy oba urządzenia są przed tobą.
3. Przy odbiorze pokazywany adres to wyprowadzony BIP48 adres multisig z obu xpubsów. Skanujesz go lub kopiujesz; nadawca nie widzi niczego niezwykłego. Z jego strony wygląda jak każdy inny adres kryptowalutowy.
4. Przy rozliczeniu portfel pokazuje ci salda, historię, fee itp. identycznie jak portfel single-sig. Nie ma osobnego „ekranu multisig". Kształt protokołu jest niewidoczny podczas normalnego użycia.

Kluczowy wybór projektowy to to, że drugi podpis jest jedyną wieloskładnikowością, o której użytkownik musi kiedykolwiek myśleć. Setup to dwa urządzenia, podpis to jedno dodatkowe dotknięcie, a to jest cała powierzchnia protokołu multisig z perspektywy użytkownika.

Mała ale ważna kwestia: rozszerzenie przeglądarki SSP i SSP Key nie są współzlokalizowane. Są na różnych OS, różnym sprzęcie, różnych powierzchniach ataku. To czyni setup z dwoma podpisami prawdziwą barierą antykradzieżową, a nie tylko progiem UX. (Rozpakowujemy to w tekście o siedmiu trybach awarii i w Czym jest multisig 2-of-2.)

Czego użytkownik nigdy nie widzi

Dużo pracy idzie w trzymanie użytkownika z dala od konieczności obsługi hydrauliki multisig. Konkretnie:

• PSBT (Partially Signed Bitcoin Transactions) to grube struktury danych krążące między urządzeniami współpodpisującymi. W tradycyjnym setupie multisig kopiujesz i wklejasz je ręcznie. SSP serializuje i przesyła je swoim własnym kanałem koordynacyjnym; użytkownik widzi powiadomienie, nie ciąg base64.
• Wymiana xpubsów cosigner to jednorazowe zdarzenie konfiguracyjne. W tradycyjnym multisig importujesz xpubsy każdego cosigner jawnie. SSP zawija to w przepływ parowania przy konfiguracji; potwierdzasz kod QR lub sześciocyfrowy kod i nigdy nie dotykasz materiału pod spodem.
• Estymacja fee, obsługa reszty i rotacja adresów są obsługiwane przez portfel dokładnie tak jak robią to portfele single-sig, mimo że sam portfel jest multisig pod spodem.
• Redeem script — BIP48-kanoniczny skrypt opisujący regułę multisig — jest konstruowany przez portfel automatycznie. Użytkownicy go nie widzą, nie zatwierdzają linia po linii, nie muszą wiedzieć, że istnieje. (Mogą go zobaczyć w block explorerze, jeśli zajrzą — to najczystsza właściwość „pokaż swoją pracę" portfeli multisig.)

Cała ta abstrakcja to konieczna praca, ale to też ryzyko — za każdym razem, gdy protokół jest ukryty przed użytkownikiem, portfel bierze na siebie odpowiedzialność za zrobienie ukrytej części dobrze. Praca audytowa SSP (Halborn) dotyczy w dużej mierze właśnie tych niewidzialnych ścieżek kodu.

Kiedy przestaje czuć się jak single-signer

Abstrakcja nie jest doskonała i ważne jest, żeby wiedzieć, gdzie pęka. UX single-signer trzyma, dopóki oba urządzenia są dostępne. Pęknięcia pojawiają się, gdy jedno nie jest:

• Wymiana urządzenia. Gdy zmieniasz telefon, nowe urządzenie musi być ponownie sparowane. To jednorazowy krok koordynacji multisig, który faktycznie jest widoczny — portfel prowadzi cię przez ponowne pokazanie sobie obu urządzeń.
• Odzyskiwanie z seed. Jeśli urządzenie zostanie zniszczone, odzyskujesz je z jego seed phrase na nowe urządzenie, a potem ponownie parujesz. Fakt, że masz dwa seedy (jeden na urządzenie), staje się widoczny w tym momencie w sposób, jakiego nie było podczas normalnego użycia.
• Odzyskiwanie cross-software. Jeśli kiedykolwiek załadujesz swoje dwa seedy SSP do portfela multisig firm trzecich (Sparrow, Electrum itd.), cała hydraulika multisig staje się widoczna — to feature, nie bug, ponieważ to udowadnia, że twój portfel jest interoperacyjny, ale to nie jest UX SSP.
• Wydawanie, gdy jedno urządzenie jest offline. Portfel nie może współpodpisać bez obu urządzeń; to protokół. Zobaczysz stan „czekam na drugi podpis", aż drugie urządzenie wróci online.

Pierwsze trzy są wystarczająco rzadkie, by nie pogarszać średniego UX. Czwarty jest najczęstszym punktem tarcia — i właściwym punktem tarcia. Jeśli portfel pozwalałby ci wydawać bez drugiego urządzenia, nie byłby już portfelem 2-of-2. To tarcie to bezpieczeństwo; nie da się go usunąć inżynierią bez usunięcia własności, za którą płaciłeś.

Projektowanie wokół UX single-signer

Trzy zasady projektowe, którymi SSP — i inne nowoczesne produkty multisig — kierują się, aby utrzymać tę abstrakcję napiętą:

1. Dwóch cosignersów musi mieszkać na różnych powierzchniach zagrożeń. Portfel, który umieszcza oba klucze współpodpisujące na tym samym OS, naprawdę nie dostarcza korzyści bezpieczeństwa; po prostu rozsmarowuje jedną powierzchnię ataku na dwa zamki. Podział SSP między rozszerzenie przeglądarki a aplikację mobilną wymusza to naturalnie.
2. Kanał koordynacyjny musi być niefałszowalny. PSBT, który rozszerzenie przeglądarki wysyła do aplikacji mobilnej, musi być kryptograficznie związany z właściwym portfelem i właściwą transakcją; w przeciwnym razie abstrakcja staje się własną powierzchnią ataku. SSP podpisuje i waliduje ten materiał na poziomie protokołu.
3. Kontrakt z użytkownikiem musi być uczciwy co do tego, co jest ukryte. Portfele, które obiecują „całkowicie bezzaufaniowe doświadczenie single-signer" bez wyjaśnienia, co dzieje się przy odzyskiwaniu, narażają użytkowników na niemiłą niespodziankę. Onboarding SSP wyraźnie przechodzi przez oba seedy, oba backupy i oba scenariusze odzyskiwania — abstrakcja jest ukryta podczas użycia, ale wyeksponowana podczas onboardingu, żeby cię później nie zaskoczyła.

Portfele account abstraction na Ethereum mają czwarte narzędzie: warstwę smart-contract. Z ERC-4337 portfel może absorbować opłaty gazowe, batchować transakcje i prezentować jeszcze bardziej „single-signer-podobne" UX oraz implementować multisig pod spodem. SSP nie ma tej warstwy na Bitcoinie (brak smart contractów), więc abstrakcja opiera się bardziej na inżynierii UX niż na absorpcji chain-side. Obie drogi są poprawne; ethereumowa jest bardziej elastyczna kosztem bycia chain-specyficzną, SSP jest bardziej przenośna kosztem większej pracy UI.

Co to znaczy dla ciebie

Trzy wnioski:

1. Doświadczenie „czuje się jak jeden portfel" jest nagłówkową funkcją, nie multisig sam w sobie. Jeśli twój znajomy zapyta „czy SSP to portfel multisig?", technicznie prawdziwa odpowiedź to tak, ale użyteczna odpowiedź to „to portfel z 2 urządzeniami, gdzie jedno dotknięcie na telefonie potwierdza wydatek". To oddaje to, co ludzie naprawdę czują.
2. Tarcie, które widzisz, wykonuje prawdziwą pracę. Za każdym razem, gdy SSP prosi cię o potwierdzenie na telefonie, egzekwuje protokół, który zatrzymuje skompromitowany laptop od opróżnienia twoich funduszy. To tarcie jest głównym powodem, dla którego w ogóle używasz portfela 2-of-2 zamiast hot wallet.
3. Traktuj abstrakcję jak kontrakt, a nie magię. Końcowy artykuł tej serii, Tryby awarii multisig i jak SSP je łagodzi, przechodzi przez to, co się dzieje, gdy każdy fragment abstrakcji pęka — utrata urządzenia, kompromitacja klucza, awaria serwera podpisującego. Przeczytaj go raz. Abstrakcja jest dobrze zaprojektowana, ale zrozumienie trybów awarii to to, co czyni cię tym rodzajem użytkownika self-custody, dla którego cała ta seria istnieje.