Portfele MPC a multisig

Zarówno portfele MPC, jak i multisig obiecują ten sam nagłówek: żadnego pojedynczego punktu kompromitacji. Obydwa tej obietnicy dotrzymują. Ale dochodzą do tego różnymi drogami, a drogi mają różne konsekwencje dla tego, co dzieje się, gdy coś pójdzie źle — a to jedyny moment, w którym model bezpieczeństwa naprawdę ma znaczenie.

Ten artykuł to techniczne starcie twarzą w twarz. Jeśli najpierw chcesz szerszego przeglądu wyborów w samodzielnym przechowywaniu, porównanie sposobów samodzielnego przechowywania obejmuje całe pole, łącznie z portfelami sprzętowymi i zwykłymi frazami seed.

Dwie różne odpowiedzi na ten sam problem

Problem w obu przypadkach stawia się tak samo: jeden sekret kontrolujący wszystko jest nie do przyjęcia, więc rozproszmy uprawnienia.

MPC dzieli klucz. Pojęciowo istnieje jeden klucz prywatny, ale nigdzie nie jest on składany. Zamiast tego jego udziały mieszkają w różnych miejscach, a protokół kryptograficzny pozwala tym udziałom współpracować przy wytworzeniu podpisu, bez tego by którakolwiek strona poznała cały klucz.

Multisig wymaga wielu kluczy. Istnieje naprawdę kilka niezależnych kluczy prywatnych. Adres koduje regułę — tyle a tyle z tych kluczy musi podpisać — a blockchain egzekwuje tę regułę przy weryfikacji transakcji.

Rozróżnienie brzmi akademicko. Nie jest. Jedno to fakt o kryptografii, drugie to fakt o blockchainie. To, co wie łańcuch, decyduje o tym, co się stanie, gdy któryś element systemu zawiedzie.

Jak naprawdę działa MPC

MPC — obliczenia wielostronne, w tym kontekście zwykle schematy podpisu progowego — pozwala kilku stronom wspólnie wyliczyć podpis pod wiadomością, podczas gdy każda trzyma tylko udział klucza podpisującego. NIST prowadzi projekt kryptografii progowej, jeśli chcesz ujęcia formalnego.

Wynikiem jest pojedynczy, zwyczajny podpis. On-chain transakcja portfela MPC jest nie do odróżnienia od transakcji podpisanej przez jedną osobę jednym kluczem. To daje realne korzyści: działa na każdym łańcuchu, kosztuje tyle co transakcja z jednym podpisem i nie zdradza obserwatorom łańcucha niczego o twoim układzie bezpieczeństwa.

Konsekwencja tej samej właściwości wymaga ostrożności. Skoro łańcuch widzi zwykły podpis, łańcuch również niczego nie egzekwuje w kwestii twojej polityki. Ile jest udziałów, kto je trzyma i ile musi współdziałać, to fakty o oprogramowaniu i serwerach, a nie o rejestrze. Zmień oprogramowanie, a zmienisz politykę.

Druga rzecz do sprawdzenia to przechowywanie udziałów. Wiele konsumenckich portfeli MPC trzyma jeden udział w infrastrukturze dostawcy. To często właśnie umożliwia gładkie odzyskiwanie — i zarazem oznacza, że dalsze istnienie i współpraca dostawcy są nośnymi elementami twojego układu. Niektóre projekty dobrze to łagodzą, dając udziały do wyeksportowania albo niezależne ścieżki kopii zapasowych. Pytanie nie brzmi, czy MPC da się zrobić dobrze; brzmi, czy konkretny produkt, który rozważasz, zrobił to w sposób, który potrafisz zweryfikować.

Jak naprawdę działa multisig

W multisigu polityka jest częścią adresu. Na Bitcoinie i innych łańcuchach UTXO adres wyprowadza się ze skryptu wymieniającego klucze publiczne i próg; wydatek, który nie niesie dość ważnych podpisów, jest po prostu nieważny, a każdy węzeł sieci go odrzuca. Na łańcuchach z inteligentnymi kontraktami odpowiednikiem jest konto, którego kod nie zadziała bez wymaganych zatwierdzeń.

Nikomu nie trzeba ufać, że zastosuje regułę, bo stosowanie reguły to właśnie to, co robi sieć. Gdyby jutro zniknęło całe zaangażowane oprogramowanie portfela, reguła nadal by obowiązywała, a każdy z kluczami i dowolnym zgodnym narzędziem wciąż mógłby wydawać.

Koszty także są realne. Zarządzasz kilkoma kluczami zamiast jednym, kopie zapasowe się komplikują, a transakcja jest większa — na Bitcoinie więcej podpisów to więcej bajtów i nieco wyższa opłata. Twoja polityka jest też widoczna on-chain, co jest kwestią prywatności: obserwator zobaczy, że adres jest 2 z 3, choć nie zobaczy, kto co trzyma.

Czym jest multisig i dlaczego ma znaczenie omawia model głębiej.

Gdzie dokładnie plasuje się SSP

SSP to multisig 2 z 2, ale uczciwość wymaga tu szczegółu, bo implementacja nie jest identyczna na każdym łańcuchu.

Na Bitcoinie i innych łańcuchach UTXO to natywny multisig na poziomie skryptu przez BIP-48. Dwa klucze, jeden skrypt, egzekwowany przez konsensus.

Na Ethereum i innych łańcuchach EVM nie ma odpowiednika natywnego skryptu, więc SSP używa konta inteligentnego weryfikującego zagregowany podpis Schnorra wytworzony z obu kluczy. Twoje dwa urządzenia wykonują protokół w stylu MuSig2, a łańcuch widzi jeden podpis — mechanicznie kształtem bliżej temu do MPC niż do bitcoinowego skryptu multisig.

Rozróżnienie, które ma znaczenie, nie brzmi „zagregowany czy nie". Brzmią tak te dwa fakty, obowiązujące na każdym łańcuchu wspieranym przez SSP:

• Oba klucze powstają na twoich urządzeniach i tylko ty je trzymasz. SSP nie trzyma żadnego udziału, żadnego klucza ani żadnego częściowego sekretu. Na naszych serwerach nie ma udziału, który dałoby się zgubić, zająć albo przetrzymać jako zakładnika.
• Wymóg jest on-chain. Na EVM kod konta inteligentnego nie autoryzuje transakcji bez podpisu, który mogą wytworzyć wyłącznie oba twoje klucze. Ten kod jest wdrożony, publiczny i przeszedł audyt — to nie polityka, którą nasze oprogramowanie postanawia stosować.

Na Solanie to program on-chain bez twórcy i bez klucza administratora, w którym adres skarbca sam jest odciskiem palca zbioru członków i progu. Inny mechanizm, ta sama gwarancja.

Jeśli interesuje cię kryptografia agregacji, podpisy Schnorra i agregacja multisig tłumaczy, jak jeden podpis może wymagać dwóch kluczy.

Tryby awarii obok siebie

Modele bezpieczeństwa najlepiej porównywać, pytając, co się psuje.

Jedno urządzenie zostaje skompromitowane. Oba modele to przeżywają. Napastnik ma jeden udział albo jeden klucz i nie podpisze sam.

Dostawca znika. Multisig przeżywa — potrzebne są tylko klucze i reguła on-chain. MPC przeżywa tylko wtedy, gdy potrafisz zdobyć i użyć swoich udziałów bez oprogramowania dostawcy, co zależy wyłącznie od projektu.

Dostawca zostaje zmuszony do działania. Jeśli dostawca trzyma udział, ten udział można potencjalnie wydobyć pod przymusem prawnym, a zależnie od schematu może to wystarczyć — wraz z innym udziałem — do ruszenia środków. Jeśli dostawca nie trzyma niczego — jak w SSP, gdzie oba klucze są twoje — nie ma czego wymuszać.

Tracisz jeden klucz albo udział. To zależy od progu, nie od technologii. Układ 2 z 3 dowolnego rodzaju znosi jedną stratę; układ 2 z 2 dowolnego rodzaju nie. Co się dzieje, gdy jeden z twoich kluczy zostanie skompromitowany przechodzi konkretnie przez przypadek SSP.

Oprogramowanie portfela kłamie ci o tym, co podpisujesz. Tutaj żaden model nie pomaga i warto powiedzieć to wprost. Rozproszenie uprawnień chroni przed skradzionym kluczem; nie chroni przed zatwierdzeniem złej transakcji. Dlatego ciekawe pytanie dla obu modeli brzmi: co twoje urządzenia weryfikują niezależnie przed podpisaniem — dekodując surową transakcję zamiast wierzyć opisowi z serwera.

Gdzie każdy wygrywa

MPC wygrywa na łańcuchach bez dobrych prymitywów multisig, w rozmiarze transakcji i opłatach, w prywatności układu, a często i w wygodzie — zwłaszcza przy odzyskiwaniu, gdzie dobrze zaprojektowany produkt MPC bywa nieporównanie przyjaźniejszy niż żonglowanie kilkoma kopiami fraz seed.

Multisig wygrywa w weryfikowalności. Reguła siedzi w rejestrze. Nie musisz wierzyć opisowi modelu bezpieczeństwa; możesz przeczytać adres albo kontrakt i zobaczyć politykę. Wygrywa też w niezależności: układ multisig z kluczami, które trzymasz ty, nie ma w swoim modelu zaufania żadnej firmy.

Nie ma sprzeczności w tym, by dla różnych celów preferować różne odpowiedzi. Małe saldo na co dzień w dobrze zbudowanym portfelu MPC i długoterminowa pozycja w multisigu z kluczami trzymanymi osobno to całkiem spójny układ.

O co zapytać, zanim się zwiążesz

W którąkolwiek stronę się skłaniasz, te cztery pytania oddzielają mocną implementację od słabej.

1. Kto trzyma każdy klucz albo udział i czy mogę zdobyć wszystkie? Jeśli uczciwa odpowiedź zawiera „dostawca, i nie", wybrałeś model z kontrahentem.
2. Co się stanie, jeśli dostawca zniknie jutro? Powinna istnieć udokumentowana ścieżka, która go nie obejmuje. Przetestuj ją, zanim będzie potrzebna.
3. Gdzie mieszka polityka? W skrypcie albo kontrakcie on-chain, czy w oprogramowaniu? Obie opcje mogą być w porządku, ale tylko jedna przeżyje zmianę oprogramowania.
4. Co każde urządzenie weryfikuje przed podpisaniem? Drugi klucz nie wnosi nic, jeśli oba urządzenia podpisują na ślepo to, co przyśle serwer. Tryby awarii multisiga i jak SSP je łagodzi przechodzi przez to oraz pozostałe sposoby, na jakie układ wielokluczowy da się w praktyce podkopać.

Jeśli chcesz modelu, na którym zbudowano SSP, wyjaśnionego od podstaw, zacznij od czym jest multisig 2 z 2. A jeśli troska, która cię tu przywiodła, dotyczy utraty klucza, a nie utraty kontroli nad nim, odzyskiwanie społeczne kontra multisig omawia drugą rodzinę odpowiedzi.