Bitcoin sa často opisuje ako digitálne zlato, čo naznačuje statickú a nemennú povahu. Avšak softvér, ktorý poháňa sieť Bitcoin, je živý protokol, ktorý podstupuje údržbu, opravy chýb a upgrady. Na rozdiel od centralizovaného vývoja softvéru, kde generálny riaditeľ spoločnosti alebo produktový manažér diktuje funkcie, sa Bitcoin spolieha na decentralizovanú sieť účastníkov, ktorí sa dohodnú na zmenách. Tento proces je zámerný, pomalý a silne naklonený k zachovaniu status quo, aby zabezpečil bezpečnosť miliárd dolárov v hodnote.
Evolúcia protokolu nie je riadená formálnym hlasovacím systémom ani jedinou autoritou. Namiesto toho funguje prostredníctvom jedinečnej kombinácie technickej dokumentácie, recenzie od rovesníkov a konsenzu komunity. Pochopenie toho, ako sa nápad posunie od jednoduchého rozhovoru na mailing liste po globálne aktivovanú zmenu kódu, odhaľuje odolnosť siete Bitcoin. Zdôrazňuje systém navrhnutý tak, aby odolal ovládnutiu zo strany akejkoľvek jedinej skupiny, či už ide o vývojárov, baníkov alebo korporátne záujmy.
V srdci tohto evolučného procesu je Bitcoin Improvement Proposal, alebo BIP. Ide o primárny mechanizmus na navrhovanie nových funkcií, zbieranie vstupov od komunity k problému a dokumentovanie rozhodnutí o dizajne. BIP nie je záväzné hlasovanie, ale skôr technický dokument o dizajne. Poskytuje informácie Bitcoin komunite alebo popisuje novú funkciu pre Bitcoin alebo jeho procesy.
Rámec Bitcoin Improvement Proposal
Ak chcete pochopiť, ako sa Bitcoin mení, musíte najprv pochopiť proces štandardizácie. Systém BIP je silne ovplyvnený procesom Python Enhancement Proposal (PEP). Slúži ako formálny spôsob zavedenia zmien do kódbázy alebo okolitého ekosystému. Ktokoľvek môže napísať BIP, ale jeho prijatie a implementácia je prísna prekážka, ktorú len máloktoré návrhy prežijú.
Definovanie BIP
BIP je v podstate technická práca. Ponúka stručnú technickú špecifikáciu funkcie a odôvodnenie funkcie. Autor je zodpovedný za budovanie konsenzu v komunite a dokumentovanie nesúhlasných názorov. Existujú tri hlavné typy BIP. Standards Track BIP popisujú akúkoľvek zmenu, ktorá ovplyvňuje väčšinu alebo všetky implementácie Bitcoinu, ako napríklad zmena sieťového protokolu alebo zmena pravidiel platnosti bloku alebo transakcie.
Informačné BIP popisujú problém s dizajnom Bitcoinu, alebo poskytujú všeobecné pokyny alebo informácie Bitcoin komunite, ale nenavrhnú novú funkciu. Procesné BIP popisujú proces okolo Bitcoinu, alebo navrhujú zmenu (alebo udalosť) v procese. Väčšina verejnej pozornosti sa sústreďuje na Standards Track BIP, pretože tieto návrhy menia konsenzuálne pravidlá siete.
Životný cyklus návrhu
Život BIP sa začína dávno pred tým, ako mu bude priradené číslo. Zvyčajne začína diskusiami na mailing liste pre vývoj Bitcoinu. Tu sa pôvodný nápad preverí, kritizuje a často rozoberie inými vývojármi. Ak nápad prežije túto počiatočnú skúšku ohňom, autor načrtne text BIP.
Po odoslaní návrhu do repozitára BIP mu editor priradí číslo. Tento stav je známy ako „Draft“. Odtiaľ sa návrh posúva rôznymi štádiami. Ak komunita súhlasí, že práca má hodnotu, môže prejsť do stavu „Proposed“. Ak sa zmeny implementujú a sieť ich aktivuje, BIP sa stane „Final“ alebo „Active“. Naopak, návrhy môžu byť „Rejected“, „Withdrawn“ autorom, alebo označené ako „Obsolete“, ak sú nahradené novšími riešeniami.
Mechanizmus konsenzu
Najmenej zrozumiteľným aspektom vývoja Bitcoinu pre outsiderov je absencia formálnej štruktúry riadenia. Neexistuje nadácia ani líder, ktorý by na BIP dal pečiatku „schválené“. Namiesto toho sa sieť spolieha na koncept známy ako „rough consensus“. Toto je termín prevzatý z Internet Engineering Task Force (IETF). Neznamená to jednomyseľnosť.
Pochopenie rough consensus
Rough consensus sa dosiahne, keď technická komunita vo všeobecnosti súhlasí, že návrh je solídny a že všetky významné námietky boli vyriešené. Ide o kvalitatívne meranie namiesto kvantitatívneho hlasovania. Ak návrh má silnú technickú hodnotu, ale čelí oprávneným bezpečnostným obavám zo strany významnej časti vývojárov, nebude postupovať.
Táto dynamika núti autorov zapojiť sa do dialógu s kritikmi. Musia zlepšiť svoje návrhy, kým sa námietky nevyriešia alebo sa nepreukáže, že sú neopodstatnené. Tento proces môže trvať roky. Napríklad upgrade Taproot bol diskutovaný a doladený dlhú dobu predtým, ako bol považovaný za pripravený na aktiváciu. Pomalosť je funkciou, nie chybou, ktorá bráni unáhleným rozhodnutiam, ktoré by mohli destabilizovať finančnú sieť.
Prístup k commitom vývojárov
Bežný omyl je, že vývojári s „commit access“ do repozitára Bitcoin Core na GitHube ovládajú Bitcoin. Hoci títo maintaineri majú schopnosť zlúčiť kód do hlavnej vetvy softvéru, fungujú skôr ako upratovači než vládci. Ich úlohou je zabezpečiť, aby zlúčený kód odrážal rough consensus komunity.
Ak by maintainer zlúčil kód, ktorý by zásadne zmenil Bitcoin proti vôli používateľov, prevádzkovatelia uzlov by jednoducho odmietli aktualizovať na túto verziu. Sieť by pokračovala na predchádzajúcej verzii a verzia maintainera by bola ignorovaná. To vytvára silnú kontrolu nad vplyvom vývojárov, ktorá zabezpečuje, že zostávajú viazaní na želania siete uzlov.
Cesty aktivácie a implementácie
Ak je upgrade protokolu zakódovaný a zlúčený do softvéru Bitcoin Core, zostáva nečinný. Musí ho sieť „aktivovať“. Toto je fáza, kde teoretický konsenzus interaguje s fyzickou realitou blockchainu. Aktivácia vyžaduje koordináciu medzi ekonomickými aktérmi systému, predovšetkým baníkmi a prevádzkovateľmi plných uzlov.
Signaling baníkov a prahy
Historicky sa aktivácia často využívala proces definovaný v BIP 9. Zahŕňa to, že baníci signalizujú svoju pripravenosť na upgrade v hlavičkách blokov, ktoré baní. Po špecifické obdobie, zvyčajne dva týždne (2016 blokov), sieť monitoruje, koľko blokov obsahuje signál podpory pre upgrade.
Ak percento signalizujúcich blokov dosiahne definovaný prah – často 90 % alebo 95 % – upgrade sa zamkne. Po následnom grace období sa nové pravidlá stanú aktívnymi. Tento mechanizmus je navrhnutý tak, aby zabezpečil plynulý upgrade siete bez toho, aby sa baníci nechali pozadu. Avšak viedol aj k politickým patovým situáciám, kde baníci efektívne vetovali upgrady odmietnutím signalizácie, aj keď širšia základňa používateľov zmeny chcela.
User Activated Soft Forks
Obmedzenia signalizácie baníkov sa prejavili počas „Block Size War“ pred rokom 2017. Keď baníci oneskorili aktiváciu Segregated Witness (SegWit), vzniklo grassroots hnutie navrhujúce User Activated Soft Fork (UASF), známy ako BIP 148.
V UASF prevádzkovatelia uzlov spúšťajú softvér, ktorý odmieta bloky od baníkov, ktorí po určitom dátume nebudú signalizovať upgrade. To posúva moc od baníkov späť k ekonomickej väčšine uzlov. Ak sa ekonomická aktivita (burzy, peňaženky, používatelia) presunie na reťazec UASF, baníci sú ekonomicky motivovaní nasledovať, alebo riskovať banenie na bezcennom reťazci. Hrozba BIP 148 bola kľúčová pri nútení aktivácie SegWit.
Dynamika fork a kompatibilita
Zmeny protokolu Bitcoin sa všeobecne delia do dvoch kategórií: soft forks a hard forks. Rozdiel spočíva v spätnej kompatibilite. Pochopenie rozdielu je kľúčové pre pochopenie toho, prečo Bitcoin zostal jednou kontinuálnou sieťou napriek mnohým upgratom.
Mechanizmus soft fork
Soft fork je zmena protokolu, ktorá obmedzuje množinu platných blokov. Sprísňuje pravidlá. Pretože nové pravidlá sú podmnožinou starých pravidiel, staré uzly, ktoré sa neupgradovali, budú stále považovať nové bloky za platné. Možno nebudú chápať nové funkcie, ale prijmú reťazec.
Táto spätná kompatibilita je životne dôležitá. Umožňuje sieti pomalý upgrade. Používatelia nie sú nútení okamžite aktualizovať svoj softvér, aby zostali súčasťou konsenzu. Väčšina hlavných upgradov, vrátane SegWit a Taproot, bola implementovaná ako soft forks. To zabezpečuje, že sieť sa nerozdelí na dve nekompatibilné reťazce len preto, že niektorí používatelia sú pomalí s upgradom.
Divergencia hard fork
Hard fork uvoľňuje pravidlá alebo zavádza pravidlá nekompatibilné so starým softvérom. Staré uzly budú považovať bloky vytvorené podľa nových pravidiel za neplatné a odmietnu ich. Aby hard fork uspel bez rozdelenia siete, musí sa 100 % používateľov upgradovať súčasne, čo je v decentralizovanom systéme nemožné.
V dôsledku toho kontroverzné hard forks takmer vždy vedú k trvalému rozdeleniu reťazca. Najznámejším príkladom je vytvorenie Bitcoin Cash (BCH) v roku 2017. Zástancovia chceli zvýšiť limit veľkosti bloku, čo je zmena pravidla nekompatibilná s existujúcim konsenzom Bitcoinu. To viedlo k dvom odlišným sieťam a menám. Hard forks sa vo vývoji Bitcoinu všeobecne vyhýbajú kvôli tomuto riziku rozbitia siete a komunity.
| Porovnávací atribút | Soft Fork | Hard Fork |
|---|---|---|
| Kompatibilita | Spätná kompatibilita | Bez spätnej kompatibility |
| Zmena pravidiel | Sprísňuje/obmedzuje pravidlá | Uvoľňuje/rozširuje pravidlá |
| Riziko siete | Nízke riziko rozdelenia reťazca | Vysoké riziko trvalého rozdelenia |
Hlavné upgrady protokolu: Segregated Witness
Jedným z najvýznamnejších príkladov návrhu, ktorý sa dostal k implementácii, je Segregated Witness (SegWit). Aktivovaný v auguste 2017, riešil dlhodobé problémy a pripravil pôdu pre budúce škálovanie. Návrh zásadne zmenil štruktúru dát transakcií.
Riešenie malleability
Pred SegWit bolo možné upraviť jedinečné ID transakcie pred jej potvrdením na blockchain bez neplatnenia podpisu. Tento problém, známy ako transaction malleability, sťažoval budovanie riešení druhej vrstvy ako Lightning Network. Ak sa ID transakcie mohlo zmeniť, inteligentné zmluvy spoliehajúce sa na to ID by sa pokazili.
SegWit to vyriešil presunutím podpisových (witness) dát mimo časti transakcie použitej na výpočet ID. Oddelením witness sa ID transakcie stalo nemenným. Táto oprava bola kľúčovým prvkom, ktorý umožnil bezpečné fungovanie platobných kanálov a umožnil vývoj Lightning Network.
Koncept váhovej jednotky
SegWit tiež slúžil ako šikovné zvýšenie veľkosti bloku. Namiesto jednoduchého zvýšenia limitu 1 MB – čo by vyžadovalo hard fork – SegWit zmenil spôsob merania blokov. Zaviedol „block weight“.
Dáta v sekcii witness majú menšiu váhu ako dáta v hlavnom bloku transakcie. To umožňuje blokom prekročiť tradičnú veľkosť 1 MB v súvislosti s surovými dátami (teoreticky až 4 MB), pričom zostávajú kompatibilné so starými uzlami, ktoré kontrolujú iba nedáta witness. To efektívne zvýšilo kapacitu siete a znížilo poplatky za transakcie používajúce formát SegWit.
Upgrade Taproot
Po SegWit bol ďalšou hlavnou zmenou Taproot, aktivovaný v novembri 2021. Taproot kombinoval tri BIP (340, 341 a 342), aby zlepšil súkromie, efektivitu a schopnosti skriptovania. Demonštroval rafinovaný proces aktivácie známy ako „Speedy Trial“.
Schnorr podpisy
V jadre Taproot je implementácia Schnorr podpisov (BIP 340). Tento digitálny podpisový schém ponúka významné výhody oproti pôvodnému Elliptic Curve Digital Signature Algorithm (ECDSA). Hlavnou výhodou je lineárnosť.
Lineárnosť umožňuje agregáciu podpisov. V multisig transakcii možno viac verejných kľúčov a podpisov skombinovať do jediného kľúča a jediného podpisu. Pre blockchain vyzerá komplexná transakcia zahŕňajúca viac strán identicky ako štandardná transakcia jedného používateľa. To zlepšuje súkromie maskovaním komplexnosti usporiadania peňaženiek a šetrí miesto na blockchain, čím znižuje poplatky.
Merkelized Abstract Syntax Trees
Taproot tiež zaviedol Merkelized Abstract Syntax Trees (MAST). Predtým, ak používateľ vytvoril komplexnú inteligentnú zmluvu s viacerými podmienkami výdaju, všetky tieto podmienky museli byť odhalené na blockchain pri výdaji prostriedkov. To bolo neefektívne a škodlivé pre súkromie.
S MAST môžu používatelia štruktúrovať podmienky výdaju vo forme stromu. Pri výdaji musia odhaliť iba špecifickú vetvu stromu, ktorá sa používa. Nevyužité vetvy zostávajú skryté. To umožňuje zložité inteligentné zmluvy, ktoré sú súkromné a efektívne z hľadiska dát, čím ďalej rozširuje potenciál Bitcoinu za jednoduchý prenos hodnoty.
Aktuálne debaty: Prípad OP_CAT
Evolúcia Bitcoinu pokračuje, pričom aktuálne diskusie sa zameriavajú na obnovenie stratených funkcií. Jedným z najvýznamnejších tém je OP_CAT. Ide o špecifický opcode (operation code), ktorý bol súčasťou pôvodného softvéru Bitcoin, ale bol Satoshi Nakamotom v roku 2010 deaktivovaný kvôli obavám z použitia pamäte a bezpečnostných zraniteľností.
Pochopenie opcodov
Opcody sú príkazy, ktoré scripting jazyka Bitcoin rozumie. Hovoria sieti, ako spracovať transakciu. Niektoré opcodes umožňujú sčítanie, iné kontrolujú podpisy a niektoré overujú časové zámky. Keď sú opcodes deaktivované, schopnosť vykonávať tieto špecifické akcie sa odstráni z nástrojov siete.
Odstránenie OP_CAT a iných výrazne obmedzilo scripting jazyk Bitcoinu. Toto obmedzenie bolo v tom čase zámerné, s prioritou na bezpečnosť a stabilitu pred funkčnosťou. Avšak s dozretím pochopenia protokolu teraz vývojári skúmajú bezpečné znovuzavedenie týchto kódov na umožnenie nových funkcií.
Návrh na konkatenáciu
OP_CAT špecificky umožňuje konkatenáciu (spájanie) dvoch reťazcov dát. Aj keď to znie jednoducho, umožňuje výkonnú funkciu známu ako „covenants“. Covenants umožňujú používateľom ukladať obmedzenia na to, ako budú budúce bitcoiny minuté, nielen kto ich môže minúť.
Napríklad covenant by mohol vynútiť, že špecifický UTXO môže byť poslaný iba na špecifickú whitelist adries. To má masívne implikácie pre mechanizmy vault, kde by používatelia mohli vytvoriť „undo“ tlačidlo pre ukradnuté prostriedky, a pre mostenie Layer 2. Debata okolo OP_CAT ilustruje konzervatívnu povahu vývoja Bitcoinu; dokonca aj jednoduchý príkaz vyžaduje roky bezpečnostnej analýzy pred znovuzavedením.
Vplyv na riešenia Layer 2
Návrhy protokolu sa často zameriavajú na základnú vrstvu, ale ich primárna užitočnosť sa realizuje na sieťach Layer 2 (L2). Vzťah medzi hlavným blockchainom a týmito sekundárnymi vrstvami je symbiotický. Zlepšenia základného protokolu robia L2 lacnejšie, bezpečnejšie a efektívnejšie.
Závislosti Lightning Network
Lightning Network je hlavným príkladom tejto závislosti. Spolieha sa na bezpečnosť základnej vrstvy na vysporiadanie transakcií. Ako bolo spomenuté, upgrade SegWit bol predpokladom pre spoľahlivé fungovanie Lightning. Budúce upgrady naďalej cielia na efektivitu Lightning.
Napríklad návrhy ako „Eltoo“ (SIGHASH_ANYPREVOUT) majú za cieľ zjednodušiť správu kanálov. Úpravou spôsobu podpisovania transakcií na základnej vrstve môžu uzly Lightning ukladať menej dát a ľahšie sa zotavovať z porúch. To ukazuje, ako návrhy L1 sú často poháňané potrebami škálovateľnosti L2.
Integrácia sidechainov
Sidechainy, ako Liquid alebo Rootstock, tiež profitujú z upgradov protokolu. Sidechainy sú nezávislé blockchainy bežiace paralelne s Bitcoinom. Používajú dvojitý peg na prenos hodnoty tam a späť. V súčasnosti sa tieto pegy často spoliehajú na federácie – skupiny dôveryhodných funkcionárov.
Upgrady ako OP_CAT alebo nové podpisové schémy by mohli umožniť bezdôveryhodnejšie mostné mechanizmy. Ak môže Bitcoin script overiť dôkazy zo sidechainu (ako Zero-Knowledge proofs), umožnilo by to používateľom presúvať prostriedky medzi reťazcami bez dôvery v federáciu. Toto zostáva hlavnou oblasťou výskumu a motivácie pre nové BIP.
Neúmyselná inovácia: Fenomén Ordinals
Niekedy vedú upgrady protokolu k úplne neočakávaným výsledkom. Vzostup Ordinals je dôkazom zákona neúmyselných dôsledkov v open-source softvéri. Ordinals využívajú mechanizmy SegWit a Taproot na vpísanie dát priamo na jednotlivé satoshi.
SegWit urobil ukladanie witness dát lacnejším a Taproot odstránil limit veľkosti dátových pushov v transakčných scriptoch. V kombinácii tieto zmeny umožnili používateľom vkladanie obrázkov, textu a dokonca videohier do blockchainu Bitcoin. To nebolo špecifickým zámerom vývojárov, ktorí písali tie BIP.
Tento vývoj vyvolal prudkú debatu v komunite. Niektorí považujú vpisy za spam, ktorý zahlcuje sieť, zatiaľ čo iní to vidia ako legitímne využitie priestoru bloku zaplatené poplatkami. Bez ohľadu na názor Ordinals demonštrujú, že keď je návrh implementovaný, používatelia siete využijú nové pravidlá spôsobmi, ktoré autori možno nikdy nepredvídali.
Záver
Anatómia návrhu protokolu Bitcoin odhaľuje systém, ktorý dáva prednosť prežitiu pred všetkým ostatným. Od počiatočného načrtnutia BIP po vyčerpávajúci proces budovania rough consensus je každý krok navrhnutý tak, aby filtroval riziká. Rozdiel medzi soft forks a hard forks ilustruje záväzok k spätnej kompatibilite, ktorý zabezpečuje, že sieť zostane inkluzívna aj pri pokroku.
Upgrady ako SegWit a Taproot ukazujú, že Bitcoin môže inovovať bez obetovania svojich jadrových princípov. Medzitým prebiehajúce debaty okolo OP_CAT a vznik Ordinals dokazujú, že ekosystém zostáva živý a nepredvídateľný. Vzájomné pôsobenie medzi baníkmi, vývojármi a prevádzkovateľmi uzlov vytvára systém kontrol a vyváženia, ktorý žiadna centralizovaná entita nemôže prepísať.
Bitcoin sa mení pomaly nie preto, že sa nemôže pohybovať rýchlo, ale preto, že cena jeho rozbitia je príliš vysoká na riskovanie.