Dyskutowane od dłuższego czasu zagadnienie Taproot dla Bitcoina nareszcie jest na tapecie deweloperów w sposób pełny. Opublikowane niedawno propozycje rzucają nowe światło na długo oczekiwane zmiany i ulepszenia w funkcjonowaniu sieci Bitcoin.
Wydajność i prywatność raz jeszcze
Bitcoin zmaga się z problemem prywatności i wydajności łańcucha bloków od wielu lat. Chociaż problem był już wiele razy opisywany w przeszłości warto wrócić na chwilę do tego zagadnienia, stanowi to bowiem konieczną uwerturę do tematu poruszanego w dzisiejszym artykule. Szczęśliwie, jak doskonale wiecie, język, w którym napisany jest kod Bitcoina pozwala bez przeszkód rozszerzać jego funkcje i implementować nowe rozwiązania. W zakresie tych możliwości leży oczywiście definiowanie sposobu kodowania wyjść dla bitcoinowych transakcji.
Cały kod musiał zostać zdefiniowany w taki sposób, aby transakcje pozostały prywatne, a także na tyle “lekkie”, aby spełnić wymagania dotyczące danych. Dochodzi do tego wyzwanie optymalnego wykorzystania przepustowości, aby nie obciążać zbytnio przestrzeni węzłów Bitcoin i rozszerzyć możliwości obliczeniowe Problem polega na tym, aby móc dopisać funkcje odnoszące się do prywatności w taki sposób, aby nie wprowadzało to żadnych niedogodności do blockchaina Bitcoina.
Nie wszystkie propozycje udoskonalenia kodu Bitcoina w zakresie prywatności są łatwe i szybkie do zaimplementowania. Spójrzmy chociażby o implementacji podpisów Schnorra i związanych z ty zagadnień, o których pisałem już tutaj. Przykładem rozwiązania, które reprezentuje bardziej skomplikowana strukturę w ramach blockchain Bitcoina są również smart kontrakty.
Subtelna ilość kodu
Innymi słowy, ilość kodu, który musiałby zostać dodany do bloku z każdą transakcją, znacznie wzrośnie. Spowolniłoby to sieć, ponieważ przy każdej nowej transakcji przetwarzanych byłoby więcej danych. Ponadto, więcej danych wymaga więcej miejsca na dysku, co spowodowałoby, że łańcuch bloków stałby się jeszcze bardziej napięty.
Taka sytuacja mogłaby przyblokować pełne węzły blockchain, które mają za zadanie sprawdzanie poprawności transakcji sieciowych, ponieważ potrzebowałyby silniejszych procesorów i znacznie większej ilości danych do przechowywania, aby poradzić sobie z już znaczącymi wymaganiami blockchaina Bitcoin.
Dlatego efektywne i anonimowe zachowanie miejsca jest tak ważne dla programistów Bitcoin. Rozwiązania, które by to umożliwiają, zostały już zaproponowane, a nawet rozpoczęły się fazy ich wdrożenia, przy czym takie technologie, jak CoinJoin lub Dandelion ++ są wymieniane najczęściej. Ostatnio w rozmowach programistów i kryptografów prym wiedzie Taproot. Czym jest Taproot i w jaki sposób może pomoc rozwiązać bieżące problemy Bitcoina?
Aperitif
Rozwiązanie Taproot zostało pierwotnie wprowadzone przez Grega Maxwella, programistę i kryptografa Bitcoin Core, który chciał stworzyć coś, co zachowałoby zestawy anonimowości w łańcuchu dla określonych fragmentów inteligentnych umów między użytkownikami (dzięki czemu wyglądają jak zwykłe płatności).
Oznacza to, że Taproot zasadniczo rozszerza możliwości inteligentnego kontraktu w sieci Bitcoin (zachowując prywatność), powodując, że wszystkie transakcje w łańcuchu (zarówno proste, jak i bardziej zaawansowane) wyglądają dokładnie tak samo dla zewnętrznego obserwatora.
Rozwiązanie Taproot jest powiązane z trzema technologiami, które zostały zaimplementowane lub są aktualnie wdrażane w Bitcoin. Są to P2SH, MAST i SCHNOOR. Rzućmy pokrótce okiem na każdą z nich.
P2SH
Zwany również „pay to script hash” jest podstawową technologią, która obecnie bierze udział w „zasilaniu” transakcji w sieci. Wprowadzony z BIP 16, P2SH blokuje Bitcoiny za skryptem, który wymaga spełnienia określonych warunków, zanim zostaną one udostępnione.
W przypadku standardowych transakcji oznacza to, że klucz prywatny zostanie użyty do sprawdzenia, czy monety mogą zostać wydane. W przypadku zaawansowanych transakcji może to oznaczać, że więcej kluczy prywatnych będzie musiało zostać zaprezentowanych, zanim skrypt wyda Bitcoiny. Warunki nie muszą być tylko kluczami prywatnymi; alternatywnie można użyć hasła, blokady czasu lub innego unikalnego wymagania (lub więcej z tych warunków w tym samym czasie).
Skrypt P2SH (zawierający warunki „uwolnienia” BTC) jest przechowywany jako skrót w blockchain. Aby wydać Bitcoiny wysyłane przez P2SH, odbiorca musi dostarczyć skrypt pasujący do skrótu skryptu i danych, które sprawiają, że skrypt ocenia się jako prawdziwy. Po wydaniu monet warunki te są ujawniane sieci.
Problem polega na tym, że gdy warunki zostaną ujawnione, światło dzienne oglądają dosłownie wszystkie z nich. Jeśli ustawisz warunek ochrony multisig i masz jedno hasło w swoim P2SH, oba zostaną ujawnione po wydaniu monet. Stanowi to problem, ponieważ zewnętrzni obserwatorzy mogą wywnioskować, z jakiego rodzaju portfela Bitcoin został wysłany.
Niektóre portfele nie oferują zaawansowanych funkcji, takich jak blokady czasu lub multisig, które zawężają pulę portfeli do odgadnięcia. Dodatkowo z większą ilością warunków przychodzi więcej kodu, a już wspominałem na początku, dlaczego jest to złe dla sieci.
MAST
MAST lub Merkelized Abstract Syntax Trees został zaproponowany na początku 2016 roku przez Johnsona Lau i jest technologią, która zmniejsza rozmiar danych niezbędnych do napisania skryptu Bitcoin. Zmniejsza to zapotrzebowanie na przestrzeń blokową i poprawia prywatność, ponieważ tylko niewielką część inteligentnego kontraktu ujawnia się w publicznej sieci, skutkiem czego trudniej go analizować. Dzięki MAST skomplikowane warunki, o których wspominaliśmy, nagle stają się realną opcją dla łańcucha bloków Bitcoin.
MAST przesłania warunki skryptu transakcji i ujawnia tylko pierwszy spełniony warunek – ten, który był odpowiedzialny za wydawanie monet. Czyni to poprzez mieszanie każdego indywidualnego warunku poprzez wdrożenie technologii Merkle Tree. Jeśli, na przykład, P2SH zawierał blokadę czasu i wymaganie multisig, a transakcja została podpisana tym ostatnim, nikt nie będzie wiedział, że ta pierwsza była nawet częścią początkowego skryptu.
Sygnatury Schnorra
Do tego wszystkiego dochodzi technologia Schnorra. Podpisy Schnorra to ulepszenie obecnego schematu podpisu Bitcoin, które pozwala na przeprowadzenie pojedynczej transakcji szyfrowania wielu kluczy w jednym (zasadniczo obejmując kilka transakcji w jednym).
Technologia Schnorr jest rozwijana od lat i oczekuje się, że będzie kolejnym ważnym dodatkiem do bazy kodu Bitcoin. Wszystko wskazuje na to, ze Schnorr znacznie poprawi rozmiary danych transakcji i sieć stanie się znacznie bardziej skalowalna niż wcześniej.
Agregacja podpisów, główna cecha tej technologii, może być stosowana w transakcjach multisig. Klucze publiczne i podpisy można łączyć, dzięki czemu pojedyncza transakcja wielosygnaturowa łączy się z tymi bezwarunkowymi. Schemat ma charakter liniowy, co oznacza, że można wykonać wiele podpisów za pomocą różnych kluczy w tej samej wiadomości, dodać je razem i utworzyć prawidłowy podpis dla sumy tych kluczy.
Dodatkowo, technologia podpisów SCHNORRA pozwala „podkręcać” klucze publiczne i prywatne, co może również pomóc w sprawieniu, aby transakcje wielosygnaturowe wyglądały „normalnie”. Schemat sygnatur Schnorra był zawsze lepszy od tego, co miał Bitcoin, ale został opatentowany do 2008 r., Co uniemożliwiło twórcom Bitcoinów wdrożenie go na dużą skalę. Więcej na temat podpisów Shnorra możecie przeczytać tutaj.
Co to jest Taproot?
Wszystkie technologie, o których wspomnieliśmy powyżej otwierają potencjalnie drzwi do wdrożenia Taproot. Jest to koncepcja podobna do MAST; Skrypty MAST zawsze wymagają wstawienia warunku do skrótu, który pozwala uczestnikom zgodzić się na podpisanie transakcji razem. Taproot to w dużej mierze nowa metodologia tworzenia adresów.
Jeśli dwóch członków wielostronnej transakcji wie, że środki staną się dostępne dla jednego z nich w ciągu kilku tygodni, mogą zgodzić się na natychmiastowe podpisanie transakcji. Ta funkcja jest zawsze zawarta w Taproot i nazywana jest cooperative close, co poprawia bezpieczeństwo i uczciwość inteligentnych umów Bitcoin.
Wprowadzenie podpisów Schnorra do równania pozwala wprowadzić elementy prywatności. Schnorr umożliwia użytkownikom tworzenie progowych kluczy publicznych i sygnatur; jeśli odpowiedni próg podpisu zostanie podany do pewnego progu klucza publicznego, środki zostaną zwolnione do wydania. Schnorr pozwala nam także łączyć niezwiązane ze sobą wyniki w skrypt, który może być użyty do zmiany progu klucza publicznego i stworzenia unikalnego skrótu.
Ten skrypt służy do zmiany sygnatury progowej; wartość progowa podpisu + skrót skryptu ostatecznie pozwoli osobom zaangażowanym na wydawanie Bitcoin. Dopóki wszyscy uczestnicy zgadzają się na „kooperatywne zamknięcie” kontraktu, połączenie Schnorr i MAST zapewnia zarówno wydajność danych, jak i prywatność.
Deweloper Bitcoin Core, Anthony Towns, zaproponował w lipcu 2018 r. Wprowadzenie „uogólnionego systemu taproot”, co zmniejszyłoby ilość danych wymaganych dla początkowej propozycji Taproot. Złożone kontrakty Taproot nadal byłyby ciężarem danych, a rozwiązanie o nazwie „Graftroot” zostało opracowane w celu rozwiązania tego problemu.
Graftroot pozwoliłby inteligentnym umowom być tak złożonymi, jak chcą ich twórcy, potencjalnie zawierającymi setki skryptów i warunków. Towns zauważa, że „nie ma dużego ciśnienia na implementowanie uogólnionej wersji taproot”, co oznacza, że Core początkowo zaimplementuje Schnorr / Taproot / MAST, a następnie zajmie się wprowadzeniem Graftroota.
Złożone smart kontrakty, które chronią i warunkują wydatki na Bitcoin, można ukryć dzięki funkcjom MAST, P2SH i Schnorr podobnym do Taproot. Stanowi to znaczący plus dla prywatności użytkowników Bitcoinów i jest to coś, czego wielu zwolenników Core oczekuje z wypiekami na twarzy.
Pieter Wuille, deweloper Bitcoin Core i współzałożyciel Blockstream, niedawno opowiedzieli o nadchodzących ulepszeniach Taproot i Schnorr, wyjaśniając, w jaki sposób te ulepszenia mogą przynieść korzyści sieci Bitcoin. Obejrzyjcie poniższą prezentację, jeśli chcecie dowiedzieć się więcej o technologicznych szczegółach nadchodzących funkcji:
Jak to ma działać?
Obecnie portfele posługujące się pojedynczymi podpisami (single signature) P2WPKH generują klucz prywatny, uzyskują z niego klucz publiczny (pubkey) i mieszają go, aby utworzyć program świadka dla adresu bech32.
W przypadku Taproot krok mieszania zostanie pominięty, więc adres bech32 będzie zawierał klucz pubkey bezpośrednio, z jedną małą zmianą. Obecnie 33-bajtowe klucze publiczne w Bitcoin są kodowane rozpoczynając się od 0x02 lub 0x03, aby umożliwić walidatorom rekonstrukcję współrzędnej Y klucza na krzywej eliptycznej secp256k1; w bip-taproot wartość tego bajtu jest zmniejszana o dwa, tak że 0x02 staje się 0x00, a 0x03 staje się 0x01. Znaczenie pozostaje takie samo, ale użycie dolnego bitu dla wartości uwalnia pozostałe bity dla przyszłych miękkich widelców. Zmieniono także wersję świadka z 0 użytego dla P2WPKH / P2WSH na 1.
Wydawanie z P2PKH lub P2WPKH wymaga, aby wydatkujący zawarł swój klucz publiczny w swoich danych wejściowych. W przypadku Taproot klucz publiczny został dostarczony podczas wydawania UTXO, więc kilka bajtów jest zapisywanych, nie włączając go ponownie. Wydatki muszą również zawierać podpis; jest to podpis w stylu Schnorra zdefiniowany przez bip-schnorr z dołączonym opcjonalnym bajtem sighash.
Ogólnie rzecz biorąc, powoduje to, że koszt stworzenia i wydania pojedynczego wyjścia Taproot jest o około 5% droższy niż P2WPKH. Prawdopodobnie nie jest to znaczące: koszt utworzenia wyniku Taproot jest prawie taki sam, jak w przypadku tworzenia wyjścia P2WSH – które ludzie płacą cały czas bez problemu – a koszt wydania pojedynczego klucza Taproot jest o 40% tańszy niż P2WPKH.
Oprócz zmiany z ECDSA na Schnorr dla algorytmu podpisu, istnieje kilka ważnych (ale łatwych do zaimplementowania) zmian w skrócie transakcji – podpis, który zobowiązuje się udowodnić, że transakcja jest autoryzowanym wydaniem UTXO.
Przede wszystkim użyty hash przechodzi od podwójnego SHA256 protokołu tradycyjnego (SHA256d) do pojedynczej operacji SHA256. Uważa się, że dodatkowe wcześniej używane skróty nie zapewniły żadnego znaczącego bezpieczeństwa. Dodatkowo zmieszane dane są poprzedzone wartością specyficzną dla tego użycia funkcji mieszającej; pomaga to zapobiegać problemom takim jak CVE-2012-2459, w których skrót z jednego kontekstu może być użyty w innym kontekście. Tag prefiksu to SHA256 (tag) || SHA256 (tag), gdzie znacznikiem w tym przypadku jest łańcuch UTF-8 „TapSighash” i || oznacza konkatenację. Oprogramowanie, które musi tworzyć lub weryfikować dużą liczbę sygnatur (takich jak aktywne węzły LN lub pełne węzły Bitcoin), może korzystać z wersji ich funkcji SHA256, która została wstępnie zainicjowana tagiem przedrostkowym, więc nie musi powtarzać tych operacji za każdą weryfikacją podpisu. Implementacje, które nie wymagają maksymalnej wydajności (takie jak zwykłe portfele), mogą po prostu zaimplementować algorytm zgodnie z opisem przy użyciu domyślnej funkcji biblioteki SHA256.
Istnieją również pewne zmiany w tym, które dane są zawarte w ramach haszy i jak są serializowane. Obejmuje to ulepszenia, które mogą sprawić, że portfele bez dostępu do zweryfikowanych wpisów UTXO (np. Portfele sprzętowe i HSM) będą bardziej wydajne, ponieważ nie muszą pobierać tylu danych, aby upewnić się, że podpisują poprawne UTXO i kwoty.
Chociaż może to brzmieć jak znaczna liczba zmian, deweloperzy Bitcoina podejrzewają, że jest to dopiero uwertura do właściwych zmian.
Taproot i transakcje wielosygnaturowe
Po UTXO o pojedynczym podpisie, najbardziej powszechne są proste multisig UTXO. Są to dane wyjściowe, które zależą od pewnej liczby podpisów z poszczególnych kluczy publicznych, ale nie mają żadnych innych warunków. Są one wykorzystywane zarówno przez indywidualnych użytkowników (np. Wymaga wielu urządzeń do wspólnej pracy w transakcjach wychodzacych), jak i przez wiele stron do pojedynczej transakcji (np. Escrow).
Istnieją dwa sposoby wykonywania prostych wielozakresowych wydatków za pomocą Taproot, z których najbardziej efektywny jest agregacja kluczy i podpisów.
W celu agregacji tworzone są dwa lub więcej kluczy prywatnych, a ich klucze publiczne są uzyskiwane. Klucze publiczne są następnie łączone w jeden klucz publiczny, którego nie można odróżnić od żadnego innego klucza publicznego Bitcoin. Jest to używane jako program świadka segwit. Później właściciel lub właściciele niektórych lub wszystkich kluczy prywatnych tworzą sygnatury, które są połączone w jedną sygnaturę, która jest również nie do odróżnienia od innych podpisów schnorr.
Być może zauważyłeś, że poprzedni akapit jest niejasny co do dokładnego mechanizmu wykorzystywanego do agregowania kluczy i podpisów. Powodem tego jest to, że istnieje wiele znanych metod i każda z nich może zostać użyta przez uczestników. Deweloperzy mogą nawet znaleźć nowe metody i wdrożyć je w portfelach Bitcoin bez żadnych konsensusowych zmian. Dzieje się tak, ponieważ algorytm podpisu szuka tylko jednego klucza publicznego i pojedynczego podpisu, które są poprawne na zasadach opisanych powyżej. Ze wszystkich znanych metod protokół MuSig jest prawdopodobnie najlepiej zbadanym protokołem agregacji w kontekście Bitcoin.
CoinJoin i Tap Root l Agregacja Cross-Input
Agregacja kluczy jest niezwykle użyteczną funkcją dla multisigs, które wydają jedno wejście. Ponieważ transakcje Bitcoin zwykle mają więcej niż jedno wejście, przyszłe iteracje Schnorra mogą być również wykorzystane do utworzenia interaktywnego schematu podpisu agregującego (IAS), w którym wszystkie dane wejściowe w transakcji są wydawane jednocześnie z pojedynczą sygnaturą.
Ponownie interakcje między sygnatariuszami odbywają się całkowicie poza łańcuchem, ale teraz pojedyncza sygnatura może zostać wykorzystana do wydania wszystkich danych wejściowych transakcji. Każde wejście nadal będzie miało swój własny klucz publiczny, ale może zostać wydane przez IAS Schnorra:
Greg Maxwell, Pieter Wuille, Anthony Towns i inni pracują nad ewolucją programu inteligentnych kontraktów Taproot, aby ułatwić tę funkcjonalność. Nazywają ten schemat Uogólnionym Taproot lub G’root i mogą znacznie ułatwić przejście z agregacji klucza do agregacji między wejściami.
Podobnie jak agregacja kluczy, agregacja międzykanałowa dodatkowo zwiększa wydajność transakcji Bitcoin. Ale, co najważniejsze, może umożliwić silne mechanizmy ochrony prywatności w warstwie bazowej Bitcoin.
CoinJoin
Jednym z najbardziej ekscytujących aspektów agregacji między wejściami jest sposób, w jaki można poprawić transakcje CoinJoin na Bitcoin. Dla kontekstu, CoinJoin jest techniką chroniącą prywatność, w której wielu nadawców i odbiorców jest połączonych w ramach jednej transakcji. Celem jest utrudnienie obserwatorowi blockchain łączenia konkretnych nadawców i odbiorców, umożliwiając w ten sposób podmiotom w CoinJoin twierdzenie o wiarygodnej zaprzeczalności.
Ta technika została pierwotnie zaproponowana przez Grega Maxwella na BitcoinTalk w 2013 r. I od tego czasu oferowana jest przez różne usługi, w tym JoinMarket, SharedCoin, ShufflePuff, DarkWallet i CoinShuffle. Wariacje CoinJoin, takie jak schemat Chaumian CoinJoin stosowany w Portfelu Wasabi, znacznie poprawiły oryginalny model. Jednakże, ponieważ anonimowość kocha firmę, nadal polega ona na wystarczająco dużej liczbie użytkowników, aby także zaciemnić swoje salda.
Kolejną kwestią związaną z CoinJoin jest identyfikowalność (i potencjalna cenzura) całego typu transakcji. Rozważmy, że najczęściej używaną heurystyką w dzisiejszej analizie blockchain jest podążanie za określonymi wejściami w celu określenia, czy dwa lub więcej adresów należy do tej samej jednostki. Jeśli na przykład Alice wysłała Bobowi 1.982723 BTC, obserwator bloków może śledzić miejsca dziesiętne tego konkretnego wejścia, aby odwzorować wykres transakcji lub historyczne podziały i zmiany własności UTXO.
Aby temu zapobiec, implementacje CoinJoin wymagają wspólnych nominałów wartości, dzięki czemu każdy w CoinJoin wysyła tę samą kwotę. Na przykład użytkownicy portfela Wasabi wysyłają takie same nominały 0,1 BTC w transakcjach CoinJoin na 100 uczestników. Chociaż nadal trudno jest wskazać połączenie między konkretnymi nadawcami i odbiorcami, obserwator blockchain może szukać wspólnych nazw, aby zidentyfikować, że miało miejsce CoinJoin i doradzić swojemu klientowi, by cenzurował wszystkie zaangażowane podmioty.
Pomoże w tym agregacja między wejściami, ponieważ wprowadza dodatkowy mechanizm zaciemniania na poziomie protokołu. Zasadniczo agregacja między wejściami może umożliwić budowę opartych na Schnorr transakcji CoinJoin z osobami podpisującymi, które wyglądają jak zwykłe transakcje z jednym podpisem dla osób z zewnątrz. Może to również umożliwić łatwiejszą implementację CoinJoin w popularnych portfelach bez uciążliwej inżynierii, co może zwiększyć ogólny zestaw anonimowości sieci lub liczbę użytkowników korzystających z tej techniki.
Kwestię wspólnego denominacji można jeszcze rozwiązać za pomocą dodatkowych technik, takich jak Pay-to-EndPoint (P2EP), która łączy wczesną pracę Satoshiego nad prywatnością (patrz P2IP) z CoinJoin, dzięki czemu zarówno nadawcy, jak i odbiorcy wnoszą wkład do transakcji. Ta nowatorska technika zasługuje na samodzielny post, ale możesz przeczytać więcej na ten temat tutaj, tutaj i tutaj.
P2EP jest kompatybilny wstecz, a gdy jest używany w połączeniu ze Schnorrem, może zapewnić wystarczającą prywatność w warstwie bazowej Bitcoin.
Kluczowe aktualizacje Bitcoin w perspektywie średnioterminowej
Omówione aktualizacje są uważana za tak głęboką i wpływową dla Bitcoin, ponieważ wskazuje na umiejscowienie ram rozwoju Bitcoin w nadchodzących latach.
Zwiększony poziom prywatności uzyskany dzięki implementacji podpisów Schnorra i jego zdolność do adaptacji do transakcji wielosygnaturowych zapewniają Bitcoinowi większą prywatność i funkcjonalność.
Bitcoin jednak zawsze był powszechnie oskarżany o luki w zakresie prywatności. Społeczność dyskutuje o tym problemie raz po raz. Bitcoin nie jest w stanie ukryć wszystkich elementów transakcji tak po prostu jak robią to anonimowe monety Monero i Dash. Zakładając, że Bitcoin zyskuje całkowitą anonimowość (jak Z-Cash), jest to coś zbyt radykalnego i absolutnie wykluczonego. Możemy jednak oczekiwać, że Bitcoin w jakiś sposób zwiększy swoją prywatność na poziomie transakcji i sprawi, że informacje o transakcji będą mniej widoczne i nie będą łatwe do śledzenia. To w kontekście Bitcoina w zupełności wystarczy.
Należy też wspomnieć, że nowy podpis Schnorra nie zastąpi w pełni ECDSA, który działa od lat, a jego niezawodność jest całkowicie sprawdzona na rynku; jednak otwiera nowe okno, alternatywny schemat dla użytkowników. W przypadku Bitcoin jest to tożsame ze wstrzyknięciem świeżej krwi. Wszystkie zaproponowane i wprowadzone zmiany prawdopodobnie przełożą się na uaktywnienie przekonań społeczności i rynku dla scenariuszy mówiących o rozszerzonych zastosowaniach Bitcoina.
Jeżeli podobał ci się ten post i chcesz więcej zapraszamy do śledzenia naszego konta steemit jak i strony http://bithub.pl/
Bardzo interesujący artykuł. Ciekawe jak długo zajmie implementacja tego wszystkiego.
Dzięki! :)