Czemu warto korzystać z Segwit
Gdyby każda transakcja w sieci Bitcoin była dzisiaj transakcją SegWit, bloki zawierałyby do 8 000 transakcji, a 138 000 niepotwierdzonych zaległości transakcyjnych zniknęłoby natychmiastowo. Opłaty transakcyjne znowu prawie by nie istniały.
Gdyby każda transakcja w sieci Bitcoin była dzisiaj transakcją SegWit, bloki zawierałyby do 8 000 transakcji, a 138 000 niepotwierdzonych zaległości transakcyjnych zniknęłoby natychmiastowo. Opłaty transakcyjne znowu prawie by nie istniały.
Oto kluczowe rzeczy, które umożliwia SegWit:
- Zmienia sposób przechowywania danych w blokach bitcoinowych.
- Zwiększa wydajność we wszystkich wersjach oprogramowania.
- Usuwa ciągliwość transakcji, błąd, który był podstawową blokadą dla wielu projektów bitcoin.
Wyeliminowanie blokad
Ostatni punkt może mieć w ostateczności największe znaczenie. Wielu deweloperów twierdzi, że SegWit sprzyja rozwojowi bardziej perspektywicznych technologii niezbędnych do mainstreamowego wykorzystania bitcoina.
Segwit obejmuje szeroki zakres funkcji, z których wiele ma charakter wysoce techniczny. Oto zalety tych funkcji:
Uniemożliwienie wprowadzania zmian w transakcji (Malleability Fixes)
Transakcje bitcoinowe są identyfikowane za pomocą 64-cyfrowego szesnastkowego skrótu nazywanego identyfikatorem transakcji (txid), który jest oparty zarówno na wydanych monetach, jak i na tym, kto będzie w stanie wydać wyniki transakcji.
Niestety, sposób obliczania txid pozwala komukolwiek na dokonywanie niewielkich modyfikacji w transakcji, które nie zmienią jej postanowień, ale zmienią wartość txid. BIP 62 ("zajmujący się plastycznością") próbował rozwiązać te problemy w sposób fragmentaryczny, ale był zbyt skomplikowany, aby mógł zostać wdrożony jako kontrola konsensusu i został wycofany. Jeśli jeden lub więcej podpisujących transakcję zrewiduje swoje podpisy, transakcja zachowa ważność i wypłaci te same kwoty na te same adresy, ale txid zmieni się całkowicie, ponieważ zawiera podpisy.
Segwit zapobiega modyfikacjom wprowadzanym przez strony trzecie (third-party malleability) i scriptSig, poprzez umożliwienie, użytkowników bitcoina, przenoszenia podatnych na zmiany treści na „świadka transakcji” oraz segregację danego „świadka”, tak aby zmiany nie wpływały na obliczenia txid.
Skorzystać na tym mogą:
-
Autorzy portfeli śledzący wydane bitcoiny: najłatwiej jest monitorować status własnych wychodzących transakcji poprzez proste obserwowanie ich za pomocą txid. Jednak w systemie podatnym za zmiany (third-party malleability) portfele muszą implementować dodatkowy kod, aby móc poradzić sobie ze zmienionymi txids.
-
**Ktokolwiek wydający niepotwierdzone transakcje: **Jeżeli A zapłaci B w transakcji nr 1, z kolei B wykorzysta tę płatność do zapłacenia C w transakcji nr 2, a następnie płatność nr 1 dokonana przez A zostanie zmanipulowana i potwierdzona innym txid, wtedy transakcja nr 2 staje się nieważna, a C nie dostanie zapłaty. Jeśli B jest godne zaufania ponowi płatność – w innym przypadku może zachować bitcoiny dla siebie.
-
Lightning Network: Po „Malleability Fixed” sieć Lightning jest mniej skomplikowana dla implementacji i znacznie bardziej wydajna w wykorzystaniu miejsca na blockchainie. Dodatkowo możliwe stało się uruchamianie lżejszych klientów Lightning, którzy zlecają monitorowanie blockchaina zamiast potrzeby, każdego klienta, na pełen węzeł Bitcoin.
-
Każdy korzystający z blockchaina: smart kontrakty, takie jak kanały mikropłatności i zapowiadane nowe smart kontrakty stały się mniej skomplikowane w projektowaniu, rozumieniu i monitorowaniu.
Linearne skalowanie operacji sighash
Głównym problemem związanym z prostym podejściem do zwiększania rozmiaru bloku bitcoinów jest to, że w przypadku niektórych transakcji skala podpisów miesza się w sposób kwadraturowy, a nie liniowy.
Zasadniczo podwojenie rozmiaru transakcji może podwajać zarówno liczbę operacji podpisu, jak i ilość danych, które muszą być hashowane dla każdego z podpisów, które mają być zweryfikowane.
Segwit rozwiązuje ten problem, zmieniając obliczanie wartości transakcji dla podpisów, tak aby każdy bajt transakcji musiał być hashowany tylko dwa razy. Zapewnia to tę samą funkcjonalność, ale sprawia, że jest wydajniejsza. Tym samym duże transakcje wciąż mogą być generowane, bez problemów związanych z hashowaniem podpisu.
Usunięcie skalowania kwadratowego hashowanych danych w celu weryfikacji podpisów zwiększa bezpieczeństwo powiększania bloku. Wykonanie tego bez ograniczania rozmiarów transakcji pozwala Bitcoinowi nadal obsługiwać płatności, które trafiają lub pochodzą z dużych grup takich jak płatności górniczych lub usługi crowdfundingu.
Zmodyfikowany hash dotyczy tylko operacji podpisu zainicjowanych z danych świadka, więc operacje sygnatur z bloku podstawowego będą nadal wymagać niższych limitów.
Podpisywanie wartości wejściowych
Kiedy portfel podpisuje transakcję, może łatwo zweryfikować całkowitą wydaną kwotę, ale może tylko bezpiecznie określić opłatę, wykonując pełną kopię wszystkich wydanych transakcji wejściowych, i musi hashować każdą z nich, aby upewnić się, że nie podają fałszywych danych. Ponieważ pojedyncze transakcje mogą mieć rozmiar do 1 MB, niekoniecznie jest to tania operacja, nawet jeśli podpisywana transakcja jest sama w sobie niewielka.
Segwit rozwiązuje to przez jawne hashowanie wartości wejściowej. Oznacza to, że portfel sprzętowy może po prostu otrzymać hash transakcji, indeks i wartość (oraz informację, jaki publiczny klucz został użyty) i może bezpiecznie podpisać wydawanie transakcji, bez względu na to, jak duża i skomplikowana, sprzedawana transakcja była.
Producenci i użytkownicy portfeli sprzętowych są oczywistymi beneficjentami; Dodatkowo znacznie ułatwi to bezpieczne korzystanie z bitcoinów w urządzeniach z aplikacjami "Internet of things”.
Zwiększone bezpieczeństwo funkcji multisig za pomocą pay-to-script-hash (P2SH)
Płatności Multisig używają obecnie P2SH, który jest zabezpieczony przez 160-bitowy algorytm HASH160 (RIPEMD z SHA256). Zwiększone bezpieczeństwo funkcji multisig za pomocą skryptu pay-to-script (P2SH)
Płatności Multisig używają obecnie P2SH, który jest zabezpieczony przez 160-bitowy algorytm HASH160 (RIPEMD z SHA256). Jeśli jednak jeden z sygnatariuszy chce ukraść wszystkie fundusze, może doświadczyć kolizji między ważnym adresem jako częścią skryptu wieloskładnikowego a skryptem, który po prostu płaci im wszystkie fundusze, mając tylko 80-bitową (280) wartość pracy, która jest już w sferze możliwości dla wyjątkowo dobrze wyposażonego napastnika.
Segwit rozwiązuje to, używając HASH160 tylko dla płatności bezpośrednio do pojedynczego klucza publicznego (gdzie ten rodzaj ataku jest bezużyteczny), podczas używania 256-bitowych SHA256 dla płatności do skryptu hash.
Każdy płacący za multisig lub smart kontrakty za pośrednictwem segwitu korzysta z dodatkowego zabezpieczenia skryptów.
Wersjonowanie skryptów
Zmiany w skrypcie bitcoina zapewniają zarówno zwiększone bezpieczeństwo, jak i ulepszoną funkcjonalność. Jednak projekt skryptu pozwala tylko zmianom zgodnych wstecz (soft-forking) na implementację poprzez zastąpienie jednego z dziesięciu dodatkowych OP_NOP kodów, nowym opcodem, który może warunkowo zawieść skrypt, ale zazwyczaj nic nie robi.
Segwit rozwiązuje ten problem, dodając numer wersji skryptów, więc dodatkowe kody operacyjne, które wymagałyby użycia hard-fork w transakcjach non-segwit, mogą być wspierane przez proste zwiększanie wersji skryptu.
Łatwiejsze zmiany w skryptach opcodów ułatwią tworzenie zaawansowanych skryptów w Bitcoin. Obejmuje to zmiany, takie jak wprowadzanie podpisów Schnorr, używanie odzyskiwania kluczy do zmniejszania rozmiarów podpisów, wspieranie sidechains lub tworzenie jeszcze bardziej inteligentnych kontraktów za pomocą Merklized Abstract Syntax Trees (MAST) i innych pomysłów będących na poziomie badań.
Zmniejszenie wzrostu UTXO
Baza danych Unspent Transaction Output (UTXO) jest obsługiwana przez każdy węzeł Bitcoin w celu ustalenia, czy nowe transakcje są ważne czy nieuczciwe. Aby zapewnić wydajną pracę sieci, ta baza danych musi być bardzo szybka w wyszukiwaniu i modyfikowaniu, a najlepiej powinna móc zmieścić się w pamięci głównej (RAM), więc zachowanie wielkości bazy danych w tak małych bajtach, jak to możliwe, jest wartościowe.
Staje się to coraz trudniejsze, ponieważ Bitcoin rośnie, ponieważ każdy nowy użytkownik musi mieć co najmniej jeden własny wpis UTXO i woli mieć wiele wpisów, aby poprawić swoją prywatność i elastyczność, lub zapewnić wsparcie dla kanałów płatniczych lub innych smart kontraktów.
Segwit poprawia sytuację, dzięki czemu dane sygnatur, które nie mają wpływu na rozmiar zestawu UTXO, kosztują o 75% mniej niż dane, które mają wpływ na rozmiar zestawu UTXO. Oczekuje się, że zachęci to użytkowników do faworyzowania transakcji, które minimalizują wpływ na zestaw UTXO, w celu zminimalizowania opłat, oraz do zachęcenia projektantów do tworzenia smart kontraktów i nowych funkcji w sposób, który zminimalizuje wpływ na zestaw UTXO. Ponieważ segwit jest zmianą soft-fork i nie zwiększa rozmiaru bazy, najgorszy współczynnik wzrostu zestawu UTXO pozostaje taki sam.
Zredukowany wzrost UTXO przyniesie korzyści górnikom, firmom i użytkownikom, którzy uruchamiają pełne węzły, co z kolei pomaga utrzymać bieżące bezpieczeństwo sieci bitcoin w miarę zwiększającej się liczby użytkowników wchodzących do systemu. Użytkownicy i deweloperzy, którzy pomagają zminimalizować wzrost zestawu UTXO, skorzystają z niższych opłat w porównaniu do tych, którzy ignorują wpływ swoich transakcji na wzrost UTXO.
Efektywność wzrasta, gdy weryfikacja podpisów znika
Podpisy dotyczące transakcji historycznych mogą być mniej interesujące niż podpisy przyszłych transakcji – na przykład Bitcoin Core domyślnie nie sprawdza podpisów transakcji przed ostatnim punktem kontrolnym, a niektórzy klienci SPV po prostu nie sprawdzają samych podpisów, ufając, że zostało już zrobione przez górników lub inne węzły. Obecnie jednak dane podpisu stanowią integralną część transakcji i muszą być obecne w celu obliczenia wartości hashowania transakcji.
Segregowanie danych podpisu pozwala węzłom, które nie są zainteresowane danymi podpisu, na usunięcie go z dysku lub na uniknięcie pobierania go w pierwszej kolejności, oszczędzając zasoby.
Ponieważ więcej transakcji używa adresów segwitu, osoby pracujące z węzłami oczyszczonymi lub węzłami SPV będą mogły działać z mniejszą przepustowością i miejscem na dysku.
Pojemność bloków / wzrost rozmiaru
Ponieważ stare węzły będą pobierać tylko blok pozbawiony świadectwa, wymuszają na nich tylko regułę limitu wielkości bloku 1 MB. Nowe węzły, które rozumieją pełny blok z „danymi świadka”, mogą zatem zastąpić ten limit nowym, pozwalając na większe rozmiary bloków. Dlatego posegregowany świadek korzysta z tej okazji, aby podnieść limit rozmiaru bloku do prawie 4 MB, i dodaje nowy limit kosztów, aby zapewnić, że bloki pozostają zrównoważone pod względem wykorzystania zasobów (efektywnie powoduje to, że efektywny limit waha się między 1,6 do 2 MB).
Osoby korzystające z ulepszonych portfeli będą mogły skorzystać ze zwiększonego rozmiaru bloku, przesuwając podpisy do sekcji świadków transakcji.