Bitcoin jest często opisywany jako cyfrowe pieniądze napędzane kodem. To prawda, ale pomija kluczowy element: kto kontroluje kod? W przeciwieństwie do tradycyjnej korporacji, która działa pod hierarchicznym zarządzaniem, lub rządu, który polega na głosowaniu parlamentarnym, zmiany protokołu Bitcoina są zarządzane przez unikalny, chaotyczny i wysoce zdecentralizowany proces polityczny. Ten system jest zaprojektowany specjalnie po to, aby utrudnić duże zmiany, zapewniając stabilność i przewidywalność waluty w długim terminie.
Zrozumienie zarządzania Bitcoinem jest niezbędne do uchwycenia jego prawdziwej odporności. Wyjaśnia, dlaczego radykalne zmiany, nawet potencjalnie korzystne, zajmują lata w realizacji, wymagając debat rozciągających się na listy mailingowe deweloperów, pule miningowe i domy indywidualnych użytkowników uruchamiających węzły walidacyjne. Ta wysoka tarcie polityczna gospodarka działa jako konstytucyjna ochrona, chroniąc sieć przed pochopnymi decyzjami i złośliwymi aktorami.
Ta analiza zagłębia się w mechanizmy zmian protokołu, badając cykl życia pomysłu — od jego początkowej propozycji jako Bitcoin Improvement Proposal (BIP) po ewentualne przyjęcie za pośrednictwem mechanizmów konsensusu, takich jak Soft Forks. Badamy delikatną równowagę władzy między deweloperami, minerami a użytkownikami uruchamiającymi pełne węzły, ostatecznie ujawniając, dlaczego odporność Bitcoina na zmiany jest jego najpotężniejszą cechą.
Fundament zmian: System Bitcoin Improvement Proposal (BIP)
Ponieważ Bitcoin nie ma scentralizowanej władzy, potrzebował formalnego, publicznego procesu do proponowania, omawiania i dokumentowania zmian protokołu. Ten mechanizm jest znany jako Bitcoin Improvement Proposal, czyli BIP. System BIP zapewnia niezbędną strukturę do zarządzania technicznym konsensusem, przekształcając abstrakcyjne pomysły w formalne propozycje gotowe do kontroli społeczności.
Pomyśl o systemie BIP jako o konstytucyjnej sali redakcyjnej dla Bitcoina. Jest to obowiązkowy punkt startowy dla każdej znaczącej, nietrywialnej zmiany, od drobnych korekt w obliczeniach opłat po rozległe zmiany w sposobie walidacji transakcji.
Anatomia BIP
BIP to uporządkowany dokument opisujący konkretną zmianę, funkcję lub ulepszenie projektu dla Bitcoina. Każde BIP otrzymuje sekwencyjny numer (np. BIP 1, BIP 341) i musi spełniać ścisłe wymagania, aby być uznane za ważne. Te wymagania zapewniają jasność, techniczną solidność i dokładne rozważenie skutków ubocznych.
Istnieją ogólnie trzy typy BIP, choć najbardziej istotne dla zarządzania to BIPs „Standards Track”, które proponują zmiany wpływające na sam protokół (jak format transakcji lub reguły konsensusu). Udane BIP musi jasno określać:
- Motywacja: Dlaczego ta zmiana jest konieczna? Jaki problem rozwiązuje?
- Specyfikacja: Szczegóły techniczne jak zmiana zostanie zaimplementowana w kodzie. Musi być wystarczająco precyzyjna, aby deweloperzy na całym świecie mogli kodować na jej podstawie.
- Kompatybilność wsteczna: Czy ta zmiana przerwie kompatybilność ze starszymi wersjami oprogramowania? (To określa, czy zmiana wymaga Soft Fork czy Hard Fork.)
Istnienie procesu BIP wymusza przejrzystość. Zapewnia, że każda krytyczna techniczna korekta jest poddawana kontroli open-source, często przez setki niezależnych kryptografów i deweloperów, którzy analizują kod pod kątem błędów, skutków ekonomicznych i luk bezpieczeństwa. Ta publiczna faza przeglądu to niezbędna tarcie chroniąca system.
Rola głównych deweloperów i maintainerów
Chociaż każdy może zaproponować BIP, jego rozwój, udoskonalanie i ewentualne scalenie z referencyjną implementacją (Bitcoin Core) nadzoruje mała, oddana grupa znana jako deweloperzy i maintainerzy Bitcoin Core. Ci ludzie nie są oficjalnym organem zarządzającym; raczej są zaufanymi wolontariuszami, których główną funkcją jest przegląd kodu, konserwacja i ocena ryzyka.
Bitcoin Core to podstawowe oprogramowanie, na którym działa większość węzłów i usług infrastrukturalnych, co czyni jego bazę kodu wysoce wpływową. Maintainerzy są odpowiedzialni za ocenę, czy BIP jest technicznie gotowy i czy zdobył wystarczający społeczny konsensus w społeczności deweloperskiej.
Kluczowe jest, że deweloperzy nie mogą wymusić przyjęcia. Piszą oprogramowanie, ale minerzy i, co ważniejsze, użytkownicy muszą dobrowolnie pobrać i uruchomić zaktualizowane oprogramowanie. Jeśli deweloperzy zaimplementowaliby zmianę, której społeczność nienawidzi, użytkownicy po prostu odrzuciliby kod i znaleźliby alternatywne oprogramowanie, skutecznie pozbawiając deweloperów ich wpływu. Ich władza opiera się wyłącznie na zaufaniu, ekspertyzie i technicznej neutralności.
Dlaczego proces BIP to niezbędna tarcie
W szybko rozwijających się scentralizowanych firmach technologicznych zwinność jest kluczowa. Zmiany są wdrażane szybko. W przypadku Bitcoina jest odwrotnie. Proces BIP jest celowo powolny i kontrowersyjny, ponieważ podstawową wartością sieci jest jej niezmienność i przewidywalność.
Gdyby Bitcoin był łatwy do zmiany, straciłby wiarygodność jako niezmienny magazyn wartości. Powolna, wieloletnia dyskusja w procesie BIP działa jako polityczny filtr:
- Weryfikacja wpływu ekonomicznego: Powolne wdrażanie pozwala ekonomistom i analitykom zbadać potencjalne skutki, takie jak zmiany w opłatach transakcyjnych lub激励 dla miningu.
- Zapobieganie centralizacji: Wymagając szerokiego porozumienia między różnymi politycznymi, ekonomicznymi i geograficznymi interesami, proces uniemożliwia jednej potężnej jednostce (jak duża pula miningowa lub scentralizowana giełda) jednostronne dyktowanie polityki.
- Zapewnienie jakości: Czas pozwala na wielokrotny przegląd, testy obciążeniowe i audyty kodu, zmniejszając ryzyko katastrofalnych błędów w protokole rdzenia.
Trudność przejścia BIP to zaleta, a nie wada, zapewniająca, że tylko zmiany z przytłaczającym technicznym i społecznym wsparciem kiedykolwiek idą naprzód.
Dwie ścieżki zmian protokołu: Soft Forks kontra Hard Forks
Gdy BIP zostanie opracowany i omówiony, deweloperzy muszą zdecydować, jak go zaimplementować. Ta strategia implementacji określa poziom koordynacji sieci wymagany i, co kluczowe, potencjalne ryzyko podziału społeczności. Wybór sprowadza się do dwóch głównych typów uaktualnień protokołu: Soft Forks i Hard Forks.
Te forki to nie tylko aktualizacje oprogramowania; reprezentują fundamentalnie różne podejścia do osiągania konsensusu i utrzymywania kompatybilności wstecznej.
Soft Forks: Uaktualnienie zgodne wstecz
Soft Fork to zmiana protokołu Bitcoina, która zaostrza reguły, co oznacza, że nowe reguły są zgodne ze starymi regułami.
Wyobraź sobie uaktualnienie aplikacji tak, że nowa wersja może odczytać wszystkie stare pliki, ale stara wersja niekoniecznie może odczytać wszystkie nowe pliki. W kontekście Bitcoina:
- Nowe reguły: Węzły uruchamiające uaktualnione oprogramowanie (Soft Fork) wymuszają nowy, surowszy zestaw reguł.
- Stare reguły: Węzły uruchamiające stare oprogramowanie (przed uaktualnieniem) nadal akceptują transakcje walidowane przez uaktualnione węzły, ponieważ uaktualnione węzły przestrzegają podzbioru oryginalnych reguł.
Na przykład, jeśli Soft Fork stwierdza, że wszystkie bloki muszą być teraz nieco mniejsze niż wcześniej (zaostrzając regułę), starsze węzły nadal uznają te mniejsze bloki za ważne, ponieważ nadal mieszczą się w oryginalnym limicie maksymalnego rozmiaru.
Soft Forks to preferowana metoda uaktualniania Bitcoina, ponieważ wymagają tylko większości sieci (zazwyczaj minerów reprezentujących 95% mocy haszującej lub większości węzłów) do przyjęcia zmiany. Pozostała mniejszość starszych węzłów może kontynuować działanie bez przerwania łańcucha, choć mogą nie być w stanie w pełni walidować lub korzystać z nowych funkcji. Ta inherentna kompatybilność wsteczna znacznie zmniejsza ryzyko chaotycznego podziału łańcucha.
Hard Forks: Opcja nuklearna
Hard Fork to fundamentalna zmiana protokołu, która czyni nowe reguły niezgodnymi ze starymi regułami. Wymaga od każdego uczestnika — minerów, węzłów i portfeli — uaktualnienia oprogramowania, aby przestrzegać nowego konsensusu.
Jeśli Hard Fork zostanie aktywowany, sieć dosłownie dzieli się na dwa oddzielne łańcuchy:
- Nowy łańcuch: Przestrzega nowego zestawu reguł (np. znacznie większe rozmiary bloków).
- Stary łańcuch: Kontynuuje przestrzeganie oryginalnych reguł.
Węzły, które nie zostały uaktualnione, odrzucą wszelkie bloki utworzone pod nowymi regułami, uważając je za nieważne. Jeśli znacząca grupa będzie kontynuować mining i walidację starego łańcucha, będą istnieć jednocześnie dwie oddzielne wersje Bitcoina.
Hard Forks są wysoce destrukcyjne i niosą ogromne ryzyko ekonomiczne. Ponieważ podział jest trwały, chyba że jeden łańcuch zostanie całkowicie porzucony, społeczność musi być niemal jednomyślna przed próbą Hard Forka. Jeśli udany, użytkownicy starego łańcucha nagle znajdują się z potencjalnie bezwartościowym aktywem, podczas gdy nowy łańcuch staje się dominującą wersją Bitcoina. Zagrożenie ekonomicznym podziałem oznacza, że Hard Forks są zarezerwowane tylko dla krytycznych poprawek lub zmian, gdzie kompatybilność wsteczna jest niemożliwa.
Test zarządzania: Dlaczego Hard Forks budzą strach
Główną funkcją Hard Forka w zarządzaniu Bitcoinem jest służenie jako masywny odstraszacz konfliktów. Potencjał podziału zmusza konkurujące interesy — takie jak minerzy chcący wyższych opłat kontra użytkownicy priorytetyzujący decentralizację — do kompromisu.
Klasycznym przykładem ilustrującym ten strach były debaty skalujące z 2017 roku. Grupa próbowała wymusić Hard Forka (znanego jako SegWit2x), aby znacząco zwiększyć limit rozmiaru bloku. Propozycja ostatecznie upadła, ponieważ społeczność użytkowników i główni deweloperzy odrzucili ryzyko rozbicia marki i płynności Bitcoina. Rynek jasno dał do zrozumienia, że zachowanie zjednoczonej tożsamości Bitcoina jest bardziej wartościowe niż dostosowanie do technicznej zmiany bez przytłaczającego konsensusu.
Ta dynamika pokazuje, że ekonomiczna wartość sieci — połączone zaufanie i płynność — działa jako ostateczne ograniczenie zarządzania. Każda grupa promująca Hard Forka ryzykuje utratę całego wsparcia ekonomicznego, jeśli szersza społeczność zdecyduje się pozostać przy ustalonym, sprawdzonym łańcuchu.
Osiąganie konsensusu: Sygnalizacja, audyt i egzekwowanie
Podczas gdy deweloperzy piszą kod i wybierają typ forka, polityczny akt przyjęcia wymaga złożonego trzyetapowego procesu obejmującego minerów, pełne węzły i mechanizmy oparte na czasie. Ta interakcja sygnalizacji (głosowanie intencji), audytu (sprawdzanie kodu) i egzekwowania (odrzucanie nieważnych bloków) to serce zdecentralizowanego zarządzania.
Kluczowym spostrzeżeniem jest, że władza jest rozproszona: minerzy proponują, ale użytkownicy decydują.
Minerzy kontra węzły: Dwie formy władzy walidacyjnej
W zarządzaniu Bitcoinem kluczowe jest rozróżnienie dwóch typów posiadaczy władzy:
1. Minerzy (moc haszująca)
Minerzy, którzy wykonują algorytm Proof-of-Work (PoW), mają moc tworzenia bloków. Gdy zaproponowany jest Soft Fork, deweloperzy definiują mechanizm, aby minerzy mogli sygnalizować swoje poparcie. Ta sygnalizacja jest zazwyczaj realizowana przez osadzenie konkretnego kawałka danych ("flagi") w nagłówku bloku, który produkują.
Jeśli 95% wszystkich wydobytych bloków w określonym okresie sygnalizuje poparcie dla Soft Forka, zmiana jest uważana za gotową do aktywacji. Sygnalizacja minerów jest ważna, ponieważ to oni egzekwują nowe reguły podczas tworzenia bloków. Jednak sygnalizacja minerów to jedynie intencja przestrzegania, a nie ostateczna władza. Minerzy mogą być naciskani przez bodźce ekonomiczne do sygnalizowania poparcia, nawet jeśli nie lubią zmiany.
2. Pełne węzły (władza egzekwowania)
Pełne węzły to komputery uruchamiające całe oprogramowanie Bitcoin, pobierające i walidujące każdą transakcję i blok od początku sieci. Węzły są głównie uruchamiane przez użytkowników, giełdy, firmy i portfele. Węzły nie sygnalizują poparcia jak minerzy; one egzekwują reguły.
Jeśli minerzy aktywowaliby zmianę, którą większość węzłów uznałaby za nieakceptowalną, węzły po prostu odrzuciłyby bloki utworzone pod nowymi, niechcianymi regułami. Odrzucając te bloki, węzły skutecznie usuwają nagrodę minerów, ponieważ blok jest osierocony, a opłaty transakcyjne tracone.
W istocie minerzy muszą przestrzegać reguł ustalonych przez węzły, ponieważ jeśli węzły odrzucą ich bloki, ich wysiłek miningowy jest ekonomicznie zmarnowany. Pełne węzły działają jako ostateczni audytorzy i strażnicy polityki monetarnej.
Mechanizm aktywacji: Rola sygnalizacji
Aby zarządzać chaotycznym procesem zdecentralizowanej aktywacji, Soft Forks wykorzystują mechanizmy aktywacji zablokowane czasowo, zaprojektowane do zapewnienia odpowiedniego przygotowania sieci.
Powszechne podejście obejmuje wielookresową fazę sygnalizacji, często nazywaną sygnalizacją "Flag Day":
- Początek sygnalizacji: Wydany jest nowy kod, a minerzy zaczynają sygnalizować gotowość za pośrednictwem nagłówków bloków.
- Okres progowy: Sieć obserwuje stałą liczbę bloków (np. 2016 bloków, czyli około dwóch tygodni).
- Aktywacja: Jeśli wymagany próg (np. 95%) tych bloków sygnalizuje gotowość, zaczyna tykać zegar na faktyczne zablokowanie. Kilka tysięcy bloków później (zapewniając okres łaski), nowa reguła aktywuje się na stałe.
Ten mechanizm zapewnia, że zmiana jest wdrażana przewidywalnie i tylko po jasnej, wymiernej demonstracji poparcia z ekonomicznie potężnego sektora miningowego. Ten proces formalizuje polityczny kompromis: deweloperzy piszą kod, minerzy głosują za jego aktywacją, a użytkownicy przygotowują swoje węzły do egzekwowania.
User Activated Soft Forks (UASF): Kiedy użytkownicy przejmują stery
Równowaga władzy została słynnie przetestowana podczas debat wokół Segregated Witness (SegWit), Soft Forka zaprojektowanego do poprawy efektywności transakcji. Gdy minerzy opierali się sygnalizacji aktywacji SegWita, powołując się na obawy ekonomiczne, społeczność musiała udowodnić, że pełne węzły mają ostateczną władzę.
To doprowadziło do koncepcji User Activated Soft Fork (UASF).
UASF to Soft Fork, w którym spust aktywacji opiera się na czasie, a nie sygnalizacji minerów. W UASF węzły (użytkownicy) jednostronnie decydują o przyszłej dacie rozpoczęcia egzekwowania nowej reguły, niezależnie od tego, co sygnalizują minerzy.
Najsłynniejszym przykładem jest BIP 148, który proponował aktywację SegWita w konkretnej dacie. Węzły uruchamiające BIP 148 stwierdziły: „Po dacie X będziemy akceptować tylko bloki sygnalizujące gotowość SegWita.”
Teoria gier tutaj jest krytyczna. Jeśli 51% mocy haszującej odmówi sygnalizacji, ale duża część ekonomicznie istotnych węzłów (giełdy, procesory płatności, główne portfele) uruchamiała oprogramowanie UASF, minerzy stanęliby przed trudnym wyborem:
- Kontynuować mining bloków bez sygnalizacji: Te bloki zostałyby odrzucone przez węzły UASF, prowadząc do strat finansowych.
- Rozpocząć sygnalizację i przyjąć regułę: Zachować dochody z miningu i dostosować się do konsensusu użytkowników.
Zagrożenie UASF skutecznie zmusiło pule miningowe do przyjęcia zmiany, demonstrując, że w zdecentralizowanej politycznej gospodarce Bitcoina preferencje użytkowników i egzekwowanie przez węzły przeważają nad sygnalizacją minerów, gdy dochodzi do konfrontacji. UASF ugruntował zasadę, że uruchamianie pełnego węzła to ostateczna władza weta w ekosystemie Bitcoina.
Studia przypadków w zarządzaniu Bitcoinem: Lekcje wyciągnięte
Badanie udanych i burzliwych wydarzeń zarządzania zapewnia kluczowy kontekst do zrozumienia środowiska wysokiej tarczy zmian protokołu. Te wydarzenia to ekonomiczne bitwy toczone za pomocą kodu, dowodzące, że konsensus jest kosztowny i wymaga znaczącego wysiłku politycznego.
SegWit (BIP 141): Studium tarczy i kompromisu
Segregated Witness, czyli SegWit, był być może najbardziej zacięcie kwestionowanym Soft Forkiem w historii Bitcoina. Zaproponowany w 2015 i ostatecznie aktywowany w 2017, dwuletnia debata podkreśla ogromną trudność wprowadzania nietrywialnych zmian.
Konflikt: SegWit został zaprojektowany do naprawy plastyczności transakcji i pośredniego zwiększenia pojemności transakcji. Jednak wiele dużych interesów miningowych sprzeciwiało się mu, preferując prosty Hard Fork zwiększający rozmiar bloku (propozycja SegWit2x). Konflikt był fundamentalnie polityczny: scentralizowane interesy miningowe kontra zdecentralizowane interesy deweloperów i użytkowników.
Rozwiązanie: Rozwiązanie obejmowało trzy równoległe strategie zarządzania:
- Konsensus deweloperów (wybór Soft Forka): Deweloperzy nalegali na Soft Forka (BIP 141), aby uniknąć ryzyka podziału łańcucha.
- Konsensus ekonomiczny (New York Agreement): Próba kompromisu, głównie z scentralizowanymi firmami (SegWit2x), ostatecznie upadła z powodu braku przyjęcia przez użytkowników.
- Władza użytkowników (UASF/BIP 148): Zagrożenie UASF było decydującym czynnikiem. Sygnalizując gotowość użytkowników do odrzucania niekompatybilnych bloków, użytkownicy udowodnili, że mają ostateczną władzę nad regułami sieci.
Sukces SegWita udowodnił, że chociaż minerzy mogą spowalniać aktywację, nie mogą jednostronnie blokować zmiany z przytłaczającym technicznym i wsparciem użytkowników, zwłaszcza gdy krytyczna infrastruktura zależy od uaktualnienia.
Taproot (BIPs 340, 341, 342): Cichy sukces Speedy Trial
Na kontrast z burzliwą aktywacją SegWita, Taproot — główne uaktualnienie aktywowane w 2021 — zapewnił znaczące ulepszenia prywatności, efektywności i możliwości smart kontraktów. Dzięki lekcjom z SegWita proces zarządzania dla Taproot został uproszczony za pomocą nowej metody aktywacji: Speedy Trial.
Mechanizm Speedy Trial: Zamiast typowego zablokowania o stałym czasie, Speedy Trial ustalił próg sygnalizacji 90% w ciągu dwóch tygodni, ale zawierał też datę wygaśnięcia.
- Jeśli 90% minerów sygnalizowało poparcie w oknie, zmiana blokowała się szybko (sukces Speedy Trial).
- Jeśli próg nie został osiągnięty, proces kończył się niepowodzeniem, zmuszając społeczność do powrotu do deski kreślarskiej — potencjalnie rozważając kontrowersyjne podejście UASF później.
To strukturalne, ograniczone czasowo podejście wywierało presję na minerów, aby szybko osiągnąć konsensus, wiedząc, że brak sygnalizacji zmusi do powrotu do trudnych negocjacji zarządzania. Taproot osiągnął próg sygnalizacji 90% stosunkowo szybko, demonstrując, że gdy zmiana jest technicznie solidna, niekontrowersyjna i dobrze wspierana przez deweloperów, sieć może uaktualnić się efektywnie.
Taproot udowodnił, że zarządzanie Bitcoinem ewoluuje. Chociaż nadal chaotyczne, społeczność nauczyła się strukturyzować bodźce polityczne, aby zachęcać do terminowej aktywacji, jednocześnie utrzymując wymóg wysokiego progu konsensusu.
Sedno decentralizacji: Dlaczego zarządzanie musi być chaotyczne
Ustaliliśmy, że zarządzanie Bitcoinem nie jest gładkie ani efektywne. Jest często powolne, bolesne i wysoce kontrowersyjne. Ta nieefektywność jest, paradoksalnie, źródłem jego siły i atrakcyjności jako twardego aktywa pieniężnego. Odporność na zmiany zapewnia integralność podstawowej propozycji wartości: niezawodna, przewidywalna i ograniczona emisja.
Model zarządzania o wysokiej tarczy zapewnia, że Bitcoin pozostaje politycznie zdecentralizowany, niezdolny do sterowania przez jedną potężną korporację lub rząd.
Koszt zmian kontra wartość przewidywalności
W świecie finansów nieprzewidywalność równa się ryzyku. Propozycja wartości Bitcoina opiera się na jego zakodowanej polityce monetarnej — limicie podaży 21 milionów monet. Gdyby reguły protokołu były łatwe do zmiany, obietnica tego stałego limitu zostałaby podważona.
Proces zarządzania wymaga, aby potencjalne zmiany pokonały ogromną przeszkodę w postaci weryfikacji społecznej, technicznej i ekonomicznej. Ten „koszt zmiany” gwarantuje:
- Integralność polityki monetarnej: Niemal niemożliwe jest zmiana limitu 21 milionów lub harmonogramu emisji bez spowodowania katastrofalnego podziału łańcucha, który zniszczyłby ekonomiczną wartość monety.
- Przewidywalność: Firmy, giełdy i inwestorzy instytucjonalni mogą lokować kapitał w ekosystemie Bitcoina, wiedząc, że fundamentalne reguły nie zmienią się niespodziewanie.
- Brak zaufania: Użytkownicy nie muszą ufać CEO czy radzie nadzorczej w utrzymaniu reguł; ufają politycznej bezwładności i ekonomicznym odstraszaczom osadzonym w modelu zarządzania.
Nieefektywność zarządzania to cena płacona za osiągnięcie monetarycznej finalności i zdecentralizowanego zaufania.
Teoria gier przestrzegania protokołu
Bezpieczeństwo zarządzania Bitcoinem ostatecznie opiera się na teorii gier — badaniu strategicznego podejmowania decyzji wśród konkurujących podmiotów.
Każdy uczestnik sieci Bitcoin (minerzy, deweloperzy i użytkownicy) ma odrębny bodziec:
- Deweloperzy: Motywowani do proponowania wysokiej jakości, bezpiecznego kodu, który zachowuje reputację sieci.
- Minerzy: Motywowani do maksymalizacji zysku, co oznacza, że muszą wybrać łańcuch, który zaakceptuje większość użytkowników (węzłów), zapewniając nagrody za wydobyte bloki.
- Użytkownicy (węzły): Motywowani do utrzymania reguł, na które początkowo się zapisali, zachowując integralność swojej inwestycji.
To tworzy Równowagę Nasha, w której optymalną strategią dla każdej strony jest przestrzeganie reguł egzekwowanych przez pełne węzły. Jeśli jakakolwiek potężna jednostka spróbuje złamać konsensus (np. pula miningowa próbująca forsować kontrowersyjnego Hard Forka), ekonomiczna kara (fork łańcucha i zniszczenie płynności) jest tak surowa, że przewyższa wszelkie potencjalne krótkoterminowe zyski techniczne.
Dlatego chaotyczny proces zarządzania Bitcoinem, charakteryzujący się BIP-ami, kontrowersyjnymi debatami i stale obecnym zagrożeniem User Activated Soft Forks, nie jest porażką projektu. To udana implementacja kryptoeconomicznego bezpieczeństwa, zapewniająca utrzymanie politycznej decentralizacji obok decentralizacji technicznej. Kod napędza pieniądze, ale konsensus napędza kod.