Bitcoin często opisuje się jako cyfrowe złoto, co sugeruje statyczną i niezmienną naturę. Jednak oprogramowanie napędzające sieć Bitcoin to żywy protokół, który przechodzi konserwację, poprawki błędów i uaktualnienia. W przeciwieństwie do scentralizowanego rozwoju oprogramowania, gdzie CEO firmy lub menedżer produktu dyktuje funkcje, Bitcoin polega na zdecentralizowanej sieci uczestników, którzy zgadzają się na zmiany. Ten proces jest celowy, powolny i silnie nastawiony na zachowanie status quo, aby zapewnić bezpieczeństwo miliardów dolarów wartości.
Ewolucja protokołu nie jest regulowana przez formalny system głosowania ani pojedynczy autorytet. Zamiast tego działa poprzez unikalną kombinację dokumentacji technicznej, recenzji rówieśniczej i konsensusu społeczności. Zrozumienie, jak pomysł przechodzi od prostej dyskusji na liście mailingowej do globalnie aktywowanej zmiany kodu, ujawnia odporność sieci Bitcoin. Podkreśla system zaprojektowany tak, aby opierać się przejęciu przez jakąkolwiek pojedynczą grupę, czy to deweloperów, górników, czy interesów korporacyjnych.
W sercu tego procesu ewolucyjnego znajduje się Bitcoin Improvement Proposal, czyli BIP. Jest to główny mechanizm proponowania nowych funkcji, zbierania opinii społeczności na temat problemu oraz dokumentowania decyzji projektowych. BIP nie jest wiążącym głosowaniem, lecz technicznym dokumentem projektowym. Dostarcza informacji społeczności Bitcoin lub opisuje nową funkcję dla Bitcoin lub jego procesów.
Framework Bitcoin Improvement Proposal
Aby zrozumieć, jak zmienia się Bitcoin, najpierw trzeba zrozumieć proces standaryzacji. System BIP jest silnie inspirowany procesem Python Enhancement Proposal (PEP). Służy jako formalny sposób wprowadzania zmian w kodzie źródłowym lub otaczającym ekosystemie. Każdy może napisać BIP, ale jego akceptacja i wdrożenie to rygorystyczny proces, któremu przetrwa niewiele propozycji.
Definiowanie BIP
BIP to w istocie dokument techniczny. Oferuje zwięzłą specyfikację techniczną funkcji oraz uzasadnienie jej wprowadzenia. Autor jest odpowiedzialny za budowanie konsensusu w społeczności i dokumentowanie sprzecznych opinii. Istnieją trzy główne typy BIP. Standards Track BIPs opisują wszelkie zmiany wpływające na większość lub wszystkie implementacje Bitcoin, takie jak zmiana protokołu sieciowego lub zmiana zasad ważności bloków lub transakcji.
Informational BIPs opisują problem projektowy Bitcoin, podają ogólne wytyczne lub informacje dla społeczności Bitcoin, ale nie proponują nowej funkcji. Process BIPs opisują proces związany z Bitcoin lub proponują zmianę (lub wydarzenie) w procesie. Większość publicznej uwagi skupia się na Standards Track BIPs, ponieważ to one zmieniają reguły konsensusu sieci.
Cykl życia propozycji
Życie BIP zaczyna się na długo przed nadaniem mu numeru. Zazwyczaj rozpoczyna się dyskusjami na liście mailingowej deweloperów Bitcoin. To tam początkowy pomysł jest weryfikowany, krytykowany i często rozmontowywany przez innych deweloperów. Jeśli pomysł przetrwa tę początkową próbę ognia, autor przygotowuje tekst BIP.
Po przesłaniu szkicu do repozytorium BIP, edytor nadaje mu numer. Ten status nazywa się „Draft”. Stamtąd propozycja przechodzi przez różne etapy. Jeśli społeczność uzna pracę za wartościową, może przejść do statusu „Proposed”. Jeśli zmiany zostaną wdrożone i sieć je aktywuje, BIP staje się „Final” lub „Active”. Odwrotnie, propozycje mogą być „Rejected”, „Withdrawn” przez autora lub oznaczone jako „Obsolete”, jeśli zostaną zastąpione nowszymi rozwiązaniami.
Mechanizm konsensusu
Najbardziej mylącym aspektem rozwoju Bitcoin dla osób z zewnątrz jest brak formalnej struktury zarządzania. Nie ma fundacji ani lidera, który stempluje „zatwierdzone” na BIP. Zamiast tego sieć polega na koncepcji znanej jako „rough consensus”. Jest to termin zapożyczony z Internet Engineering Task Force (IETF). Nie oznacza to jednomyślności.
Zrozumienie rough consensus
Rough consensus osiąga się, gdy społeczność techniczna generalnie zgadza się, że propozycja jest solidna i że wszystkie znaczące zastrzeżenia zostały zaadresowane. Jest to pomiar jakościowy, a nie ilościowy głos. Jeśli propozycja ma silne walory techniczne, ale napotyka uzasadnione obawy bezpieczeństwa ze strony znaczącej części deweloperów, nie zostanie przyjęta.
Ta dynamika zmusza autorów do angażowania się w dyskusje z krytykami. Muszą ulepszać swoje propozycje, aż zastrzeżenia zostaną rozwiązane lub udowodnione jako nieuzasadnione. Ten proces może trwać lata. Na przykład uaktualnienie Taproot było dyskutowane i dopracowywane przez znaczny okres, zanim uznano je za gotowe do aktywacji. Powolność jest cechą, a nie błędem, zapobiegającą pochopnym decyzjom, które mogłyby zdestabilizować sieć finansową.
Dostęp do commitów deweloperów
Powszechnym błędem jest przekonanie, że deweloperzy z „commit access” do repozytorium Bitcoin Core na GitHub kontrolują Bitcoin. Chociaż ci maintainerzy mają możliwość scalania kodu do głównej gałęzi oprogramowania, działają bardziej jak konserwatorzy niż władcy. Ich rolą jest zapewnienie, że scalany kod odzwierciedla rough consensus społeczności.
Gdyby maintainer scalił kod, który fundamentalnie zmienił Bitcoin wbrew woli użytkowników, operatorzy węzłów po prostu odmówiliby aktualizacji do tej wersji. Sieć kontynuowałaby na poprzedniej wersji, a wersja maintainer’a zostałaby zignorowana. Tworzy to potężną kontrolę wpływu deweloperów, zapewniając, że pozostają oni posłuszni pragnieniom sieci węzłów.
Ścieżki aktywacji i implementacji
Gdy uaktualnienie protokołu zostanie zakodowane i scalone do oprogramowania Bitcoin Core, pozostaje uśpione. Musi zostać „zaaktywowane” przez sieć. To faza, w której teoretyczny konsensus spotyka się z fizyczną rzeczywistością blockchaina. Aktywacja wymaga koordynacji wśród ekonomicznych aktorów systemu, głównie górników i operatorów pełnych węzłów.
Sygnalizacja górników i progi
Historycznie aktywacja często wykorzystywała proces zdefiniowany w BIP 9. Polega on na sygnalizowaniu przez górników gotowości do uaktualnienia w nagłówkach bloków, które kopią. Przez określony okres, zwykle dwa tygodnie (2016 bloków), sieć monitoruje, ile bloków zawiera sygnał wsparcia dla uaktualnienia.
Jeśli procent bloków z sygnalizacją osiągnie zdefiniowany próg – często 90% lub 95% – uaktualnienie zostaje zablokowane. Po kolejnym okresie łaski nowe reguły stają się aktywne. Ten mechanizm jest zaprojektowany tak, aby sieć uaktualniała się płynnie, nie pozostawiając górników w tyle. Jednak doprowadził też do politycznych patów, gdzie górnicy skutecznie wetują uaktualnienia, odmawiając sygnalizacji, nawet jeśli szersza baza użytkowników pragnie zmiany.
User Activated Soft Forks
Ograniczenia sygnalizacji górników stały się oczywiste podczas „wojny o rozmiar bloku” przed 2017 rokiem. Gdy górnicy opóźniali aktywację Segregated Witness (SegWit), pojawił się oddolny ruch proponujący User Activated Soft Fork (UASF), znany jako BIP 148.
W UASF operatorzy węzłów uruchamiają oprogramowanie, które odrzuca bloki od górników nie sygnalizujących uaktualnienia po określonej dacie. Przenosi to władzę z górników z powrotem na ekonomiczną większość węzłów. Jeśli aktywność ekonomiczna (giełdy, portfele, użytkownicy) przeniesie się na łańcuch UASF, górnicy będą ekonomicznie motywowani do podążenia za nim lub ryzykują kopanie na bezwartościowym łańcuchu. Zagrożenie BIP 148 było kluczowe w wymuszeniu aktywacji SegWit.
Dynamika fork i kompatybilność
Zmiany w protokole Bitcoin generalnie dzielą się na dwie kategorie: soft forks i hard forks. Różnica tkwi w kompatybilności wstecznej. Zrozumienie tej różnicy jest kluczowe dla pojmowania, dlaczego Bitcoin pozostał pojedynczą, ciągłą siecią pomimo licznych uaktualnień.
Mechanizm soft fork
Soft fork to zmiana protokołu, która ogranicza zbiór ważnych bloków. Zaostrza reguły. Ponieważ nowe reguły są podzbiorem starych reguł, stare węzły, które nie zostały uaktualnione, nadal uznają nowe bloki za ważne. Mogą nie rozumieć nowych funkcji, ale zaakceptują łańcuch.
Ta kompatybilność wsteczna jest kluczowa. Umożliwia stopniowe uaktualnianie sieci. Użytkownicy nie są zmuszeni do natychmiastowej aktualizacji oprogramowania, aby pozostać częścią konsensusu. Większość głównych uaktualnień, w tym SegWit i Taproot, została wdrożona jako soft forks. Zapewnia to, że sieć nie rozdziela się na dwa niekompatybilne łańcuchy tylko dlatego, że niektórzy użytkownicy wolno się uaktualniają.
Dywergencja hard fork
Hard fork luzuje reguły lub wprowadza reguły niekompatybilne ze starym oprogramowaniem. Stare węzły uznają bloki utworzone pod nowymi regułami za nieważne i je odrzucą. Aby hard fork odniósł sukces bez rozszczepienia sieci, 100% użytkowników musi uaktualnić się jednocześnie, co jest niemożliwe w zdecentralizowanym systemie.
W konsekwencji sporny hard fork prawie zawsze prowadzi do trwałego rozszczepienia łańcucha. Najsłynniejszym przykładem jest powstanie Bitcoin Cash (BCH) w 2017 roku. Zwolennicy chcieli zwiększyć limit rozmiaru bloku, co było zmianą reguły niekompatybilną z istniejącym konsensusem Bitcoin. Powstały dwa odrębne sieci i waluty. Hard forks są generalnie unikane w rozwoju Bitcoin ze względu na ryzyko rozbicia sieci i społeczności.
| Atrybut porównawczy | Soft fork | Hard fork |
|---|---|---|
| Kompatybilność | Kompatybilny wstecz | Niekompatybilny wstecz |
| Zmiana reguły | Zaostrza/ogranicza reguły | Luzuje/rozszerza reguły |
| Ryzyko sieci | Niskie ryzyko rozszczepienia łańcucha | Wysokie ryzyko trwałego rozszczepienia |
Główne uaktualnienia protokołu: Segregated Witness
Jednym z najbardziej znaczących przykładów propozycji przechodzącej do implementacji jest Segregated Witness (SegWit). Aktywowany w sierpniu 2017 roku, rozwiązał długotrwałe problemy i przygotował grunt pod przyszłe skalowanie. Propozycja fundamentalnie zmieniła strukturę danych transakcji.
Rozwiązanie malleability
Przed SegWit było możliwe modyfikowanie unikalnego ID transakcji przed jej potwierdzeniem na blockchainie bez unieważnienia podpisu. Ten problem, znany jako transaction malleability, utrudniał budowanie rozwiązań drugiej warstwy, takich jak Lightning Network. Jeśli ID transakcji mogło się zmienić, smart kontrakty zależne od tego ID ulegałyby awarii.
SegWit rozwiązał to, przenosząc dane podpisu (witness) poza część transakcji używaną do obliczania ID. Poprzez segregację witness, ID transakcji stało się niezmienne. To rozwiązanie było kluczowe dla bezpiecznego funkcjonowania kanałów płatniczych, umożliwiając rozwój Lightning Network.
Koncepcja jednostki wagi
SegWit służył też jako sprytne zwiększenie rozmiaru bloku. Zamiast po prostu podnieść limit 1 MB – co wymagałoby hard fork – SegWit zmienił sposób mierzenia bloków. Wprowadził „block weight”.
Dane w sekcji witness liczą się na mniejszą wagę niż dane w głównym bloku transakcji. Umożliwia to blokom przekraczanie tradycyjnego rozmiaru 1 MB pod względem surowych danych (do 4 MB teoretycznie), pozostając kompatybilnymi ze starszymi węzłami sprawdzającymi tylko dane nie-witness. Skutecznie zwiększyło to pojemność sieci i obniżyło opłaty za transakcje używające formatu SegWit.
Uaktualnienie Taproot
Po SegWit następną główną zmianą było Taproot, aktywowane w listopadzie 2021 roku. Taproot połączyło trzy BIPs (340, 341 i 342), aby poprawić prywatność, efektywność i możliwości skryptowania. Przedstawiło bardziej dopracowany proces aktywacji znany jako „Speedy Trial”.
Podpisy Schnorra
W rdzeniu Taproot znajduje się implementacja podpisów Schnorra (BIP 340). Ten schemat podpisu cyfrowego oferuje znaczące zalety nad oryginalnym Elliptic Curve Digital Signature Algorithm (ECDSA). Główną korzyścią jest liniowość.
Liniowość umożliwia agregację podpisów. W transakcji wielopodpisowej wiele kluczy publicznych i podpisów można połączyć w pojedynczy klucz i pojedynczy podpis. Dla blockchaina skomplikowana transakcja z wieloma stronami wygląda identycznie jak standardowa transakcja jednego użytkownika. Poprawia to prywatność, maskując złożoność aranżacji portfeli, i oszczędza miejsce na blockchainie, obniżając opłaty.
Merkelized Abstract Syntax Trees
Taproot wprowadził też Merkelized Abstract Syntax Trees (MAST). Wcześniej, jeśli użytkownik utworzył złożony smart kontrakt z wieloma warunkami wydawania, wszystkie te warunki musiały być ujawnione na blockchainie podczas wydawania środków. Było to nieefektywne i złe dla prywatności.
Dzięki MAST użytkownicy mogą strukturyzować warunki wydawania w formie drzewa. Podczas wydawania muszą ujawnić tylko konkretną gałąź drzewa, która jest używana. Niewykonane gałęzie pozostają ukryte. Umożliwia to skomplikowane smart kontrakty, które są prywatne i efektywne pod względem danych, dalej rozszerzając potencjał Bitcoin poza proste przekazywanie wartości.
Aktualne debaty: Przypadek OP_CAT
Ewolucja Bitcoin trwa, a bieżące dyskusje skupiają się na przywracaniu utraconej funkcjonalności. Jednym z najbardziej prominentnych tematów jest OP_CAT. Jest to konkretny opcode (operation code), który był częścią oryginalnego oprogramowania Bitcoin, ale został wyłączony przez Satoshi Nakamoto w 2010 roku z powodu obaw o zużycie pamięci i luki bezpieczeństwa.
Zrozumienie opcode’ów
Opcode’i to polecenia, które rozumie język skryptowy Bitcoin. Mówią sieci, jak przetwarzać transakcję. Niektóre umożliwiają dodawanie, inne sprawdzają podpisy, a jeszcze inne weryfikują time locki. Gdy opcode’y są wyłączone, zdolność do wykonywania tych konkretnych akcji jest usuwana z narzędziowni sieci.
Usunięcie OP_CAT i innych poważnie ograniczyło język skryptowy Bitcoin. To ograniczenie było celowe w tamtym czasie, priorytetyzując bezpieczeństwo i stabilność nad funkcjonalnością. Jednak wraz z dojrzewaniem zrozumienia protokołu deweloperzy teraz badają bezpieczne ponowne wprowadzenie tych kodów, aby umożliwić nowe funkcje.
Propozycja konkatenacji
OP_CAT konkretnie umożliwia konkatenację (połączenie) dwóch ciągów danych. Brzmi to prosto, ale umożliwia potężną funkcję znaną jako „covenants”. Covenants pozwalają użytkownikom nakładać ograniczenia na sposób wydawania przyszłych bitcoinów, nie tylko na to, kto może je wydać.
Na przykład covenant mógłby wymusić, że konkretny UTXO może być wysłany tylko na konkretną białą listę adresów. Ma to ogromne implikacje dla mechanizmów vault, gdzie użytkownicy mogliby stworzyć „przyciski cofnij” dla skradzionych środków, oraz dla mostkowania Layer 2. Debata wokół OP_CAT ilustruje konserwatywny charakter rozwoju Bitcoin; nawet proste polecenie wymaga lat analizy bezpieczeństwa przed ponownym wprowadzeniem.
Wpływ na rozwiązania Layer 2
Propozycje protokołu często celują w warstwę bazową, ale ich główna użyteczność realizuje się na sieciach Layer 2 (L2). Relacja między głównym blockchainem a tymi wtórnymi warstwami jest symbiotyczna. Ulepszenia protokołu bazowego czynią L2 tańszymi, bezpieczniejszymi i bardziej efektywnymi.
Zależności Lightning Network
Lightning Network to główny przykład tej zależności. Polega na bezpieczeństwie warstwy bazowej do rozliczania transakcji. Jak wspomniano, uaktualnienie SegWit było warunkiem wstępnym dla niezawodnego funkcjonowania Lightning. Przyszłe uaktualnienia nadal celują w efektywność Lightning.
Na przykład propozycje takie jak „Eltoo” (SIGHASH_ANYPREVOUT) mają uprościć zarządzanie kanałami. Poprzez modyfikację sposobu podpisywania transakcji na warstwie bazowej, węzły Lightning mogą przechowywać mniej danych i łatwiej odzyskiwać się z awarii. Pokazuje to, jak propozycje L1 są często napędzane potrzebami skalowalności L2.
Integracja sidechainów
Sidechany, takie jak Liquid czy Rootstock, również korzystają z uaktualnień protokołu. Sidechany to niezależne blockchainy działające równolegle do Bitcoin. Używają dwukierunkowego peg do transferu wartości w obie strony. Obecnie te pegi często polegają na federacjach – grupach zaufanych funkcjonariuszy.
Uaktualnienia takie jak OP_CAT lub nowe schematy podpisów mogłyby umożliwić bardziej trustless mechanizmy mostkowania. Jeśli skrypt Bitcoin może weryfikować dowody z sidechainu (jak Zero-Knowledge proofs), użytkownicy mogliby przenosić środki między łańcuchami bez ufania federacji. To pozostaje głównym obszarem badań i motywacji dla nowych BIP.
Niezamierzona innowacja: Zjawisko Ordinals
Czasem uaktualnienia protokołu prowadzą do całkowicie nieoczekiwanych rezultatów. Wzrost Ordinals jest świadectwem prawa niezamierzonych konsekwencji w oprogramowaniu open-source. Ordinals wykorzystują mechaniki zarówno SegWit, jak i Taproot do inskrypcji danych bezpośrednio na indywidualnych satoshi.
SegWit uczynił przechowywanie danych witness tańszym, a Taproot usunął limit rozmiaru pushy danych w skryptach transakcji. Połączone, te zmiany pozwoliły użytkownikom osadzać obrazy, tekst, a nawet gry wideo bezpośrednio w blockchainie Bitcoin. Nie było to specyficzne zamierzenie deweloperów, którzy pisali te BIPs.
Ten rozwój wywołał zaciekłą debatę w społeczności. Niektórzy postrzegają inskrypcje jako spam zatykający sieć, inni jako legalne użycie przestrzeni blokowej opłacone opłatami. Bez względu na punkt widzenia, Ordinals demonstrują, że raz wdrożona propozycja będzie wykorzystywana przez użytkowników sieci w sposoby, których autorzy mogli nigdy nie przewidzieć.
Podsumowanie
Anatomia propozycji protokołu Bitcoin ujawnia system, który priorytetyzuje przetrwanie ponad wszystko. Od początkowego szkicu BIP po wyczerpujący proces budowania rough consensus, każdy krok jest zaprojektowany do filtrowania ryzyk. Różnica między soft forks a hard forks ilustruje zaangażowanie w kompatybilność wsteczną, zapewniając, że sieć pozostaje inkluzywna nawet podczas postępu.
Uaktualnienia takie jak SegWit i Taproot pokazują, że Bitcoin może innowować bez poświęcania swoich podstawowych zasad. Tymczasem trwające debaty wokół OP_CAT i pojawienie się Ordinals dowodzą, że ekosystem pozostaje żywy i nieprzewidywalny. Wzajemne oddziaływanie między górnikami, deweloperami i operatorami węzłów tworzy system kontroli i równowagi, którego żadna scentralizowana jednostka nie może nadpisać.
Bitcoin zmienia się powoli nie dlatego, że nie może szybko, ale dlatego, że koszt jego zepsucia jest zbyt wysoki, by ryzykować.