W poprzednim artykule przeszliśmy, jak SSP faktycznie buduje portfel multisig on-chain: ścieżki BIP48, dwa xpubs w porządku leksykograficznym, redeem script, względem którego chain sprawdza. Cały ten mechanizm jest zbudowany na konkretnym schemacie podpisu — ECDSA na krzywej secp256k1, tym samym schemacie, z którym Bitcoin wystartował w 2009 i który większość chainów odziedziczyła.
Ten artykuł jest o drugim schemacie podpisu — Schnorr — i co się zmienia, gdy budujesz multisig na nim. Nagłówkowa zmiana to fakt, że Schnorr wspiera agregację: przy odpowiednim protokole n podpisów od n cosignersów można połączyć w jeden podpis, który on-chain wygląda jak normalny podpis pojedynczego klucza. Portfel zachowuje się jak portfel multisig, ale chain nigdy nie widzi „multi-ości". To ma realne konsekwencje dla fee, prywatności i tego, jakie rodzaje multisig stają się ekonomicznie sensowne.
TL;DR
- ECDSA to to, czym podpisuje większość obecnego multisig (w tym SSP dziś). Każdy cosigners produkuje osobny podpis; chain sprawdza wszystkie. Koszt i ślad skalują się z
n. - Schnorr to inny schemat podpisu, włączony w Bitcoinie przez upgrade Taproot z 2021. Ma matematyczną własność — liniowość — której ECDSA nie ma. Liniowość pozwala wiele podpisów Schnorra zsumować w jeden ważny podpis dla połączonego klucza.
- MuSig2 to nowoczesny, praktyczny protokół, który tę matematyczną własność zamienia w użyteczny protokół multisig.
ncosignersów wykonuje krótki interaktywny protokół, każdy wnosząc jedną rundę nonce'ów i jeden podpis cząstkowy; wynikiem jest pojedynczy podpis Schnorra, nieodróżnialny od podpisu pojedynczego klucza. - To jednoznaczna wygrana po stronie weryfikacji — fee, puchnięcie blockchaina i prywatność wszystkie korzystają. Nie jest darmową wygraną po stronie podpisywania: agregacja wymaga starannej obsługi nonce'ów, a buggy implementacja może wyciekać klucze prywatne.
- SSP dziś używa BIP48 + ECDSA multisig na chainach, które wspiera. Roadmap to dodanie ścieżek Schnorr/MuSig2 tam, gdzie chain je wspiera, bez łamania istniejącego modelu 2-of-2, który użytkownicy już mają.
Szybkie przypomnienie, co robi podpis
Cyfrowy podpis dowodzi weryfikatorowi dwóch rzeczy: ta konkretna wiadomość została podpisana przez kogoś trzymającego klucz prywatny dla tego klucza publicznego. On-chain „wiadomość" to hash transakcji, „klucz publiczny" to adres (lub to, co adres wyprowadza), a „weryfikator" to każdy węzeł sieci. Jeśli podpis się zgadza, transakcja jest ważna; jeśli nie, jest odrzucana.
ECDSA — schemat, którego używają Bitcoin i większość chainów EVM — jest dobrze zrozumiały, konserwatywny i działa dobrze dla przypadku pojedynczego sygnatariusza. Kłopot zaczyna się, gdy chcesz, by wielu sygnatariuszy autoryzowało tę samą transakcję. ECDSA nie ma sposobu na łączenie podpisów. Jeśli chcesz two-of-two, chain musi przechować oba podpisy i oba sprawdzić. Three-of-five, pięć podpisów. Transakcja rośnie wraz z liczbą cosignersów.
What is multisig opisuje część protokołu — m z n kluczy, reguły redeem, chain wymuszający próg. Czego ten wcześniejszy tekst nie rozwija, to koszt: pod ECDSA wszystkie te podpisy żyją w transakcji. Transakcja P2WSH 2-of-2 jest naprawdę większa i droższa do wyemitowania niż transakcja single-sig dająca ten sam efekt.
Co zmienia Schnorr
Podpisy Schnorra, pierwotnie zaproponowane pod koniec lat 80., zostały pominięte w pierwotnym designie Bitcoina z powodu ówczesnej niepewności patentowej. Są matematycznie czystsze niż ECDSA w jednym konkretnym sensie: są liniowe. Jeśli s1 to ważny podpis nad wiadomością pod kluczem P1, a s2 to ważny podpis nad tą samą wiadomością pod kluczem P2, to s1 + s2 jest ważnym podpisem nad tą wiadomością pod P1 + P2. Zarówno klucze, jak i podpisy się sumują.
Czemu to ma znaczenie: nagle staje się możliwe łączenie podpisów zanim trafią one na chain. Zamiast przechowywać dwa podpisy w transakcji, przechowujesz jeden — sumę. Weryfikator sprawdza ten jeden podpis przeciwko sumie dwóch kluczy publicznych, którą obaj sygnatariusze potrafią obliczyć z wyprzedzeniem. Z perspektywy chaina wynikowa transakcja wygląda nieodróżnialnie od transakcji podpisanej przez pojedynczy klucz.
ECDSA tego nie potrafi. Matematyka ECDSA zawiera odwrotność multiplikatywną, która łamie liniowość; sumy podpisów ECDSA nie są ważnymi podpisami. Dlatego multisig oparty o ECDSA musi wysyłać wszystkie pojedyncze podpisy on-chain. Chain inspektuje każdy z osobna.
Bitcoin wypuścił podpisy Schnorra (przez BIP340) w ramach soft forku Taproot z 2021. Same podpisy są nieco mniejsze niż podpisy ECDSA (64 bajty vs ~71), ale o wiele większa sprawa to to, co ta liniowość umożliwia, gdy połączysz ją z multisig.
MuSig2 — multisig, który on-chain wygląda jak jeden podpis
Uczciwa wersja „możesz sumować podpisy Schnorra" mówi, że musisz to robić ostrożnie. Naiwne podejście — niech każdy cosigners wybierze nonce, podzieli się swoim podpisem cząstkowym, wszystko zsumować — wycieka materiał klucza pod powtarzanym podpisywaniem i jest podatne na klasę ataków typu „rogue key". Praktyczny protokół agregacji musi się bronić przed obojgiem.
MuSig2 to wynik mniej więcej dekady dopracowywania tego problemu. To de facto standard dla multisig Schnorra n-of-n: w chwili podpisywania cosignersi wymieniają dwie rundy nonce'ów, każdy produkuje podpis cząstkowy, a jeden z nich sumuje cząstkowe w finalny podpis zagregowany. Wynikiem jest pojedynczy podpis Schnorra, ważny przeciwko pojedynczemu zagregowanemu kluczowi publicznemu, on-chain nieodróżnialny od podpisu pojedynczego klucza.
Kilka ważnych punktów o MuSig2:
- Obecnie to
n-of-n. By uzyskać prawdziwem-of-n(np. 2-of-3) pod agregacją, potrzebna jest dodatkowa machineria — FROST to wiodąca propozycja — i wciąż jest produkcyjnie dopracowywana. Więc w 2026 to, co SSP czysto by zagregował, to default 2-of-2. Konfiguracje 2-of-3 i wyższe z artykułu-wyboru dalej w większości używają widoczności on-chain w stylu ECDSA. - Nadal wymaga obu cosignersów online, by podpisać. Agregacja nie zmniejsza potrzebnej liczby sygnatariuszy; tylko kompresuje końcowe wyjście. UX jest takie samo jak dziś — dwa urządzenia podpisują tę samą transakcję — ale ślad on-chain wyniku jest mniejszy.
- Buggy implementacja MuSig2 może wyciekać klucze. Obsługa nonce'ów jest subtelna. Wdrożenia produkcyjne opierają się z tego powodu na dobrze zaaudytowanych bibliotekach (moduł MuSig2 z
libsecp256k1, stackrust-bitcoin, itp.).
Co to znaczy dla SSP dziś
SSP dziś, na każdym chainie, który wspiera, używa multisig ECDSA wyprowadzonego z BIP48. Dwa urządzenia, dwa klucze prywatne, dwa osobne podpisy on-chain. To jest poprawne, jest zaudytowane (przez Halborn — zobacz referencję inside-ssp-2025-halborn-audits w istniejącym tekście 2-of-2) i jest interoperacyjne z każdym innym portfelem zgodnym z BIP48. Wadą jest to, że płacisz pełny on-chain koszt 2-of-2.
Roadmap stąd, prostym językiem: dodać ścieżkę kodu Schnorr/MuSig2 dla Bitcoina (gdzie Taproot jest aktywny i stabilny), która podpisuje ten sam portfel 2-of-2, używając agregacji zamiast tego. Semantyka progowa portfela nie zmienia się — oba urządzenia nadal muszą podpisywać. Bajty on-chain się kurczą, a wynikowa transakcja wygląda jak wydatek single-sig.
Dla użytkownika to objawiałoby się głównie jako:
- Nieco niższe fee Bitcoina na transakcję.
- Poprawiona prywatność — portfel przestaje krzyczeć „jestem portfelem multisig" do analityki chain.
- Szybsza rekoncyliacja dla UI portfela (nieco mniej danych do pobrania i sparsowania na adres).
To nie jest — i warto powiedzieć to wprost — upgrade bezpieczeństwa. Kryptografia jest porównywalnie twarda, tylko inaczej strukturyzowana. Powodem przyjęcia jest efektywność i prywatność, nie surowe bezpieczeństwo.
Co to znaczy dla kosztu, prywatności i UX
Trzy miejsca, w których to ląduje, gdy agregacja jest powszechnie wdrożona na chainie:
Koszt. Bitcoin nalicza fee mniej więcej według rozmiaru transakcji w vbajtach. Transakcja ECDSA P2WSH 2-of-2 jest znacząco większa niż odpowiadająca jej transakcja Taproot-MuSig2. Dla portfeli z niskim saldem wysyłających małe kwoty, względne oszczędności fee mogą wynieść 20–30%. Dla biznesów o wysokim throughpucie, bezwzględne oszczędności na rocznych fee to realne pieniądze.
Prywatność. Dziś, gdy portfel emituje wydatek P2WSH 2-of-2, ten fakt jest widoczny dla każdego korzystającego z eksploratora blockchaina. Wyrafinowane firmy chain-analytics klastrują adresy wg wzorca wydatków, a „ten adres to multisig" to silny sygnał klastra. Wydatek Schnorr-zagregowany wygląda identycznie jak wydatek single-sig. Sygnał klastra znika.
UX. UX podpisywania w SSP — podpisz w przeglądarce, potem potwierdź na telefonie — nie zmienia się. Oba urządzenia nadal produkują podpisy cząstkowe; portfel po prostu łączy je przed wysłaniem zamiast wysyłać oba. Z perspektywy użytkownika jedyna widoczna zmiana to „portfel wydaje się tańszy w użyciu".
Na horyzoncie jest też głębsza wygrana UX. Gdy agregacja m-of-n (przez FROST lub podobne) będzie produkcyjnie gotowa, mógłbyś wyobrazić sobie portfel SSP 2-of-3 — jak setup solo z recovery, który opisuje poprzedni artykuł — który on-chain wygląda jak zwykły portfel single-sig. Trzeci klucz „recovery" jest naprawdę trzecim kluczem podpisującym, ale chain nigdy nie musi o tym wiedzieć.
Co to znaczy dla ciebie
Trzy wnioski:
- Nie musisz myśleć o Schnorrze, by używać SSP poprawnie. Setup 2-of-2, który masz dziś, jest zbudowany na dobrze zaaudytowanym multisig ECDSA i pozostaje taki niezależnie od tego, jak wyląduje agregacja. Następny artykuł serii (social recovery vs multisig) celowo ignoruje agregację, bo pytanie kto może wydać jest niezależne od tego, jak wygląda podpis on-chain.
- Agregacja to upgrade „fee i prywatności", nie „bezpieczeństwa". Jeśli kiedyś zobaczysz portfel sprzedający „MuSig2 = bezpieczniejszy", bądź sceptyczny. Bezpieczeństwo kryptograficzne dobrze zaimplementowanego MuSig2 jest porównywalne z dobrze zaimplementowanym multisig ECDSA; wygrane są gdzie indziej.
- Patrz na wsparcie chaina, nie na marketing portfela. Schnorr jest aktywny na Bitcoinie i jest przyjmowany w świecie EVM przez account abstraction. Chainy, które go dobrze wspierają, to te, gdzie SSP najpierw wyda zagregowany multisig; gdzie indziej BIP48 + ECDSA pozostaje właściwym i bezpiecznym defaultem.
Następny artykuł tej serii, Social recovery vs multisig, przenosi fokus z kryptografii na operacje: kiedy sięgasz po multisig, a kiedy social recovery bije? Oba chronią przed utratą kluczy; odpowiadają na różne pytania. Po szybkie przypomnienie, jakich urządzeń SSP dziś używa i czemu, Meet SSP Wallet pozostaje punktem startowym.
