Dotychczas w tej serii pokryliśmy czym jest multisig i jaki próg wybrać. Oba artykuły opisywały zachowanie portfela multisig — m z n kluczy podpisuje, chain sprawdza próg, pieniądze się ruszają. Żaden nie mówił wiele o tym, jak portfel jest faktycznie złożony pod spodem. To jest ten artykuł.
Wersja krótka: kiedy SSP tworzy ci portfel, nie generuje po prostu dwóch losowych kluczy i nie kończy roboty. Generuje je w sposób zgodny z udokumentowanym standardem zwanym BIP48, tak by wynikowy portfel był interoperacyjny, odzyskiwalny w oprogramowaniu innym niż SSP, i przewidywalny do inspekcji on-chain. To jest artykuł, który wyjaśnia, czym jest BIP48, dlaczego istnieje, i dlaczego „ten portfel używa BIP48" jest jednym z najnudniejszych-i-najważniejszych zdań w multisig.
TL;DR
- Ścieżka derywacji to droga od pojedynczej seed phrase do konkretnego klucza (i adresu) w portfelu. Znormalizowane ścieżki takie jak BIP44 / BIP48 pozwalają różnemu oprogramowaniu portfeli dojść do tych samych kluczy z tej samej seed.
- BIP48 to spec konkretnie dla portfeli multisig. Mówi: oto kanoniczna ścieżka derywacji dla
mkluczy składających się na portfel 2-of-3, 3-of-5 itd., przez główne typy skryptów wyjściowych. - SSP używa BIP48. To znaczy, że dwie seedy wygenerowane przez twój portfel SSP są używalne z dowolnego innego portfela zgodnego z BIP48 (Sparrow, Electrum, descriptors Bitcoin Core) — nie tylko z SSP samego.
- BIP48 naprawia problem, który miała wcześniejsza spec multisig (BIP45): czysto rozdziela klucze dla różnych typów skryptów (legacy, P2SH-wrapped SegWit, native SegWit, Taproot), żeby jedna seed phrase mogła pomieścić je wszystkie bez kolizji.
- Nie musisz ręcznie babrać się ze ścieżkami derywacji, żeby używać SSP. Powinieneś wiedzieć, że istnieją, żeby „odzyskiwanie portfela" nie wydawało się magią — i żebyś rozumiał, na co tak naprawdę mapuje się twoja seed.
30-sekundowa wycieczka po ścieżkach derywacji
Zanim BIP48 mógł cokolwiek znaczyć, podlegająca maszyneria musiała istnieć. Tą maszynerią jest BIP32: portfele hierarchical deterministic (HD). Główna idea: jeden klucz mistrzowski — wyprowadzony z seed phrase — może deterministycznie wytworzyć nieskończone drzewo kluczy potomnych. Przejdź konkretną ścieżką przez drzewo i zawsze dojdziesz do tego samego klucza potomnego. Przejdź inną — dojdziesz do innego.
Ścieżki wyglądają tak:
m / purpose' / coin_type' / account' / change / index
Na przykład ścieżka BIP44 m / 44' / 0' / 0' / 0 / 0 dochodzi do pierwszego adresu odbiorczego pierwszego konta Bitcoina według reguł BIP44. Zamień coin_type na 60' i jesteś w przestrzeni Ethereum; zamień purpose na 84' i jesteś w przestrzeni BIP84 (native SegWit); i tak dalej. Apostrof (') to derywacja hardened — dziecka nie da się odwrócić do rodzica. Każdy segment po mistrzu to liczba 32-bitowa, partycjonowana umownie.
To jest część, która zwykle się rozpływa: ścieżka to metadata, nie sekret. Każdy, kto zna twoją ścieżkę i twój klucz prywatny (lub klucz rozszerzony), może wyprowadzić te same adresy. Ścieżka mówi portfelowi gdzie patrzeć. Seed mówi mu co tam jest.
Po przyjazne przypomnienie, czym sama seed jest, post seed phrase best practices jest wstępnym wymogiem.
Co specyfikuje BIP48
BIP48 mieszka pod m / 48' / coin_type' / account' / script_type' / change / index. Ciekawym dodatkiem jest script_type' — przedostatni segment.
Ten segment koduje, jakiego typu wyjście multisig ścieżka obsługuje:
0'→ P2SH (multisig legacy)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ multisig odpowiadający Taproot (zgodnie z poprawkami BIP48)
To ma znaczenie, bo w praktyce ten sam zestaw cosignersów m-of-n wytwarza różne adresy on-chain zależnie od tego, którego skryptu wyjścia użyto. Bez BIP48 portfel mógłby cicho używać jednego typu, oprogramowanie do odzysku zakładać inny, a wynikiem byłyby dwa portfele, które wyglądają, jakby powinny wyprowadzać te same monety — ale nie wyprowadzają, bo liczą różne adresy.
BIP48 ustala też segment purpose' na 48', więc ścieżki multisig nie mogą kolidować ze ścieżkami single-sig BIP44/BIP49/BIP84. Jedna seed może trzymać portfel single-sig pod BIP84 i portfel multisig 2-of-2 pod BIP48, bez ingerencji. Każdy mieszka we własnym poddrzewie.
Poza samą ścieżką BIP48 specyfikuje, jak klucze publiczne cosignersów ("xpubsy") powinny być uporządkowane przy konstrukcji wyjścia multisig. Reguła kanoniczna to leksykograficzne uporządkowanie kluczy publicznych przed włożeniem ich do redeem script. To usuwa niejednoznaczność — każdy portfel zgodny z BIP48 budujący z tych samych xpubsów liczy ten sam adres. Bez tej reguły dwa portfele mogłyby łączyć te same klucze w różnych kolejnościach i lądować na różnych adresach z tą samą regułą redeem.
Jeśli chcesz przeczytać spec dosłownie, mieszka w repo Bitcoin BIPs (bips/bip-0048.mediawiki).
Jak SSP używa BIP48 w praktyce
Kiedy konfigurujesz portfel SSP, generowane są dwie seed phrase — jedna w rozszerzeniu przeglądarki, jedna w aplikacji mobilnej SSP Key. Każda seed phrase odpowiada mistrzowskiemu kluczowi prywatnemu. Z każdej mistrzowskiej SSP wyprowadza ścieżkę BIP48 dla odpowiedniego chaina (Bitcoin, Ethereum, Flux i reszta wspieranego przez SSP zestawu) pod script_type' = 2' (native SegWit na Bitcoinie; odpowiednie formy kanoniczne na innych chainach gdzie ma to zastosowanie).
Xpubsy obu sygnatariuszy są następnie wymieniane. Każda strona ma teraz ten sam zestaw dwóch xpubsów, leksykograficznie uporządkowanych według BIP48. Z tej pary każda strona niezależnie liczy ten sam adres. Dwie połówki nigdy nie dzielą klucza prywatnego — między urządzeniami chodzą tylko klucze publiczne.
Kiedy odbierasz pieniądze, pokazywany ci adres to adres wyprowadzony BIP48-em z obu xpubsów. Kiedy wydajesz, każde urządzenie podpisuje tę samą transakcję pod własnym kluczem prywatnym. Redeem script on-chain odwołuje się do obu kluczy publicznych; sieć sprawdza oba podpisy. To cały protokół.
Powód, dla którego to ma znaczenie w scenariuszu odzysku: gdyby SSP jako produkt zniknął jutro, nadal trzymałbyś dwie seed phrase zgodne z BIP48. Załadowanie obu w Sparrow (lub w dowolnym innym portfelu zdolnym do multisig wspierającym ścieżki BIP48 używane przez SSP) odbudowuje ten sam portfel, pod tymi samymi adresami, z pełną zdolnością wydatkowania. Portfel nie mieszka w SSP — mieszka on-chain, a seedy plus spec BIP48 wystarczają, żeby do niego dotrzeć z dowolnego miejsca.
Ta własność jest sporą częścią tego, dlaczego self-custody-without-cold-storage traktuje portfel SSP 2-of-2 jako poważny portfel, a nie ciekawostkę o smaku custodial. Jest odzyskiwalny z otwartych standardów.
Dlaczego BIP48 zamiast BIP45 (i nie BIP44)
Wcześniejszą spec multisig był BIP45. Była uczciwą pierwszą próbą: m / 45' / cosigner_index' / change / index, z cosigner_index' kodującym, którym cosignersem jesteś w portfelu. Patrząc wstecz miała dwa problemy.
Po pierwsze, cosigner_index' wpiekał porządek w samą ścieżkę. To znaczyło, że kolejność, w której sygnatariusze byli dodawani, wpływała na derywację, co czyniło wspólny setup kruchym — pomyl porządek i wyprowadzasz inne adresy niż twój cosigners. BIP48 rozwiązuje to, usuwając cosigner index ze ścieżki w całości i pozwalając, by leksykograficzny porządek kluczy publicznych załatwił to.
Po drugie, BIP45 nie rozdzielał po typie skryptu. Ta sama ścieżka byłaby ponownie używana niezależnie od tego, czy portfel używał legacy P2SH multisig, czy SegWit-wrapped multisig. To tworzyło ten sam problem kolizji-adresów-ale-nie-tych-samych-monet opisany powyżej.
BIP44, ogólniejsza spec HD, nigdy nie pretendowała do pokrywania multisig. Próby przeładowania BIP44 ścieżkami multisig tworzyły własne konflikty. BIP48 było jawną poprawką: dedykowany purpose number, jawny slot script-type, i deterministyczne uporządkowanie kluczy. Dziś większość nowoczesnych portfeli multisig konweruje na nim; jest standardem de facto.
Po głębszą historię, jak to łączy się z kolejnym rozdziałem multisig — agregacją Schnorra, gdzie wiele podpisów kompresuje się do jednego — następny artykuł tej serii, Schnorr signatures and multisig aggregation, podejmuje wątek.
Co to znaczy dla interoperacyjności
Najczystszy test „czy ten portfel multisig jest naprawdę self-custodial?" to: czy mogę go odzyskać bez oprogramowania portfela? Jeśli odpowiedź brzmi „tak" — używając udokumentowanych seedów, udokumentowanej ścieżki derywacji i standardowych narzędzi — portfel jest prawdziwie twój. Jeśli odpowiedź brzmi „nie", portfel ma ukryte elementy custodial.
Zgodność SSP z BIP48 to to, co pozwala nam odpowiedzieć tak. Seed phrase to BIP39 (standardowy mnemonik), derywacja to BIP48, konstrukcja adresu jest kanonicznie BIP48. Każdy portfel mówiący tymi samymi standardami może odbudować portfel.
Dlatego wprowadzenie Meet SSP Wallet ramuje SSP jako „self-custody z multisigiem 2-of-2", a nie jako usługę zarządzaną. Standardy pod spodem są powodem, dla którego to ramowanie jest uczciwe.
Co to znaczy dla ciebie
Trzy wnioski:
- Nie musisz zapamiętywać ścieżek, żeby używać SSP. Liczba
m/48'/0'/0'/2'/0/0to nie jest coś, co normalny użytkownik powinien kiedykolwiek wpisać. Ale wiedza, że istnieje, sprawia, że „mogę odzyskać ten portfel bez SSP" jest prawdziwym stwierdzeniem zamiast marketingowym. - Twoje dwie seedy są interoperacyjne. Jeśli kiedyś będziesz musiał odzyskać w portfelu multisig firm trzecich, BIP48 plus twoje dwie seedy BIP39 plus
coin_typechaina to przepis. Checklist self-custody wymienia to jako krok próbny nie bez powodu. - Portfel multisig, który nie używa BIP48 (ani podobnego), zasługuje na pytania. Jeśli produkt nie potrafi ci powiedzieć dokładnie, jak adresy są wyprowadzane z twoich kluczy, to nie jest self-custody — to custody z dodatkowymi krokami. Zgodność ze standardami jest tym, co czyni twierdzenie „twoje klucze, twoje monety" weryfikowalnym.
