Mechanizmy správy Bitcoinu: Soft Forks, BIPy a konsenzus vývojárov

Bitcoin sa často opisuje ako digitálne peniaze riadené kódom. To je pravda, ale vynecháva kľúčový prvok: kto ovláda kód? Na rozdiel od tradičnej spoločnosti, ktorá funguje na hierarchickom manažmente, alebo vlády, ktorá sa spolieha na parlamentné hlasovanie, zmeny protokolu Bitcoinu riadi jedinečný, chaotický a vysoko decentralizovaný politický proces. Tento systém je navrhnutý špeciálne tak, aby robil veľké zmeny obtiažnymi, čím zabezpečuje stabilitu a predvídateľnosť meny na dlhodobé obdobie.

Pochopenie správy Bitcoinu je nevyhnutné na pochopenie jeho skutočnej odolnosti. Vysvetľuje, prečo radikálne zmeny, dokonca aj tie potenciálne prospešné, trvajú roky na implementáciu a vyžadujú debaty, ktoré sa tiahnu cez mailingové zoznamy vývojárov, miningové pooly a domácnosti jednotlivých používateľov spúšťajúcich validačné uzly. Táto vysoká frikcia v politickej ekonomike funguje ako ústavná ochrana, chrániaca sieť pred unáhlenými rozhodnutiami a zlomyseľnými aktérmi.

Táto analýza sa ponára hlboko do mechanizmov zmeny protokolu, skúma životný cyklus nápadu – od jeho počiatočného návrhu ako Bitcoin Improvement Proposal (BIP) až po jeho prípadné prijatie prostredníctvom mechanizmov konsenzu ako Soft Forks. Preskúmame krehkú rovnováhu moci medzi vývojármi, baníkmi a používateľmi, ktorí spúšťajú plné uzly, a nakoniec odhalíme, prečo je odolnosť Bitcoinu voči zmenám jeho najsilnejšou vlastnosťou.


Základ zmien: Systém Bitcoin Improvement Proposal (BIP)

Keďže Bitcoin nemá centralizovanú autoritu, potreboval formálny, verejný proces na navrhovanie, diskusiu a dokumentáciu zmien protokolu. Tento mechanizmus je známy ako Bitcoin Improvement Proposal, alebo BIP. Systém BIP poskytuje potrebnú štruktúru na riadenie technického konsenzu, premieňa abstraktné nápady na formálne návrhy pripravené na kontrolu komunity.

Považujte systém BIP za ústavnú návrhovú miestnosť pre Bitcoin. Je to povinný štartovací bod pre akúkoľvek významnú netriviálnu zmenu, od miernych úprav výpočtu poplatkov až po rozsiahle zmeny v tom, ako sa transakcie validujú.

Anatómia BIP

BIP je štruktúrovaný dokument, ktorý popisuje špecifickú zmenu, funkciu alebo dizajnové zlepšenie pre Bitcoin. Každý BIP dostane sekvenčné číslo (napr. BIP 1, BIP 341) a musí spĺňať prísne požiadavky, aby bol považovaný za platný. Tieto požiadavky zabezpečujú jasnosť, technickú spoľahlivosť a dôkladné zváženie vedľajších efektov.

Existujú všeobecne tri typy BIPov, hoci najrelevantnejšie pre správu sú BIPy „Standards Track“, ktoré navrhujú zmeny ovplyvňujúce samotný protokol (ako formát transakcií alebo konsenzuálne pravidlá). Úspešný BIP musí jasne definovať:

  1. Motivácia: Prečo je táto zmena potrebná? Aký problém rieši?
  2. Špecifikácia: Technické detaily ako sa zmena implementuje v kóde. Musí byť dostatočne presná, aby ju mohli globálni vývojári kodovať.
  3. Spätná kompatibilita: Zlomí táto zmena kompatibilitu so staršími verziami softvéru? (To určuje, či zmena vyžaduje Soft Fork alebo Hard Fork.)

Existencia procesu BIP vynucuje transparentnosť. Zabezpečuje, že každá kritická technická úprava podlieha kontrole open-source, často stovkami nezávislých kryptografov a vývojárov, ktorí analyzujú kód na chyby, ekonomické vedľajšie efekty a bezpečnostné zraniteľnosti. Táto fáza verejnej kontroly je esenciálnou frikciou, ktorá chráni systém.

Úloha jadrových vývojárov a maintainerov

Hoci ktokoľvek môže navrhnúť BIP, jeho vývoj, doladenie a prípadné zlúčenie do referenčnej implementácie (Bitcoin Core) dohliadajú malá, oddaná skupina známa ako vývojári a maintaineri Bitcoin Core. Títo jedinci nie sú oficiálnym vládnucom orgánom; sú to dôveryhodní dobrovoľníci, ktorých primárnou funkciou je kontrola kódu, údržba a posúdenie rizík.

Bitcoin Core je základný softvér, na ktorom beží väčšina uzlov a infraštruktúrnych služieb, čo robí jeho kódovú základňu vysoko vplyvnou. Maintaineri sú zodpovední za posúdenie, či je BIP technicky pripravený a či získal dostatočný sociálny konsenzus v komunite vývojárov.

Kľúčové je, že vývojári nemôžu vynútiť prijatie. Napíšu softvér, ale baníci a dôležitejší používatelia ho musia dobrovoľne stiahnuť a spustiť. Ak by vývojári implementovali zmenu, ktorú komunita nenávidí, používatelia jednoducho odmietnu kód a nájdu alternatívny softvér, čím efektívne zbavia vývojárov ich vplyvu. Ich moc spočíva výlučne na dôvere, expertíze a technickej neutralite.

Prečo je proces BIP potrebnou frikciou

Vo rýchlo sa meniacich centralizovaných technologických spoločnostiach je priorita agilita. Zmeny sa tlačia rýchlo. Pre Bitcoin je opak pravdou. Proces BIP je zámerne pomalý a hádavý, pretože primárnou hodnotou siete je jej nemennosť a predvídateľnosť.

Ak by bol Bitcoin ľahko zmeniteľný, stratil by svoju dôveryhodnosť ako nemenné úložisko hodnoty. Pomalá, viacročná diskusia inherentná v procese BIP funguje ako politický filter:

  • Overovanie ekonomického dopadu: Pomalé zavádzanie umožňuje ekonómom a analytikom študovať potenciálne dopady, ako zmeny poplatkov za transakcie alebo stimuly pre mining.
  • Zabránenie centralizácii: Vyžadovaním širokej dohody naprieč rôznymi politickými, ekonomickými a geografickými záujmami proces bráni tomu, aby nejaká jediná mocná entita (ako masívny mining pool alebo centralizovaná burza) unilaterálne diktovala politiku.
  • Zabezpečenie kvality: Čas umožňuje opakované kontroly kódu, stresové testy a audity, čím sa znižuje riziko katastrofálnych chýb v jadrovom protokole.

Obtiažnosť schválenia BIP je funkciou, nie chybou, zabezpečujúc, že len zmeny s ohromujúcou technickou a sociálnou podporou idú dopredu.


Dve cesty zmeny protokolu: Soft Forks vs. Hard Forks

Akonáhle je BIP navrhnutý a diskutovaný, vývojári musia rozhodnúť, ako ho implementovať. Táto implementačná stratégia definuje úroveň potrebnej koordinácie siete a kriticky riziko rozdelenia komunity. Táto voľba sa zužuje na dva hlavné typy aktualizácií protokolu: Soft Forks a Hard Forks.

Tieto forky nie sú len aktualizácie softvéru; predstavujú zásadne odlišné prístupy k dosiahnutiu konsenzu a udržaniu spätnej kompatibility.

Soft Forks: Aktualizácia s spätnou kompatibilitou

Soft Fork je zmena protokolu Bitcoinu, ktorá sprísňuje pravidlá, čo znamená, že nové pravidlá sú kompatibilné so starými pravidlami.

Predstavte si aktualizáciu softvérovej aplikácie tak, že nová verzia dokáže čítať všetky staré súbory, ale stará verzia nemusí čítať všetky nové súbory. V kontexte Bitcoinu:

  • Nové pravidlá: Uzly spúšťajúce aktualizovaný softvér (Soft Fork) vynucujú novú, prísnejšiu sadu pravidiel.
  • Staré pravidlá: Uzly spúšťajúce starý softvér (pred aktualizáciou) stále akceptujú transakcie validované aktualizovanými uzlami, pretože aktualizované uzly dodržiavajú podmnožinu pôvodných pravidiel.

Napríklad, ak Soft Fork stanoví, že všetky bloky musia byť teraz o niečo menšie ako predtým (sprísnenie pravidla), staršie uzly budú stále považovať tieto menšie bloky za platné, pretože stále dodržiavajú pôvodný maximálny limit veľkosti.

Soft Forks sú preferovanou metódou aktualizácie Bitcoinu, pretože vyžadujú len väčšinu siete (typicky baníkov reprezentujúcich 95 % hashovacej sily alebo väčšinu uzlov) na prijatie zmeny. Zostávajúca menšina starších uzlov môže pokračovať v prevádzke bez rozbitia reťazca, hoci nemusia plne validovať alebo používať nové funkcie. Táto inherentná spätná kompatibilita výrazne znižuje riziko chaotického rozdelenia reťazca.

Hard Forks: Jadrová možnosť

Hard Fork je zásadná zmena protokolu, ktorá robí nové pravidlá nekompatibilné so starými pravidlami. Vyžaduje, aby každý účastník – baníci, uzly a peňaženky – aktualizoval svoj softvér na nasledovanie nového konsenzu.

Ak sa Hard Fork aktivuje, sieť sa doslova rozdelí na dva oddelené reťazce:

  1. Nový reťazec: Dodržiava novú sadu pravidiel (napr. výrazne väčšie bloky).
  2. Starý reťazec: Pokračuje v dodržiavaní pôvodných pravidiel.

Uzly, ktoré neboli aktualizované, odmietnu akékoľvek bloky vytvorené podľa nových pravidiel, považujúc ich za neplatné. Ak významná skupina pokračuje v minení a validácii starého reťazca, budú existovať dve oddelené verzie Bitcoinu súčasne.

Hard Forks sú vysoko narúšajúce a nesú obrovské ekonomické riziko. Pretože rozdelenie je trvalé, pokiaľ sa jeden reťazec úplne neopustí, musí byť komunita takmer jednomyseľná pred pokusom o Hard Fork. Ak je úspešný, používatelia na starom reťazci sa náhle ocitnú s potenciálne bezcenným aktívom, zatiaľ čo nový reťazec sa stane dominantnou verziou Bitcoinu. Hrozba ekonomického rozdelenia znamená, že Hard Forks sa rezervujú len na kritické opravy alebo zmeny, kde spätná kompatibilita nie je možná.

Test správy: Prečo sa Hard Forks obávajú

Primárnou funkciou Hard Forku v správe Bitcoinu je slúžiť ako masívny odstrašovač proti konfliktom. Potenciál rozdelenia núti konkurenčné záujmy – ako baníkov, ktorí chcú vyššie poplatky, verzus používateľov, ktorí uprednostňujú decentralizáciu – k kompromisu.

Klasický príklad ilustrujúci tento strach sa odohral počas debát o škálovaní v roku 2017. Skupina sa pokúsila vynútiť Hard Fork (známy ako SegWit2x) na výrazné zvýšenie limitu veľkosti bloku. Návrh nakoniec zlyhal, pretože používateľská komunita a jadroví vývojári odmietli riziko rozbitia značky a likvidity Bitcoinu. Trh jasne ukázal, že zachovanie jednotnej identity Bitcoinu je hodnotnejšie ako ubytovanie technickej zmeny, ktorá nemala ohromujúci konsenzus.

Táto dynamika demonštruje, že ekonomická hodnota siete – kombinovaná dôvera a likvidita – funguje ako ultimátne obmedzenie správy. Akákoľvek skupina tlačiaci Hard Fork riskuje stratu celej ekonomickej podpory, ak sa širšia komunita rozhodne držať sa etablovaného, overeného reťazca.


Dosažovanie konsenzu: Signalizácia, audit a vynucovanie

Zatiaľ čo vývojári navrhujú kód a vyberajú typ forku, politický akt prijatia vyžaduje komplexný trojstupňový proces zahŕňajúci baníkov, plné uzly a mechanizmy založené na čase. Táto interakcia signalizácie (hlasovanie o úmysle), auditu (kontrola kódu) a vynucovania (odmietanie neplatných blokov) je srdcom decentralizovanej správy.

Kľúčovým poznatkom je, že moc je rozdelená: baníci navrhujú, ale používatelia disponujú.

Baníci vs. uzly: Dve formy validačnej moci

V správe Bitcoinu je kritické rozlíšiť medzi dvoma typmi nositeľov moci:

1. Baníci (Hashovacia sila)

Baníci, ktorí vykonávajú algoritmus Proof-of-Work (PoW), majú moc vytvárať bloky. Keď sa navrhne Soft Fork, vývojári definujú mechanizmus, aby baníci signalizovali svoju podporu. Táto signalizácia sa typicky robí vložením špecifických dát („vlajky“) do hlavičky bloku, ktorú produkujú.

Ak 95 % všetkých vyťažených blokov v definovanom období signalizuje podporu Soft Forku, zmena sa považuje za pripravenú na aktiváciu. Signalizácia baníkov je dôležitá, pretože oni vynucujú nové pravidlá pri vytváraní blokov. Avšak signalizácia baníkov je len úmyslom dodržať, nie konečnou autoritou. Baníci môžu byť tlačení ekonomickými incentivmi na signalizáciu podpory, aj keď zmenu nemusia mať radi.

2. Plné uzly (Moc vynucovania)

Plné uzly sú počítače spúšťajúce celý softvér Bitcoinu, sťahujúce a validujúce každú transakciu a blok od začiatku siete. Uzly primárne spúšťajú používatelia, burzy, firmy a peňaženky. Uzly nesignalizujú podporu ako baníci; oni vynucujú pravidlá.

Ak by baníci aktivovali zmenu, ktorú väčšina uzlov považuje za neprijateľnú, uzly jednoducho odmietnu akékoľvek bloky vytvorené podľa nových, neželaných pravidiel. Odmietnutím týchto blokov uzly efektívne odstránia odmenu baníkov, pretože blok je osirelý a poplatky za transakcie sú stratené.

V podstate baníci musia dodržiavať pravidlá stanovené uzlami, pretože ak uzly odmietnu ich bloky, ich miningové úsilie je ekonomicky vyhodené. Plné uzly fungujú ako ultimátni audítori a strážcovia menovej politiky.

Mechanizmus aktivácie: Úloha signalizácie

Na riadenie chaotického procesu decentralizovanej aktivácie Soft Forks využívajú mechanizmy aktivácie zamknuté na čas, navrhnuté na zabezpečenie adekvátnej pripravenosti siete.

Bežný prístup zahŕňa viacobdobovú signalizačnú fázu, často nazývanú „Flag Day“ signalizácia:

  1. Začiatok signalizácie: Nový kód je vydaný a baníci začínajú signalizovať svoju pripravenosť cez hlavičky blokov.
  2. Obdobie prahu: Sieť sleduje fixný počet blokov (napr. 2 016 blokov, približne dva týždne).
  3. Aktivácia: Ak požadovaný prah (napr. 95 %) tých blokov signalizuje pripravenosť, spustí sa hodina pre skutočné zamknutie. O niekoľko tisíc blokov neskôr (poskytujúc lehotu), sa nové pravidlo natrvalo aktivuje.

Tento mechanizmus zabezpečuje, že zmena sa nasadí predvídateľne a len po jasnej, meranej demonštrácii podpory z ekonomicky mocného miningového sektora. Tento proces formalizuje politický kompromis: vývojári píšu kód, baníci hlasujú za jeho aktiváciu a používatelia pripravujú svoje uzly na vynucovanie.

User Activated Soft Forks (UASF): Keď používatelia prevezmú kormidlo

Rovnováha moci bola slávne otestovaná počas debát okolo Segregated Witness (SegWit), Soft Forku navrhnutého na zlepšenie efektivity transakcií. Keď baníci odolávali signalizácii pre aktiváciu SegWitu z ekonomických dôvodov, komunita musela dokázať, že plné uzly majú ultimátnu moc.

To viedlo k konceptu User Activated Soft Fork (UASF).

UASF je Soft Fork, kde je spúšťač aktivácie založený na čase, nie na signalizácii baníkov. V UASF uzly (používatelia) unilaterálne rozhodnú o budúcom dátume na začatie vynucovania nového pravidla, bez ohľadu na to, čo signalizujú baníci.

Najznámejším príkladom je BIP 148, ktorý navrhoval aktivovať SegWit k špecifickému dátumu. Uzly spúšťajúce BIP 148 vyhlásili: „Po dátume X budeme akceptovať len bloky, ktoré signalizujú pripravenosť na SegWit.“

Teória hier tu je kritická. Ak 51 % hashovacej sily odmietne signalizovať, ale veľká časť ekonomicky relevantných uzlov (burzy, spracovatelia platieb, hlavné peňaženky) spúšťala UASF softvér, baníci čelia ťažkej voľbe:

  1. Pokračovať v minení blokov bez signalizácie: Tieto bloky by boli odmietnuté UASF uzlami, čo vedie k finančným stratám.
  2. Začať signalizovať a prijať pravidlo: Zachovať svoj miningový príjem a zladiť sa s konsenzom používateľov.

Hrozba UASF úspešne prinútila miningové pooly prijať zmenu, demonštrujúc, že v decentralizovanej politickej ekonomike Bitcoinu preferencie používateľov a vynucovanie uzlami prevážia signalizáciu baníkov, keď dôjde k tlaku. UASF upevnila princíp, že spúšťanie plného uzla je konečná veta v ekosystéme Bitcoinu.


Prípadové štúdie v správe Bitcoinu: Poučené lekcie

Skúmanie úspešných a búrlivých udalostí správy poskytuje kľúčový kontext na pochopenie prostredia vysokej frikcie pri zmene protokolu. Tieto udalosti sú ekonomické bitky vedené cez kód, dokazujúce, že konsenzus je nákladný a vyžaduje významné politické úsilie.

SegWit (BIP 141): Štúdia frikcie a kompromisu

Segregated Witness, alebo SegWit, bol pravdepodobne najviac sporný Soft Fork v histórii Bitcoinu. Navrhnutý v roku 2015 a nakoniec aktivovaný v roku 2017, dvojročná debata zdôrazňuje obrovskú obtiažnosť uskutočnenia netriviálnych zmien.

Konflikt: SegWit bol navrhnutý na opravu malleability transakcií a nepriame zvýšenie kapacity transakcií. Mnohé veľké miningové záujmy mu však odporovali, preferujúc priamočiaru Hard Fork zvýšenie veľkosti bloku (návrh SegWit2x). Konflikt bol zásadne politický: centralizované miningové záujmy verzus decentralizované záujmy vývojárov a používateľov.

Riešenie: Riešenie zahŕňalo tri paralelné stratégie správy:

  1. Konsenzus vývojárov (Voľba Soft Forku): Vývojári trvali na Soft Forku (BIP 141), aby sa vyhli riziku rozdelenia reťazca.
  2. Ekonomický konsenzus (New York Agreement): Kompromis, primárne s centralizovanými firmami, bol pokusaný (SegWit2x), ale nakoniec zlyhal, pretože mu chýbalo prijatie používateľmi.
  3. Moc používateľov (UASF/BIP 148): Hrozba UASF bola rozhodujúca. Signalizáciou ochoty používateľov odmietnuť nekompatibilné bloky používatelia demonštrovali, že majú ultimátnu moc nad pravidlami siete.

Úspech SegWitu dokázal, že hoci baníci môžu aktiváciu spomaliť, nemôžu unilaterálne zablokovať zmenu, ktorá má ohromujúcu technickú a používateľskú podporu, najmä keď na aktualizácii závisí kritická infraštruktúra.

Taproot (BIPy 340, 341, 342): Tichý úspech Speedy Trial

Porovnajte búrlivú aktiváciu SegWitu s Taprootom, veľkou aktualizáciou aktivovanou v roku 2021. Taproot poskytol významné zlepšenia v súkromí, efektivite a schopnostiach smart kontraktov. Vďaka lekciám z SegWitu bol proces správy pre Taproot zefektívnený pomocou novej metódy aktivácie: Speedy Trial.

Mechanizmus Speedy Trial: Namiesto typického fixného časového zamknutia Speedy Trial nastavil 90 % signalizačný prah počas dvojtýždňového obdobia, ale zahŕňal aj dátum expirácie.

  • Ak 90 % baníkov signalizovalo podporu v okne, zmena sa rýchlo zamkne (úspech Speedy Trial).
  • Ak prah nebol dosiahnutý, proces zlyhá, nútiac komunitu vrátiť sa k návrhovej doske – potenciálne zvažujúc kontroverzný UASF prístup neskôr.

Tento štruktúrovaný, časovo obmedzený prístup vyvinul tlak na baníkov na rýchle dosiahnutie konsenzu, s vedomím, že zlyhanie signalizácie by prinútilo návrat k ťažkým rokovaniam o správe. Taproot dosiahol 90 % signalizačný prah relatívne rýchlo, demonštrujúc, že keď je zmena technicky spoľahlivá, nekonfliktná a dobre podporovaná vývojármi, sieť sa môže efektívne aktualizovať.

Taproot dokázal, že správa Bitcoinu sa vyvíja. Hoci stále chaotická, komunita sa naučila štruktúrovať politické incentívy na podporu včasnej aktivácie, pričom stále udržiava požiadavku na konsenzus s vysokým prahom.


Jadro decentralizácie: Prečo musí byť správa chaotická

Ustanovili sme, že správa Bitcoinu nie je elegantná ani efektívna. Je často pomalá, mučivá a vysoko hádavá. Táto neefektivita je paradoxne zdrojom jej sily a príťažlivosti ako aktíva tvrdej meny. Odolnosť voči zmenám zabezpečuje integritu jadra hodnotovej ponuky: spoľahlivé, predvídateľné a konečné vydávanie.

Model správy s vysokou frikciou zabezpečuje, že Bitcoin zostane politicky decentralizovaný, neschopný byť riadený jedinou mocnou korporátnou entitou alebo vládou.

Cena zmeny verzus hodnota predvídateľnosti

Vo svete financií sa nepredvídateľnosť rovná riziku. Hodnotová ponuka Bitcoinu je založená na jeho hard-kódovanej menovej politike – limite zásob 21 miliónov mincí. Ak by boli pravidlá protokolu ľahko zmeniteľné, sľub tohto fixného limitu by bol podkopaný.

Proces správy vyžaduje, aby potenciálne zmeny prekonali masívnu prekážku sociálneho, technického a ekonomického overovania. Táto „cena zmeny“ garantuje:

  • Integrita menovej politiky: Je takmer nemožné zmeniť limit 21 miliónov alebo harmonogram vydávania bez spôsobení katastrofického rozdelenia reťazca, ktoré by zničilo ekonomickú hodnotu mince.
  • Predvídateľnosť: Firmy, burzy a inštitucionálni investori môžu investovať kapitál do ekosystému Bitcoinu s vedomím, že základné pravidlá sa neočakávane nezmenia.
  • Bez dôvery: Používatelia nemusia dôverovať CEO alebo predstavenstvu pri udržiavaní pravidiel; dôverujú politickej inertii a ekonomickým odstrašovačom zabudovaným do modelu správy.

Neefektivita správy je cenou za dosiahnutie menovej konečnosti a decentralizovanej dôvery.

Teória hier pri dodržiavaní protokolu

Bezpečnosť správy Bitcoinu nakoniec spočíva na teórii hier – štúdiu strategického rozhodovania medzi konkurenčnými entitami.

Každý účastník siete Bitcoin (baníci, vývojári a používatelia) má odlišný incentiv:

  • Vývojári: Incentivizovaní navrhovať kvalitný, bezpečný kód, ktorý zachováva reputáciu siete.
  • Baníci: Incentivizovaní maximalizovať zisk, čo znamená, že musia vybrať reťazec, ktorý akceptuje väčšina používateľov (uzlov), čím zabezpečia odmeny za ich vyťažené bloky.
  • Používatelia (Uzly): Incentivizovaní udržiavať pravidlá, na ktoré sa prihlásili, zachovávajúc integritu svojej investície.

To vytvára Nashovu rovnováhu, kde optimálnou stratégiou pre každú stranu je dodržiavať pravidlá vynucované plnými uzlami. Ak sa nejaká mocná entita pokúsi prelomiť konsenzus (napr. mining pool tlačiaci kontroverzný Hard Fork), ekonomický trest (forkovanie reťazca a zničenie likvidity) je taký ťažký, že preváži akýkoľvek potenciálny krátkodobý technický zisk.

Preto chaotický proces správy Bitcoinu, charakterizovaný BIPmi, kontroverznými debatami a stále prítomnou hrozbou User Activated Soft Forks, nie je zlyhaním dizajnu. Je to úspešná implementácia kryptoeconomickej bezpečnosti, zabezpečujúca, že politická decentralizácia sa udržiava popri technickej decentralizácii. Kód riadi peniaze, ale konsenzus riadi kód.