Historia Bitcoina jest naznaczona kluczowymi aktualizacjami, które określiły jego trajektorię jako globalnej waluty cyfrowej. Wśród tych technicznych kamieni milowych niewiele było tak transformacyjnych lub tak gorąco dyskutowanych jak wdrożenie Segregated Witness. Często określane skrótem SegWit, ta aktualizacja protokołu została aktywowana w sierpniu 2017 roku po okresie intensywnej dyskusji społecznościowej i budowania konsensusu. Stanowiła przełomowy moment dla sieci, rozwiązując długotrwałe problemy związane ze skalowalnością i bezpieczeństwem.
Przed SegWit sieć Bitcoin zmagała się z rosnącą presją ze strony powiększającej się bazy użytkowników. W miarę wzrostu adopcji ograniczenia oryginalnego rozmiaru bloku stały się wąskim gardłem, prowadząc do zatłoczenia sieci i rosnących kosztów transakcji. Deweloperzy i interesariusze szukali rozwiązania, które złagodziłoby te presje bez naruszania zdecentralizowanej natury blockchaina. Segregated Witness wyłoniło się jako sprytne rozwiązanie inżynieryjne optymalizujące sposób przechowywania danych zamiast po prostu zwiększania limitu rozmiaru bloku.
Ta aktualizacja zrobiła więcej niż tylko poprawiła przepustowość. Fundamentalnie zmieniła mechanikę przetwarzania transakcji, rozwiązując techniczną lukę znaną jako malleability transakcji. Poprawiając ten problem, SegWit stworzył niezbędne podstawy dla rozwiązań drugiej warstwy, takich jak Lightning Network. To otworzyło drogę do natychmiastowych, niskokosztowych płatności, które wcześniej były trudne do bezpiecznego wdrożenia.
Zrozumienie SegWit wymaga spojrzenia poza same specyfikacje techniczne. Obejmuje to badanie modelu zarządzania Bitcoinem, ekonomii przestrzeni blokowej oraz dynamiki społeczności napędzającej ewolucję protokołu. Ta aktualizacja pokazała, że Bitcoin może się dostosowywać i skalować za pomocą soft forków, zachowując kompatybilność wsteczną przy wprowadzaniu radykalnych ulepszeń efektywności i użyteczności.
Wyzwanie skalowalności
Bitcoin został pierwotnie zaprojektowany z limitem rozmiaru bloków, które mogły być dodawane do blockchaina. Ten limit, ustalony na 1 megabajt (MB), służył jako środek ochronny przed atakami spamowymi w początkowych dniach sieci. Jednak w miarę jak Bitcoin wyrósł z obscurycznego eksperymentu w globalnie uznany aktywo, ta funkcja bezpieczeństwa zaczęła działać jak ograniczenie wzrostu.
Wąskie gardło rozmiaru bloku
Każda transakcja Bitcoin składa się z danych, które muszą być przetwarzane i przechowywane przez górników. Te dane obejmują wejścia, wyjścia oraz podpisy cyfrowe potwierdzające własność wydawanych środków. W erze przed SegWit wszystkie te informacje musiały konkurować o miejsce w sztywnym limicie 1 MB bloku.
Wraz z gwałtownym wzrostem popularności sieci popyt na przestrzeń blokową często przekraczał dostępną podaż. Użytkownicy znaleźli się w wojnie licytacyjnej, dołączając wyższe opłaty do swoich transakcji, aby zachęcić górników do włączenia ich do następnego bloku. Ta dynamika powodowała wolniejsze czasy potwierdzeń dla użytkowników płacących standardowe opłaty.
W okresach szczytowych sieć stawała się zatłoczona, czyniąc małe płatności lub mikropłatności niepraktycznymi. Społeczność uznała, że aby Bitcoin działał skutecznie jako magazyn wartości i środek wymiany, przepustowość sieci musiała zostać zwiększona. Debaty koncentrowały się na tym, jak osiągnąć tę skalowalność bez poświęcania bezpieczeństwa lub decentralizacji.
Dylemat hard forka
Jednym z proponowanych rozwiązań problemu skalowalności był hard fork. Hard fork to radykalna zmiana protokołu, która czyni wcześniej nieważne bloki/transakcje ważnymi lub odwrotnie. W kontekście skalowania oznaczałoby to po prostu przepisanie kodu, aby umożliwić większe bloki, takie jak 2 MB lub 8 MB.
Jednak hard forki niosą znaczące ryzyka. Wymagają jednoczesnej aktualizacji oprogramowania przez wszystkie węzły w sieci. Jeśli segment społeczności odmówi aktualizacji lub nie zgodzi się ze zmianą, blockchain może się podzielić na dwie oddzielne łańcuchy. Tak stało się z powstaniem Bitcoin Cash, który wybrał zwiększenie rozmiaru bloku za pomocą hard forka.
Deweloperzy Bitcoin Core priorytetowo traktowali bezpieczniejsze podejście znane jako soft fork. Soft fork to aktualizacja kompatybilna wstecz, co oznacza, że węzły uruchamiające starsze wersje oprogramowania nadal mogą uczestniczyć w sieci. SegWit został zaprojektowany jako soft fork, aby zapewnić jedność sieci przy jednoczesnym dostarczeniu niezbędnych ulepszeń przepustowości.
Konsensus i zarządzanie
Droga do aktywacji SegWit podkreśliła unikalną naturę zarządzania Bitcoinem. W przeciwieństwie do scentralizowanych systemów, gdzie lider dyktuje zmiany, Bitcoin opiera się na konsensusie wśród zróżnicowanej grupy uczestników. Obejmuje to górników, deweloperów, operatorów węzłów i użytkowników końcowych.
Propozycja SegWit, znana jako Bitcoin Improvement Proposal (BIP) 141, wymagała bardzo wysokiego progu poparcia od górników do aktywacji. Konkretnie, 95% mocy hash górniczej musiało zasygnalizować gotowość w ciągu dwutygodniowego okresu. Ten wysoki próg zapewnia, że aktualizacje mają przytłaczające poparcie przed wymuszeniem, minimalizując ryzyko niestabilności sieci.
Jak działa SegWit pod maską
Główna innowacja Segregated Witness kryje się w jej nazwie. „Segregated” oznacza rozdzielenie, a „Witness” odnosi się do podpisów cyfrowych weryfikujących transakcję. W starszych transakcjach Bitcoin dane podpisu były splecione z danymi transakcji, zajmując znaczną część cennej przestrzeni 1 MB bloku.
Rozdzielenie danych świadka
SegWit przebudował format transakcji, przenosząc dane świadka (podpisy) poza główną strukturę bloku. Chociaż te dane są nadal rejestrowane i weryfikowane, przechowywane są w oddzielnej strukturze biegnącej równolegle do bazowego bloku transakcji. To rozdzielenie było kluczem do odblokowania większej przepustowości bez technicznego zwiększania limitu 1 MB dla starych węzłów.
Aby to zwizualizować, wyobraź sobie pociąg reprezentujący blok Bitcoin. W starszym systemie pasażerowie (szczegóły transakcji) i ich bagaż (podpisy) byli upchnięci w tych samych wagonach. Pociąg miał ścisły limit objętości, jaką mógł przewieźć.
SegWit efektywnie dodał specjalny wagon towarowy na końcu pociągu specjalnie na bagaż. Przenosząc ciężki bagaż poza wagony pasażerskie, pociąg mógł nagle przewieźć znacznie więcej pasażerów w tych samych głównych przedziałach. „Bagaż” nadal podróżuje z pociągiem, ale nie zajmuje już premium przestrzeni potrzebnej dla samych pasażerów.
Waga bloku vs. rozmiar bloku
Aby wdrożyć tę zmianę, SegWit wprowadził nowy koncept zwany „wagą bloku”. Stara miara rozmiaru bloku w prostych bajtach została zastąpiona systemem przypisującym różne „wagi” różnym częściom transakcji. Pozwoliło to sieci na rozróżnienie krytycznych danych transakcji od danych świadka.
W tym nowym systemie bazowe dane transakcji są liczone w pełnym rozmiarze, podczas gdy dane świadka są dyskontoowane. Konkretnie, dane świadka ważą znacznie mniej niż dane transakcji w obliczeniach limitu bloku. Ta zmiana efektywnie zwiększyła limit rozmiaru bloku z 1 MB do teoretycznych 4 MB „jednostek wagi”.
Ta zmiana zachęciła użytkowników i dostawców portfeli do adopcji adresów SegWit. Transakcje wykorzystujące nowy format były tańsze w wysyłaniu, ponieważ zużywały mniej „wagi” w bloku w porównaniu do starszych transakcji. Ta ekonomiczna zachęta pomogła w adopcji aktualizacji w całym ekosystemie.
Wirtualne bajty (vBytes)
Wraz z wprowadzeniem wagi bloku koncept opłat transakcyjnych również ewoluował. Opłaty zaczęto obliczać w „wirtualnych bajtach” (vBytes) zamiast surowych bajtów. vByte to jednostka pomiaru wywodząca się z wagi transakcji.
Ponieważ dane świadka są dyskontoowane, transakcja SegWit ma mniejszy rozmiar vByte niż starsza transakcja o tym samym surowym rozmiarze. Oznacza to, że przy tej samej stawce opłaty (satoshis na bajt) transakcja SegWit kosztuje mniej w całkowitych opłatach.
Ta poprawa efektywności była natychmiastowa dla użytkowników przechodzących na portfele kompatybilne z SegWit. Pozwoliła sieci na przetwarzanie większej liczby transakcji na sekundę, efektywnie zwiększając przepustowość bez niebezpieczeństw związanych z hard forkem. Optymalizacja udowodniła, że inteligentne inżynierstwo może wycisnąć więcej wydajności z istniejącej infrastruktury.
Rozwiązanie malleability transakcji
Chociaż skalowanie było główną cechą SegWit, aktualizacja rozwiązała inną krytyczną wadę techniczną znaną jako malleability transakcji. Ten problem dręczył Bitcoina od jego powstania i stanowił główną barierę dla rozwoju zaawansowanych protokołów drugiej warstwy.
Malleability odnosi się do możliwości zmiany przez osobę trzecią unikalnego identyfikatora (TXID) transakcji przed jej potwierdzeniem na blockchainie. Ważne jest, że ta zmiana mogła być dokonana bez unieważnienia samej transakcji lub zmiany fundamentalnych szczegółów, takich jak nadawca, odbiorca czy kwota.
W starszym systemie podpis cyfrowy był uwzględniony w obliczeniach hasha transakcji (TXID). Jednak podpisy kryptograficzne mogą być matematycznie reprezentowane w nieco różnych formach, pozostając ważnymi. Atakujący lub węzeł przekaźnikowy mógł lekko zmodyfikować dane podpisu, co skutkowałoby całkowicie innym TXID.
Jeśli TXID uległ zmianie, nadawca mógł uwierzyć, że transakcja nie powiodła się, podczas gdy odbiorca (lub atakujący) potwierdził zmodyfikowaną wersję. To powodowało zamieszanie i czyniło niebezpiecznym łańcuchowanie niepotwierdzonych transakcji. Jeśli pierwszy transakcja w łańcuchu miał zmieniony ID, każda kolejna transakcja odwołująca się do tego ID stawałaby się nieważna.
SegWit naprawił to, usuwając dane podpisu z części transakcji używanej do generowania TXID. Ponieważ „witness” został wydzielony, wszelkie zmiany w danych podpisu nie wpływały już na ID transakcji. To uczyniło ID transakcji niezmiennym od momentu jej utworzenia.
Włączenie Lightning Network
Naprawa malleability transakcji była katalizatorem dla Lightning Network. Lightning Network to rozwiązanie skalowania warstwy 2, które w dużej mierze polega na możliwości tworzenia bezpiecznych łańcuchów niepotwierdzonych transakcji.
Podstawa dla warstwy 2
Aby kanały płatności działały, dwie strony efektywnie otwierają wspólne konto na blockchainie, a następnie wymieniają podpisane transakcje off-chain. Te transakcje off-chain aktualizują saldo kanału bez obciążania głównego blockchaina.
Jednak te transakcje off-chain zależą od początkowej „transakcji finansującej” bezpiecznie zakotwiczonej. Jeśli malleability transakcji nadal byłoby możliwe, złośliwy aktor mógłby potencjalnie zmienić ID transakcji finansującej. To unieważniłoby całą kolejną logikę off-chain uzgodnioną przez strony.
Zabezpieczając ID transakcji, SegWit zapewnił solidne podstawy potrzebne dla tych smart kontraktów. Pozwoliło to węzłom Lightning ufać, że transakcje, które podpisują off-chain, pozostaną ważne podczas ostatecznego rozliczenia na głównej sieci Bitcoin.
Natychmiastowe rozliczenia
Z usuniętym ryzykiem malleability, Lightning Network mogło być bezpiecznie wdrożone. Umożliwiło to niemal natychmiastowe rozliczenia płatności między użytkownikami na całym świecie. Podczas gdy SegWit zapewnił skromny wzrost przepustowości on-chain, włączenie Lightning oferowało potencjał praktycznie nieograniczonego skalowania off-chain.
Użytkownicy mogli teraz dokonywać milionów transakcji bez obciążania głównego blockchaina, rozliczając tylko ostateczny wynik. To połączenie efektywności on-chain (poprzez SegWit) i skalowania off-chain (poprzez Lightning) reprezentuje główną strategię Bitcoina na radzenie sobie z globalnym wolumenem transakcji.
Saga aktywacji: BIP 141 i UASF
Wdrożenie SegWit nie było jedynie aktualizacją techniczną; było historycznym wydarzeniem w zdecentralizowanym zarządzaniu. Proces ujawnił złożone dynamiki władzy między górnikami, deweloperami i użytkownikami w ekosystemie Bitcoin.
Propozycja (BIP 141)
Aktualizacja SegWit została formalnie zaproponowana jako Bitcoin Improvement Proposal 141. Aby aktywować się płynnie, deweloperzy ustalili próg wymagający 95% bloków sygnalizujących poparcie dla aktualizacji w ciągu dwutygodniowej epoki trudności. Miało to zapewnić, że sieć się nie podzieli.
Jednak osiągnięcie tego konsensusu okazało się trudne. Różne polityczne i ekonomiczne interesy wśród głównych pul górniczych doprowadziły do impasu. Niektórzy górnicy woleli hard fork do bezpośredniego zwiększenia rozmiaru bloku, inni wahali się z aktualizacją infrastruktury.
Przez miesiące sygnalizacja aktywacji utrzymywała się znacznie poniżej wymaganego progu. Wydawało się, że aktualizacja może utknąć na zawsze, podkreślając potencjalną wadę polegania na sygnalizacji górników przy aktualizacjach protokołu.
User Activated Soft Fork (BIP 148)
Rozczarowani brakiem postępów, w społeczności wyłonił się ruch oddolny. Ta inicjatywa była znana jako User Activated Soft Fork (UASF), czyli BIP 148. Koncept był rewolucyjny: zamiast czekać na głosowanie górników, ekonomiczna większość węzłów (użytkownicy, giełdy i firmy) wymusiłaby aktualizację samodzielnie.
Uczestnicy UASF uruchamiali wersję oprogramowania Bitcoin, która odrzucała wszelkie bloki niesygnalizujące poparcia dla SegWit po określonej dacie. To efektywnie narysowało linię w piasku. Jeśli górnicy kontynuowaliby ignorowanie SegWit, ich bloki zostałyby odrzucone przez znaczną część sieci, powodując utratę przychodów.
Zagrożenie User Activated Soft Fork przesunęło równowagę władzy. Pokazało, że chociaż górnicy przetwarzają transakcje, to użytkownicy definiują reguły protokołu. Stawiając czoła ekonomicznemu naciskowi UASF, górnicy skapitulowali, a SegWit został zablokowany i aktywowany w sierpniu 2017 roku.
Typy adresów i kompatybilność
Po aktywacji SegWit ekosystem Bitcoin увидел pojawienie się różnych formatów adresów. Zrozumienie tych formatów jest niezbędne dla użytkowników, którzy chcą skorzystać z niższych opłat i korzyści efektywności oferowanych przez SegWit.
Adresy Legacy
Oryginalny format adresu Bitcoin jest znany jako Legacy. Te adresy zazwyczaj zaczynają się od liczby 1. Transakcje wysyłane z adresów Legacy są większe, ponieważ nie wykorzystują rozdzielenia danych świadka. W konsekwencji są najdroższe pod względem opłat transakcyjnych.
Nested SegWit (P2SH)
Aby zapewnić płynną adopcję, deweloperzy wprowadzili warstwę kompatybilności znaną jako Pay to Script Hash (P2SH). Te adresy zaczynają się od liczby 3. Pozwoliły użytkownikom wysyłać transakcje SegWit nawet jeśli portfel nadawcy nie wspierał w pełni nowego natywnego formatu.
Nested SegWit zapewniał pośrednie rozwiązanie. Oferował znaczące oszczędności opłat w porównaniu do adresów Legacy, choć nie tak duże jak pełne natywne wdrożenie. Przez długi czas był to standard dla wielu giełd i dostawców portfeli podczas aktualizacji systemów.
Native SegWit (Bech32)
Najefektywniejszy format to Native SegWit, znany również jako Bech32. Te adresy zaczynają się od bc1. Adresy Native SegWit są wyróżniające się, ponieważ są niewrażliwe na wielkość liter, zmniejszając ryzyko błędów pisania.
Co ważniejsze, transakcje Native SegWit są mniejsze w wirtualnych bajtach niż ich odpowiedniki Nested. To skutkuje najniższymi możliwymi opłatami transakcyjnymi dla użytkowników. W miarę dojrzewania ekosystemu Native SegWit stał się domyślnym standardem dla większości nowoczesnych portfeli i usług.
| Typ adresu | Prefiks | Efektywność opłat | Kompatybilność |
|---|---|---|---|
| Legacy | 1... | Niska | Uniwersalna |
| Nested SegWit | 3... | Średnia | Wysoka |
| Native SegWit | bc1... | Wysoka | Nowoczesne portfele |
Poza SegWit: Taproot i Ordinals
Pomyślne wdrożenie SegWit udowodniło, że Bitcoin może przechodzić złożone aktualizacje bez zakłócania jego głównej propozycji wartości. Ten sukces utorował drogę dla kolejnych innowacji, które dalej rozszerzyły możliwości sieci.
Taproot i podpisy Schnorr
W listopadzie 2021 roku Bitcoin aktywował aktualizację Taproot. Taproot zbudował bezpośrednio na fundamentach położonych przez SegWit. Wprowadził podpisy Schnorr, które pozwoliły na jeszcze większą efektywność i prywatność.
Podobnie jak SegWit, Taproot zmienił sposób przechowywania danych na blockchainie. Umożliwił agregację podpisów, gdzie wiele podpisów w złożonej transakcji mogło być połączonych w jeden podpis. To uczyniło złożone smart kontrakty nieodróżnialnymi od zwykłych transakcji, poprawiając prywatność przy oszczędzaniu przestrzeni blokowej.
Bez zmian strukturalnych wprowadzonych przez SegWit, konkretnie systemu wersjonowania skryptów, aktualizacje jak Taproot byłyby znacznie trudniejsze do wdrożenia. SegWit ustanowił jasną ścieżkę dla przyszłej rozszerzalności.
Wzrost Ordinals
Najnowiej wprowadzenie Bitcoin Ordinals wykorzystało infrastrukturę SegWit w nieoczekiwany sposób. Ordinals pozwalają użytkownikom inskrybować dowolne dane — takie jak obrazy, tekst czy kod — bezpośrednio na indywidualnych satoshi.
Jest to możliwe, ponieważ SegWit dyskontoował „wagę” danych świadka. Inskrybujący zorientowali się, że mogą przechowywać duże ilości danych w polu świadka transakcji za ułamek kosztu przechowywania ich w głównej części bloku. Chociaż kontrowersyjne dla niektórych, którzy postrzegają to jako spam, Ordinals pokazały elastyczność przestrzeni danych świadka.
Ten nieoczekiwany przypadek użycia podkreśla solidną naturę projektu SegWit. Tworząc oddzielny, dyskontoowany pas dla danych, aktualizacja nieświadomie stworzyła płótno dla artefaktów cyfrowych, dalej dywersyfikując użyteczność blockchaina Bitcoin.
Wniosek
Segregated Witness stanowi świadectwo odporności i adaptacyjności sieci Bitcoin. Stawiając czoła krytycznemu wąskiemu gardłu zagrażającemu wzrostowi, społeczność zjednoczyła się za rozwiązaniem eleganckim, kompatybilnym wstecz i myślącym perspektywicznie. Ponownie wyobrażając strukturę danych transakcji, SegWit przyniósł natychmiastową ulgę od wysokich opłat, zachowując decentralizację, która nadaje Bitcoinowi wartość.
Dziedzictwo SegWit wykracza daleko poza proste obliczenia wagi bloku. Rozwiązał uporczywą lukę malleability transakcji, odblokowując potencjał rozwiązań skalowania warstwy 2 jak Lightning Network. Co więcej, ustanowił precedens dla zarządzania napędzanego przez użytkowników, dowodząc, że ekonomiczna większość może efektywnie sprawdzać władzę podmiotów górniczych.
W miarę ewolucji Bitcoina struktury zbudowane przez SegWit pozostają centralne dla jego działania. Od efektywności adresów Native SegWit po zaawansowane możliwości Taproot i Ordinals, aktualizacja zdefiniowała na nowo to, co jest możliwe na blockchainie. Zapewniła, że Bitcoin może skalować się, aby sprostać globalnemu zapotrzebowaniu bez kompromisów w zasadach, na których został założony.
SegWit zrewolucjonizował Bitcoina, separując podpisy od danych transakcji, efektywnie zwiększając przepustowość bloku i naprawiając krytyczne błędy, aby umożliwić przyszłe skalowanie.