Taproot zmierza do Bitcoina: jak to działa, jego historia i implikacje

Podpisy Taproot i Schnorr będą dostępne na Bitcoinie w bloku 709,632 XNUMX. Będzie to ogromne, fundamentalne osiągnięcie, które będzie można kontynuować w przyszłości. Minęły cztery lata od chwili uruchomienia w sieci funkcji Segregated Witness, czyli naszej ostatniej dużej aktualizacji protokołu. To tyle, co cykl halveningu!

Pomyśl o tym. Cztery lata od uruchomienia SegWit do uruchomienia Taproot. Powolna, metodyczna cierpliwość, taka jaka powinna być. Jednak historia Taproot/Schnorr sięga znacznie dalej.

Historia korzenia palowego

Niektórzy, którzy są tu od jakiegoś czasu, mogą uznać to za ironię losu, ale pierwsza wzmianka o podpisach Schnorra, o której jestem świadomy, pochodzi w rzeczywistości od byłego programisty Bitcoin Core, który stał się twórcą blockchainu dla przedsiębiorstw, Mike'a Hearna. W 2012 roku on wychowany pomysł nowej krzywej kryptograficznej w odniesieniu do wsadowej weryfikacji podpisów, aby walidacja węzłów była tańsza obliczeniowo. Ostatecznie proponowany przez niego schemat był zależny od podpisów Schnorra.

Adam Back wypowiadał się na temat naiwności systemy zrobić adresy multisig, które w 2014 roku wyglądały jak adresy singlesig, wykorzystując podpisy Schnorra. Włącznie z Gavinem Andresenem Schnorra zamiast ECDSA na swojej liście życzeń zmian, które wprowadziłby w Bitcoinie, gdyby mógł machnąć magiczną różdżką.

Od samego początku istnienia Bitcoina większość programistów aktywnie zaangażowanych w Bitcoin Core chciała podpisów Schnorra i zawsze istniał dość solidny konsensus co do ich wyższości nad podpisami ECDSA. W rzeczywistości można argumentować, że ECDSA utworzono specjalnie ze względu na opatentowanie schematu podpisu Schnorra i istniało ogromne zapotrzebowanie na schemat podpisu kryptograficznego o otwartym kodzie źródłowym, nieobciążony patentami.

Schnorr jest znacznie wydajniejszy i łatwiejszy w obsłudze (można dodawać, odejmować itp. elementy z podpisów, a jeśli zostanie wykonany poprawnie, może nadal pozostawiać użytkownikom ważne podpisy, kiedy powinni je mieć) niż ECDSA. Na przestrzeni lat w większości zastosowań kryptograficznych korzystanie z ECDSA było raczej koniecznością niż pożądaniem.

Merkelizowane abstrakcyjne drzewa składniowe (MAST), połowa Taproot nadchodzącej aktualizacji Taproot, mają podobną długą historię. Nie mogę znaleźć cytatu, ale całkiem wyraźnie pamiętam, że widziałem to zdanie rzucone przez osoby takie jak Peter Todd na Bitcointalk.org około 2013 lub 2014 roku.

Oryginał BIP dla MAST został zaproponowany przez Johnsona Lau w 2016 r. Propozycja ta również odnotowała pewne ożywienie około 2017 r., kiedy Mark Friedenbach, BTCDrak i Kalle Alm podzielili ją na dwa oddzielne PKG (116 i 117) i rozwinął pierwotną propozycję Lau.

MAST pozostawał w zawieszeniu przez następny rok, dopóki Greg Maxwell nie wpadł na początkowy pomysł Taproot i opublikowany go na listę mailingową bitcoin-dev. Jego kluczowym spostrzeżeniem było to, że w każdym przypadku kontraktu między wieloma uczestnikami, jaki przyszedł mu do głowy, istniał „optymalny wynik”, w którym kontrakt mógł zostać rozliczony przez każdego, kto po prostu podpisał odpowiedni wynik, zamiast wymuszać wynik za pomocą bardziej zaawansowanych skryptów i transakcji. Jest to podstawowe założenie, na którym opiera się Taproot, tj. modyfikacja drzewa MAST do zwykłego klucza najwyższego poziomu, który można wydać bez ujawniania, czy drzewo Merkle z innymi warunkami wydawania w ogóle istnieje.

Ostatni fragment tej lekcji historii rozpoczyna się od ogłoszenia Pietera Wiulle’a projekty BIPów dla Schnorr i Taproot w tandemie na listę mailingową w dniu 6 maja 2019 r. Do stycznia 2020 r. formalnie sfinalizowano to w BIP 340, 341 i 342. Od tego momentu pozostało już tylko wiele drobnych szczegółów dopracowywania na poziomie wdrożenia, pewien okres przeglądu, a następnie długotrwała walka o mechanizmy aktywacji. To prowadzi nas do chwili obecnej, tuż przed aktywacją.

Znaczenie podpisów Schnorra

O co więc właściwie chodzi z podpisami Schnorra? Cóż, na początek zmniejszają transakcje. Podpis ECDSA ma zwykle rozmiar około 72 bajtów dla pojedynczego podpisu w transakcji. Podpisy Schnorra rejestrują maksymalnie 64 bajty na podpis. Oznacza to około 12% oszczędności w rozmiarze w porównaniu z ECDSA dla każdego podpisu Schnorra. Jest to zarówno bezpośrednia korzyść dla osoby korzystającej z Schnorr, która zapłaci mniej opłat niż użytkownik ECDSA, ale jest to również bezpośrednia korzyść dla osób niekorzystających z Schnorr, ponieważ wymaga przechowywania nieco mniej danych w łańcuchu bloków w celu przetworzenia i sprawdzenia czyjegoś Schnorra podpisy.

Przechowywanie mniejszej ilości danych jest zawsze dobre, ale jeszcze lepsze jest zwiększenie efektywności sprawdzania poprawności danych, które musisz przechowywać. Jedna z fajnych właściwości Schnorra, liniowość matematyki, która się za nią kryje, pozwala również na ciekawą właściwość, której potrzebujesz w danych Bitcoin: walidację wsadową. Kiedy Twój węzeł otrzymuje blok z sieci, analizuje każdą indywidualną transakcję i jeden po drugim sprawdza poprawność każdego podpisu.

To w dużej mierze wyjaśnia, dlaczego sprawdzanie poprawności bloków zużywa dużo mocy procesora. Wszystkie podpisy Schnorra można grupować i weryfikować matematycznie na raz, co przypomina łączenie ich w jedną całość i wykonywanie jednej operacji matematycznej zamiast kilku pojedynczych. Zatem im więcej sygnatur Schnorra, tym większe oszczędności obliczeniowe. Jest to ogromny sukces sieci w zakresie skalowania.

Kolejnym ogromnym ulepszeniem, jakie wnosi Schnorr, są skrypty z wieloma podpisami. Każdy adres multisig musi jawnie ujawniać wszystkie indywidualne klucze publiczne biorące udział w skrypcie multisig w czasie spędzania czasu, a każdy klucz zaangażowany w proces wydatkowania musi mieć podpis. Dzięki matematycznym właściwościom Schnorra otwierają się drzwi dla MuSig, standardu wielosygnaturowego. Możesz po prostu dodać klucze i otrzymać jeden klucz publiczny, pod którym każdy udział w kluczu prywatnym będzie mógł podpisać przy użyciu nowych protokołów podpisu. Jonas Nick z Blockstream testowany MuSig2 zajmuje dwie minuty jeden milion uczestnicy adresu multisig do podpisania. Nie można przecenić poprawy skalowania skryptów z wieloma podpisami.

Ten ogromny krok naprzód w dziedzinie skryptów wielopodpisowych ma również ogromny wpływ na profil prywatności i koszt wielu aplikacji zbudowanych na bazie Bitcoina. Kanały Lightning oparte na MuSig mogą teraz łączyć się z całym zestawem anonimowości Schnorr/Taproot UTXO w łańcuchu, ponieważ nikt nie będzie już w stanie rozróżnić faktu, że są to wyjścia typu multisig typu dwa z dwóch.

Będą się wtapiać w całość i wyglądać jak pojedynczy podpis. To samo dotyczy ogólnie każdego multisig UTXO. Będzie to miało wiele konsekwencji dla osób korzystających ze skryptów z wieloma podpisami, aby lepiej chronić swoje chłodnie za pomocą solidniejszego modelu zabezpieczeń i odzyskiwania niż skrypt z pojedynczym podpisem.

Po pierwsze, obserwując łańcuch bloków, nie będzie oczywiste, że używają konfiguracji multisig, więc podobnie jak w przypadku Lightning sprawi, że będą się one komponować ze wszystkim innym. Kluczową zaletą jest jednak aspekt ekonomiczny: używanie obecnie multisygnatury wymaga dostarczenia osobnego podpisu dla każdego klucza zaangażowanego w ostateczne wydanie UTXO. Dzięki Schnorr/MuSig wszystko zostanie skompresowane w pojedynczy podpis dla jednego połączonego klucza publicznego, co oznacza, że ​​wydawanie multisig UTXO przy użyciu MuSig stanie się znacznie tańsze, ponieważ wypycha mniej danych do łańcucha bloków.

Ostatnią fajną rzeczą, jaką robią podpisy Schnorra, jest drastyczne uproszczenie implementacji podpisów adapterów. Pomyśl o podpisie adaptera, który jest „szyfrowany” wartością dodaną lub odjętą od prawidłowego podpisu. Nie jest ważny, dopóki nie odwrócisz tej operacji matematycznej lub „odszyfrujesz ją” za pomocą „klucza”, którym został użyty do manipulacji. Jest to możliwe w przypadku ECDSA, ale ze względu na nieliniowość matematyki w porównaniu do Schnorra, jest to stosunkowo skomplikowane i istnieje wiele problemów związanych z bezpieczeństwem, które należy wziąć pod uwagę podczas jego wdrażania.

Jednak ze względu na liniowe właściwości Schnorra sygnatura adaptera jest tak prosta, jak wzięcie pojedynczej (powiedzmy liczby 9,300,030 30 XNUMX) i odjęcie od niej wartości (powiedzmy XNUMX). Gdy strona posiadająca podpis adaptera pozna odjętą wartość, może po prostu dodać ją z powrotem i voila, mają ponownie ważny podpis.

Implikacje korzeni palowych

Jak omówiono nieco powyżej, Taproot w rzeczywistości jest po prostu MASTem, z tą różnicą, że zamiast działać jak P2SH (gdzie mieszasz skrypt lub w przypadku MAST-a, korzeń Merkle na górze drzewa skryptów), „poprawiasz” Klucz publiczny Schnorr w katalogu głównym drzewa Merkle.

Podkręcanie działa dzięki liniowym właściwościom Schnorra — kiedy „podkręcasz” klucz publiczny za pomocą rdzenia Merkle (dodajesz ten korzeń Merkle do klucza publicznego), możesz po prostu dodać korzeń Merkle do oryginalnego klucza prywatnego i wygenerować klucz wydatkowy dla nowy, ulepszony klucz publiczny. Oznacza to, że dodajesz to samo do klucza publicznego i prywatnego i nadal stanowią one prawidłową parę kluczy. Ukrywa to istnienie drzewa MAST, chyba że zostanie użyta jego gałąź, ale zasadniczo jest to nadal tylko drzewo MAST, tylko takie, które jest zaangażowane w bardziej wydajny i prywatny sposób.

Możliwość zaangażowania się w różne skrypty wydatków w drzewie Merkle i ujawnienia tylko użytego skryptu to ogromna korzyść w zakresie skalowalności pod względem złożoności inteligentnych kontraktów, którą można zbudować na Bitcoinie.

Podobnie jak rozmiar bloku ogranicza liczbę transakcji w bloku, istnieje ograniczenie rozmiaru transakcji wynoszące 100 kilobajtów. Jedyna różnica polega na tym, że zamiast być zasadą konsensusu, jest to reguła polityczna. Oznacza to, że górnik może wydobyć transakcję większą niż 100 kilobajtów, ale domyślnie żaden węzeł w sieci nie przekaże górnikowi transakcji większej niż ta.

To z natury ogranicza rozmiar skryptu używanego do blokowania Bitcoin UTXO. Nawet w przypadku P2SH, gdzie UTXO jest zablokowane na podstawie skrótu skryptu, który nie jest ujawniany, dopóki go nie wydasz, w końcu i tak będziesz musiał ujawnić pełny skrypt w odpowiednim czasie. Taproot zwiększa ten limit skalowalności skryptu, nie wymagając od użytkownika ujawniania całego skryptu podczas jego używania. Zamiast ograniczać całkowity rozmiar wszystkich sposobów wydawania UTXO do limitu wielkości transakcji, musisz jedynie upewnić się, że każdy pojedynczy sposób wydawania UTXO Taproot przestrzega tego ograniczenia.

Taproot oferuje również wiele korzyści związanych z prywatnością. Jedną z największych zalet drzewa MAST jest możliwość tworzenia wszelkiego rodzaju sytuacji warunkowych, w których monety mogą zostać wydane przez inne strony.

Wyobraź sobie takie rzeczy, jak programy spadkowe, w ramach których po około roku Twoje dzieci mogą wydać Twoje monety, lub w przypadku odmowy podpisania, Twoja żona i prawnik mają potencjalną drogę do odzyskania monet. Nic na temat tych warunków wydatkowania nie jest podawane do wiadomości publicznej, chyba że są one faktycznie stosowane. Ten dwojaki proces zapewnia innym stronom zaangażowanym w różne gałęzie wydatków, które konstruujesz, wiarygodne zaprzeczenie ich zaangażowania w ten UTXO, a także chroni je przed złodziejem lub napastnikiem, który celuje w nie z wyprzedzeniem, wiedząc, że mają pewien stopień kontroli nad swoimi UTXO celu.

Na poziomie technicznym Taproot został również stosunkowo dobrze zaprojektowany. Każdy, kto czyta, kto jest zaznajomiony z Segregated Witness na jakimkolwiek poziomie, powinien znać wersję świadka.

Po wdrożeniu Segregated Witness utworzono nową sekcję „świadka” transakcji, do której przeniesiono dane podpisu. Dane świadka miały flagę wersji, dzięki czemu można było je zaktualizować do nowej funkcjonalności bez konieczności wykorzystywania niezdefiniowanych OP_CODE w warstwie bazowej dla nowych funkcji.

W ten sposób zaimplementowano Taproot/Schnorr. Transakcje Segregated Witness korzystają z wersji zerowej świadka. Kiedy Taproot/Schnorr wkrótce zostanie uruchomiony, użyją nowej wersji świadka, aby odróżnić je od starszych transakcji Segregated Witness. W ten sam sposób, w jaki SegWit wprowadził wersje świadka, Taproot wprowadza „wersję tapleaf” dla skryptów używanych w drzewach MAST dla UTXO używających Taproot. Pozwala to nie tylko na aktualizację skryptów ukrytych w MAST bez użycia nowych OP_CODE w warstwie bazowej, ale także bez konieczności aktualizacji wersji monitora! Dlatego Taproot został zaprojektowany tak, aby jego aktualizacja w przyszłości była możliwie najefektywniejsza, bez ograniczania innych niepowiązanych aktualizacji protokołu.

Taproot przyniesie wiele różnych przypadków użycia. Na początek wszystkie klauzule uniemożliwiające współpracę w kanale Lightning, takie jak klucze kar lub blokady czasowe umożliwiające ich użycie, można zakopać pod MASZTEM za pomocą Taproot. Nikt nigdy nie będzie wiedział, że istnieją, chyba że trzeba ich użyć, co jeszcze bardziej zaciemnia, które UTXO są w rzeczywistości kanałami Lightning, czy nie.

Schematy dziedziczenia to kolejny przypadek użycia. Wyobraź sobie drzewo Taproot skonstruowane w taki sposób, że po sześciu miesiącach braku transferu pieniędzy cała twoja rodzina będzie mogła się zebrać i wydać UTXO, jak chce. Następnie, sześć miesięcy później, każdy oprócz jednej osoby będzie mógł je wydać (więc wyobraź sobie, że masz żonę, dwójkę dzieci i rodziców jako posiadaczy kluczy, a potem wyobraź sobie, że po dodatkowych sześciu miesiącach twoja żona, jedno dziecko i rodzice mogą podpisać lub dwójka dzieci i rodzice mogą podpisać umowę bez żony itd.).

Następnie, sześć miesięcy później, wszyscy oprócz dwóch osób będą mogli je wydać. Ostatecznie może się to sprowadzić do tego, że tylko jedna osoba z pomocą prawnika (aby mieć pewność, że nie doszło do żadnych szaleństw) będzie w stanie wydać UTXO.

A co, jeśli używasz multisig do zabezpieczenia swojej chłodni, ale masz tylko jedno miejsce, które uważasz za bezpieczne i przewidywalne w dłuższej perspektywie? Można utworzyć MAST, w którym ostatecznie, po kilku latach, klucz znajdujący się w bezpiecznym miejscu będzie mógł wydać te monety samodzielnie, na wypadek zgubienia lub zniszczenia innych kluczy, ale bez narażania monet na bezpośrednie ryzyko kradzieży, jeśli to nastąpi jeden klucz został naruszony.

Jest to niesamowita i wszechstronna aktualizacja Bitcoina, nad którą prawdopodobnie pracowano niemal od narodzin samego Bitcoina, a nie tylko przez ostatnie kilka lat, podczas których opracowano i wdrożono faktyczne szczegóły implementacji.

To naprawdę zwycięstwo pod tak wieloma względami, jeśli chodzi o skalowalność i użyteczność protokołu Bitcoin, że trudno to przekazać ze względu na subtelność i „nieseksowność” niektórych z nich. Ale to nie umniejsza zwycięstwa. Zatem zapnijcie wszyscy pasy i przygotujcie się do zabawy nowymi zabawkami, z których wkrótce będziemy musieli skorzystać, bo nadchodzi Taproot!

To jest gościnny post Shinobi. Wyrażone opinie są całkowicie ich własnymi i niekoniecznie odzwierciedlają opinie BTC Inc lub Magazyn Bitcoin.

Źródło: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer