Jeśli myślisz, że po wprowadzeniu Taproot deweloperzy Bitcoina osiedli na laurach, jesteś w dużym błędzie. Zobacz, nad jakimi zmianami w protokole króla kryptowalut pracują aktualnie i z jakimi zmianami możemy mieć do czynienia w najbliższej przyszłości.
Nad Czym Pracują Aktualnie Deweloperzy Bitcoina?
Po czterech latach bez większych fajerwerków, protokół Bitcoina przeszedł niedawno ważną aktualizację w postaci Taproot. To kluczowa zmiana reguł gry dla przyszłości łańcucha bloków kryptowaluty. Ustanowiła podwaliny pod przyszłe innowacje, które zostaną opracowane na szczycie systemu w nadchodzących latach.
Ostatnim dużym soft forkiem przed Taproot był Segregated Witness. Soft forki nie są zatem w protokole Bitcoina zbyt częste. Bitcoin musi ewoluować bezpiecznie, aby zapewnić, że z powodu niepotrzebnego pośpiechu, do jego systemu nie wkradną się żadne błędy. Stawką są miliardy dolarów, a co ważniejsze, los bitcoinowej rewolucji. Jakikolwiek poważny błąd byłby poważnym ciosem w zaufanie milionów użytkowników, którzy mają nadzieję na lepszą przyszłość z BTC.
Fakt wprowadzenia założeń Taproot nie oznacza to bynajmniej, że deweloperzy Bitcoina nie pracowali w tym czasie i nie pracują aktualnie nad niczym innym. Wręcz przeciwnie. Na tapecie znajduje się cała gama tematów, które – w nadchodzących miesiącach i latach – mogą prowadzić do potencjalnych nowych soft forków. Zagadnienia te zgrupowane są w ramach tak zwanych „propozycji ulepszeń”, znanych w społeczności deweloperskiej pod hasłem BIP.
Oto jedne z najważniejszych, które mogą doświadczyć integracji z protokołem Bitcoin w pierwszej kolejności.
BIP 118: SIGHASH_NOINPUT
W manifeście Lightning Network Joseph Poon zalecał użycie SIGHASH_NOINPUT, aby móc stworzyć pierwszą transakcję zobowiązania, która odwołuje się do identyfikatora transakcji bez konieczności faktycznego jej podpisywania.
Protokoły poza łańcuchowe wykorzystują transakcje, które nie są jeszcze transmitowane do sieci Bitcoin w celu renegocjacji stanu końcowego, który powinien zostać rozliczony on-chain. W wielu przypadkach pożąda jest reakcja na daną transakcję obserwowaną w łańcuchu z góry ustaloną reakcją w postaci innej transakcji. Często reakcja ta jest identyczna, bez względu na to, która transakcja jest widoczna w łańcuchu, ale aplikacja nadal musi utworzyć wiele identycznych transakcji. Dzieje się tak, ponieważ podpisy w wejściu transakcji jednoznacznie łączą się z hashem transakcji, która utworzyła wydane wyjście.
BIP 118 opisuje nową flagę skrótu podpisu (sighash-flag) dla transakcji segwit. Usuwa wszelkie zobowiązania do wykorzystania danych wyjściowych z mechanizmu weryfikacji podpisów. Umożliwia to dynamiczne wiązanie transakcji z danymi wyjściowymi, oparte wyłącznie na zgodności skryptów wyjściowych ze skryptami wejściowymi.
Warto zaznaczyć, że założenia, o których mowa, zostały spisane jeszcze przed wdrożeniem Segregated Witness (SegWit). Obecnie sieć Lightning Network działa zatem bez SIGHASH_NOINPUT jako nowej sygnatury flagi skrótu.
Jednak od tego czasu Christian Decker zaproponował budowę kanału płatności eltoo, który miałby stać się niczym innym, jak relatywnie prostą implementacją warstwy drugiej na Bitcoinie. Taki kanał miałby zastąpić obecnie stosowaną konstrukcję opartą na karach, a tym samym znacznie zmniejszyć koszty utrzymania stanu kanału, ponieważ stan ten stałby się symetryczny dla wszystkich uczestników sieci.
Eltoo zależne jest od implementacji SIGHASH_NOINPUT, ponieważ stan kanału jest zakodowany jako połączona lista transakcji aktualizacji, które w przypadku naruszenia protokołu są pomijane (od punktu naruszenia do bieżącego stanu kanału).
Programiści Lightning Network zgadzają się, że kanały Lightning skorzystałyby na zbudowaniu ich za pośrednictwem eltoo. Aby tak się stało, założenia BIP 118 będą musiały zostać zaimplementowane. Podobnie jak w przypadku Taproot, najbardziej oczekiwany nie jest sam fakt wdrożenia tego rozwiązania lecz to, jakie możliwości otworzy ono na przyszłość.
BIP 119: OP_CHECKTEMPLATEVERIFY
BIP 119 ma na celu wprowadzenie nowego opcode’u, który będzie używany głównie do kontroli przeciążenia transakcji i tworzenia instancji kanału płatności. Kod OP_CHECKTEMPLATEVERIFY jest jednym z technicznych podejść branych pod uwagę przy implementacji „przymierzy” (covenant).
Przymierza to ustalenia w zakresie ograniczeń dotyczących sposobów wydawania cyfrowych monet poza samym wykorzystaniem klucza prywatnego. Takie konstrukcje mogą być przydatne do konstruowania smart kontraktów. Mogą być również wykorzystywane do dalszego zwiększenia skalowalności sieci Lightning w przyszłości.
Złożone we wdrażaniu i związane z ryzykiem wprowadzenia dyskryminującej zamienności, przymierza pozostają na razie na etapie projektu i nie były jak dotąd rozważane pod kątem szybkiego włączenia do protokołu Bitcoin.
Drivechain
Jeśli interesuje Cię świat kryptowalut, prawdopodobnie słyszałeś już o koncepcji „łańcuchów bocznych” (sidechain). Jest to funkcja, która jako usprawnienie Bitcoina była proponowana już od dawna. Drivechainy to dodatkowe łańcuchy bloków, które można powiązać z Bitcoinem. Niektóre z tych łańcuchów można by wykorzystać do testowania nowych, póki co eksperymentalnych rozwiązań i technologii, których Bitcoin jeszcze nie zaimplementował.
Można tu pomyśleć o funkcji podobnej do zk-SNARK, która znajduje zastosowanie w Zcash. Funkcjonalność ta zapewnia obecnie Zcash większą prywatność niż swoim użytkownikom oferuje Bitcoin. Użytkownicy mogliby zablokować swoje BTC, aby móc użyć nowej monety w łańcuchu bocznym.
Działającą wersję pomysłu na łańcuch boczny pod nazwą „drivechain” wdrożył wraz z innymi deweloperami Paul Sztorc, znany z prac nad BIP 300 i BIP 301. W treści dokumentu opisującego szczegóły rozwiązania czytamy:
„Drivechain umożliwia Bitcoinowi tworzenie, usuwanie, wysyłanie BTC i odbieranie BTC z „warstwy 2” zwanej „łańcuchem bocznym”. Łańcuchy boczne to Altcoiny, którym brakuje natywnej „monety” – zamiast tego należy najpierw przesłać istniejące monety [z innego łańcucha bloków].
Kiedy już znajdą się w łańcuchu bocznym, monety mogą zmieniać właściciela nieograniczoną liczbę razy i na nieograniczoną liczbę nowych sposobów. W ten sposób właściciele BTC mogą zdecydować się na skorzystanie z nowych funkcjonalności lub kompromisów. Bitcoinowcy, którzy nie zechcą korzystać z takiego rozwiązania, absolutnie nie muszą przejmować się tym, co robi jakikolwiek łańcuch boczny.”
Tak czy inaczej, „drivechainy” stanowią bardzo kontrowersyjny pomysł w społeczności programistów Bitcoina. Niektórzy deweloperzy twierdzą, że może to dać zbyt dużą władzę w ręce bitcoinowych górników. W związku z tym nie jest to funkcjonalność do wprowadzenia „na już”, aczkolwiek dobrze wiedzieć, że jest to jeden z pomysłów, do którego od czasu do czasu wraca się w bitcoinowych kuluarach.
Agregacja podpisów między danymi wejściowymi (cross-input signature aggregation – CISA)
Aktywacja Taproot utorowała drogę do implementacji całej gamy nowych rozwiązań na szczycie łańcucha bloków Bitcoin. Podobnie jest w przypadku agregacji sygnatur między danymi wejściowymi (CISA). Jak zapewne wiesz, podpisy cyfrowe są kluczową częścią Bitcoina. Kiedy użytkownik chce wysłać BTC, musi podpisać transakcję za pomocą swoich kluczy prywatnych, aby udowodnić, że jest właścicielem wysyłanych cyfrowych monet.
W czasie, kiedy twórca Bitcoina rozpoczynał pracę nad protokołem, musiał podjąć decyzję odnośnie doboru odpowiedniego schematu podpisu cyfrowego do zastosowania w nowym systemie. Potrzebował algorytmu, który na tamte czasy był używany powszechnie, dostępny i w pełni zrozumiały dla deweloperów. Pozostawało oczywiście najważniejsze: musiał być otwarto źródłowy. Spośród wszystkich dostępnych ówcześnie opcji, Satoshi zdecydował się na wykorzystanie dobrze znanej implementacji Elliptic Curve Digital Signature Algorithm (ECDSA).
ECDSA była wspierana przez protokół OpenSSL – zestaw narzędzi do szyfrowania, w celu poprawy jakości i prywatności komunikacji online. ECDSA charakteryzował się mniejszymi wymaganiami odnośnie struktury obliczeniowej oraz krótkimi kluczami. Pod kątem bezpieczeństwa, zapewniał jego proporcjonalny poziom przy wykorzystaniu systemów takich jak RSA. W efekcie, 256-bitowy klucz ECDSA zapewniał taki sam poziom bezpieczeństwa, co 02072-bitowy klucz RSA, zachowując jednocześnie niewielką część jego rozmiaru.
Pieter Wuille i wielu innych deweloperów, którzy pracowali na ulepszonej krzywej eliptycznej secp256k1 doprowadzili do tego, że ECDSA stało się jeszcze szybsze i bardziej wydajne. Niemniej jednak ECDSA posiada niedociągnięcia i braki, które stawiały ją w pozycji “do zmiany”. W związku z tym deweloperzy sięgnęli po też wcale nie nowe rozwiązanie, które miało poprawić stan rzeczy.
To rozwiązanie to „podpisy Schnorra„, które wprowadzono równolegle z Taproot. Umożliwiają one łączenie wielu sygnatur w jedną, czyniąc transakcje nieco tańszymi, zwiększając jednocześnie skalowalność.
Funkcja CISA umożliwia agregację podpisów w pojedynczej transakcji. Główną implikacją CISA jest to, że transakcje CoinJoin będą tańsze.
CoinJoin pozwala użytkownikom uniknąć pozostawiania śladów online. Dzięki temu, kryptowaluta uważana za „nie do końca anonimową”, ma szansę stać się bardziej „prywatna”. Zwolennicy tego rozwiązania mają nadzieję, że oddolny wysiłek zaszczepi najlepsze praktyki dotyczące prywatności i przełamie w końcu złą prasę, jeżeli chodzi o protokoły związane z anonimowością w sieci Bitcoin.
Dość powszechnym nieporozumieniem, zwłaszcza wśród nowych adeptów bitcoinowej sztuki jest twierdzenie, że Bitcoin jest anonimowy. Najprawdopodobniej, takie przesłanki orbitują przez wzgląd na „ciemną stronę” Bitcoina, jako sieci używanej przez osoby o nieczystych intencjach.
Problem polega na tym, że Bitcoin tak naprawdę nie do końca jest anonimowy. Można powiedzieć, że jest pseudo – anonimowy. Wszystkie adresy w łańcuchu bloków są publiczne. W związku z tym każdy, kto ma wystarczającą wiedzę i sprzęt, może wyśledzić adres IP powiązany z dowolnym adresem publicznym. Chyba że „nadawca” będzie w stanie „zaciemnić” swoje transakcje.
Protokoły chroniące prywatność, takie jak CoinJoin, pozwalają na „wyrzucenie niewydanych transakcji” (inaczej UTXO) do puli, która zawiera inne takie UTXO. Ten proces skutecznie zamazuje ślad pozostawiony przez bitcoiny w łańcuchu bloków. CoinJoin uważany jest przez wielu za najlepszą praktykę w zakresie uzyskania prywatności w sieci Bitcoina.
Używany za pośrednictwem portfeli Wasabi i Samurai CoinJoin jest zatem metodą zwiększania prywatności transakcji użytkowników. Dzięki CISA transakcje CoinJoin stałyby się tańsze, co zachęciłoby więcej użytkowników do korzystania z nich. Poprawiłoby to znacznie prywatność sieci Bitcoin. CoinJoin nie byłby już czymś, za co trzeba płacić więcej – stałby się normą.
Słowem podsumowania
Nie wiadomo, czy (i ewentualnie kiedy) omówione wyżej aktualizacje zostaną zaimplementowane do Bitcoina. Przeczytałeś jednak o tych, o których aktualnie dyskutuje się najczęściej. Jak zapewne zauważyłeś, większość z nich stała się możliwa do zaimplementowania dopiero po niedawnym aktywowaniu Taproot.
Protokół Bitcoina jest obsługiwany przez społeczność deweloperów, którzy każdego dnia ciężko pracują, aby sieć była coraz lepsza i coraz bardziej użyteczna. Z pewnością można postawić tezę, że z takim poziomem oddaniem bitcoinowa rewolucja ma się dobrze i jeszcze niejednym nas zaskoczy.
źródło grafiki tytułowej: link