Bitcoin je často popisován jako digitální zlato, což naznačuje statickou a neměnnou povahu. Nicméně software, který pohání síť Bitcoin, je živý protokol, který prochází údržbou, opravami chyb a upgrady. Na rozdíl od centralizovaného vývoje softwaru, kde generální ředitel společnosti nebo manažer produktu diktuje funkce, spoléhá Bitcoin na decentralizovanou síť účastníků, aby se dohodli na změnách. Tento proces je záměrný, pomalý a silně nakloněn k zachování stávajícího stavu, aby zajistil bezpečnost miliard dolarů v hodnotě.
Evoluce protokolu není řízena formálním hlasovacím systémem ani jedinou autoritou. Místo toho funguje prostřednictvím jedinečné kombinace technické dokumentace, peer review a konsenzu komunity. Porozumění tomu, jak se nápad posouvá od jednoduché diskuse na mailing listu k globálně aktivované změně kódu, odhaluje odolnost sítě Bitcoin. Zdůrazňuje systém navržený tak, aby odolal ovládnutí jakoukoli jedinou skupinou, ať už vývojáři, górníci nebo korporátní zájmy.
Ve srdci tohoto evolučního procesu stojí Bitcoin Improvement Proposal, neboli BIP. Jedná se o primární mechanismus pro navrhování nových funkcí, shromažďování názorů komunity na problém a dokumentování rozhodnutí o designu. BIP není závazné hlasování, ale spíše technický designový dokument. Poskytuje informace Bitcoin komunitě nebo popisuje novou funkci pro Bitcoin nebo jeho procesy.
Rámec Bitcoin Improvement Proposal
Abychom pochopili, jak se Bitcoin mění, musíme nejprve pochopit proces standardizace. Systém BIP je silně ovlivněn procesem Python Enhancement Proposal (PEP). Slouží jako formální způsob zavedení změn do kódbáze nebo okolního ekosystému. Běžný člověk může napsat BIP, ale jeho přijetí a implementace je přísná zkouška, kterou přežije jen málo návrhů.
Definice BIP
BIP je v podstatě technická práce. Nabízí stručnou technickou specifikaci funkce a odůvodnění funkce. Autor je zodpovědný za budování konsenzu v komunitě a dokumentování nesouhlasných názorů. Existují tři hlavní typy BIP. Standards Track BIP popisují jakoukoli změnu, která ovlivňuje většinu nebo všechny implementace Bitcoinu, například změnu síťového protokolu nebo změnu pravidel platnosti bloku nebo transakce.
Informační BIP popisují problém s designem Bitcoinu nebo poskytují obecné pokyny nebo informace Bitcoin komunitě, ale nenavrhují novou funkci. Procesní BIP popisují proces okolo Bitcoinu nebo navrhují změnu (nebo událost) v procesu. Většina veřejné pozornosti se věnuje Standards Track BIP, protože tyto návrhy mění konsenzuální pravidla sítě.
Životní cyklus návrhu
Život BIP začíná dlouho předtím, než mu je přiřazeno číslo. Obvykle začíná diskuzemi na mailing listu pro vývoj Bitcoinu. Zde je počáteční nápad prověřen, kritizován a často roztrhán jinými vývojáři. Pokud nápad přežije tuto počáteční zkoušku ohněm, autor vytvoří text BIP.
Jakmile je návrh odeslán do repozitáře BIP, editor mu přiřadí číslo. Tento stav je známý jako „Draft“. Odtud se návrh posouvá různými stádii. Pokud komunita souhlasí, že práce je cenná, může přejít do stavu „Proposed“. Pokud jsou změny implementovány a síť je aktivuje, BIP se stane „Final“ nebo „Active“. Naopak návrhy mohou být „Rejected“, „Withdrawn“ autorem nebo označeny jako „Obsolete“, pokud jsou nahrazeny novějšími řešeními.
Mechanismus konsenzu
Nejmatoucí aspekt vývoje Bitcoinu pro vetřence je absence formální struktury governance. Neexistuje nadace ani lídr, který by na BIP razil „approved“. Místo toho síť spoléhá na koncept známý jako „rough consensus“. Toto je termín půjčený z Internet Engineering Task Force (IETF). Neznamená to jednomyslnost.
Porozumění rough consensus
Rough consensus je dosažen, když technická komunita obecně souhlasí, že návrh je zdravý a že byly řešeny všechny významné námitky. Jedná se o kvalitativní měření spíše než kvantitativní hlasování. Pokud návrh má silné technické kvality, ale čelí platným bezpečnostním obavám od významné části vývojářů, nepokračuje.
Tato dynamika nutí autory zapojit se do kritiky. Musí vylepšovat své návrhy, dokud nejsou námitky vyřešeny nebo prokázány jako neopodstatněné. Tento proces může trvat roky. Například upgrade Taproot byl diskutován a zdokonalován po dlouhou dobu, než byl považován za připravený k aktivaci. Pomalost je funkcí, ne chybou, zabraňující unáhleným rozhodnutím, která by mohla destabilizovat finanční síť.
Přístup k commitům vývojářů
Běžný omyl je, že vývojáři s „commit access“ k repozitáři Bitcoin Core na GitHubu ovládají Bitcoin. Zatímco tito maintaineři mají schopnost sloučit kód do hlavní větve softwaru, fungují spíše jako správci než vládci. Jejich role je zajistit, aby sloučený kód odrážel rough consensus komunity.
Pokud by maintainer sloučil kód, který by fundamentálně změnil Bitcoin proti vůli uživatelů, provozovatelé uzlů by jednoduše odmítli aktualizaci na tuto verzi. Síť by pokračovala na předchozí verzi a verze maintainerů by byla ignorována. To vytváří silnou kontrolu vlivu vývojářů, zajišťující, že zůstávají vázáni přáními uzlové sítě.
Cesty aktivace a implementace
Jakmile je upgrade protokolu zakódován a sloučen do softwaru Bitcoin Core, zůstává neaktivní. Musí být „aktivován“ sítí. Toto je fáze, kde teoretický konsenzus interaguje s fyzickou realitou blockchainu. Aktivace vyžaduje koordinaci mezi ekonomickými aktéry systému, především górníky a provozovateli plných uzlů.
Signálování górníků a prahy
Historicky aktivace často využívala proces definovaný v BIP 9. Zahrnuje to signálování připravenosti górníků na upgrade v hlavičkách bloků, které těží. Po určitou dobu, obvykle dva týdny (2016 bloků), síť monitoruje, kolik bloků obsahuje signál podpory upgradu.
Pokud procento signálujících bloků dosáhne definovaného prahu – často 90 % nebo 95 % – upgrade se uzamkne. Po následném prodloužení lhůty se nová pravidla stanou aktivními. Tento mechanismus je navržen tak, aby zajistil plynulý upgrade sítě bez opuštění górníků. Nicméně vedl také k politickým patovým situacím, kde górníci efektivně vetují upgrady odmítnutím signálování, i když širší základna uživatelů změnu chce.
User Activated Soft Forks
Omezení signálování górníků se projevila během „Block Size War“ před rokem 2017. Když górníci zdržovali aktivaci Segregated Witness (SegWit), objevilo se grassroots hnutí navrhující User Activated Soft Fork (UASF), známý jako BIP 148.
V UASF provozovatelé uzlů spouštějí software, který odmítá bloky od górníků, kteří po určitém datu nesignálují upgrade. To přesouvá moc zpět k ekonomické většině uzlů. Pokud se ekonomická aktivita (burzy, peněženky, uživatelé) přesune na řetězec UASF, górníci jsou ekonomicky motivováni následovat, nebo riskují těžbu na bezcenném řetězci. Hrozba BIP 148 byla klíčová pro vynucení aktivace SegWit.
Dynamika forků a kompatibilita
Změny protokolu Bitcoin obecně spadají do dvou kategorií: soft forks a hard forks. Rozdíl spočívá v zpětné kompatibilitě. Porozumění rozdílu je klíčové pro chápání toho, proč Bitcoin zůstal jedinou kontinuální sítí navzdory četným upgradům.
Mechanismus soft fork
Soft fork je změna protokolu, která omezuje množinu platných bloků. Zužuje pravidla. Protože nová pravidla jsou podmnožinou starých pravidel, staré uzly, které nebyly upgradovány, stále vidí nové bloky jako platné. Možná neporozumí novým funkcím, ale přijmou řetězec.
Tato zpětná kompatibilita je životně důležitá. Umožňuje síti postupný upgrade. Uživatelé nejsou nuceni okamžitě aktualizovat svůj software, aby zůstali součástí konsenzu. Většina hlavních upgradů, včetně SegWit a Taproot, byla implementována jako soft forks. To zajišťuje, že síť se nerozdělí na dva nekompatibilní řetězce jen proto, že někteří uživatelé jsou pomalí s upgradem.
Divergence hard fork
Hard fork uvolňuje pravidla nebo zavádí pravidla nekompatibilní se starým softwarem. Staré uzly uvidí bloky vytvořené pod novými pravidly jako neplatné a odmítnou je. Aby hard fork uspěl bez rozdělení sítě, musí 100 % uživatelů upgradovat současně, což je v decentralizovaném systému nemožné.
V důsledku toho sporné hard forks téměř vždy vedou k trvalému rozdělení řetězce. Nejznámějším příkladem je vytvoření Bitcoin Cash (BCH) v roce 2017. Zastánci chtěli zvýšit limit velikosti bloku, což byla změna pravidel nekompatibilní s existujícím konsenzem Bitcoinu. To vedlo k dvěma odlišným sítím a měnám. Hard forks se ve vývoji Bitcoinu obecně vyhýbají kvůli tomuto riziku rozbití sítě a komunity.
| Porovnávací atribut | Měkký fork | Tvrdý fork |
|---|---|---|
| Kompatibilita | Zpětně kompatibilní | Nezpětně kompatibilní |
| Změna pravidel | Zužuje/Omezuje pravidla | Uvolňuje/Rozšiřuje pravidla |
| Riziko sítě | Nízké riziko rozdělení řetězce | Vysoké riziko trvalého rozdělení |
Hlavní upgrady protokolu: Segregated Witness
Jeden z nejvýznamnějších příkladů návrhu posunujícího se k implementaci je Segregated Witness (SegWit). Aktivován v srpnu 2017, řešil dlouhodobé problémy a připravil půdu pro budoucí škálování. Návrh fundamentálně změnil strukturu dat transakcí.
Řešení malleability
Před SegWit bylo možné upravit jedinečné ID transakce před jejím potvrzením na blockchainu bez invalidace podpisu. Tento problém, známý jako transaction malleability, ztěžoval budování druhé vrstvy řešení jako Lightning Network. Pokud se ID transakce mohlo změnit, chytré kontrakty spoléhající na toto ID by selhaly.
SegWit to vyřešil přesunutím podpisových (witness) dat mimo část transakce používanou k výpočtu ID. Oddělením witness se ID transakce stalo neměnným. Toto řešení bylo klíčové pro bezpečné fungování platebních kanálů, umožňující vývoj Lightning Network.
Koncept váhy jednotky
SegWit také sloužil jako chytrý nárůst velikosti bloku. Místo jednoduchého zvýšení limitu 1 MB – což by vyžadovalo hard fork – SegWit změnil měření bloků. Zaváděl „block weight“.
Data v sekci witness mají menší váhu než data v hlavní části transakčního bloku. To umožňuje blokům překročit tradiční velikost 1 MB v surových datech (teoreticky až 4 MB), zatímco zůstávají kompatibilní se starými uzly, které kontrolují pouze ne-witness data. To efektivně zvýšilo kapacitu sítě a snížilo poplatky pro transakce ve formátu SegWit.
Upgrade Taproot
Následující po SegWit byla další hlavní změna Taproot, aktivovaný v listopadu 2021. Taproot kombinoval tři BIP (340, 341 a 342), aby zlepšil soukromí, efektivitu a schopnosti skriptování. Demonstroval jemnější proces aktivace známý jako „Speedy Trial“.
Schnorr podpisy
V jádru Taproot je implementace Schnorr podpisů (BIP 340). Tento digitální podpisový schémat nabízí významné výhody oproti původnímu Elliptic Curve Digital Signature Algorithm (ECDSA). Primární výhodou je lineárnost.
Lineárnost umožňuje agregaci podpisů. V multi-signature transakci lze více veřejných klíčů a podpisů zkombinovat do jednoho klíče a jednoho podpisu. Pro blockchain vypadá složitá transakce zahrnující více stran identicky jako standardní transakce jednoho uživatele. To zlepšuje soukromí maskováním složitosti uspořádání peněženek a šetří místo na blockchainu, snižuje poplatky.
Merkelized Abstract Syntax Trees
Taproot také zaváděl Merkelized Abstract Syntax Trees (MAST). Dříve, pokud uživatel vytvořil složitý chytrý kontrakt s více podmínkami výdaje, musely být všechny tyto podmínky odhaleny na blockchainu při výdeji prostředků. To bylo neefektivní a špatné pro soukromí.
S MAST mohou uživatelé strukturovat podmínky výdaje ve formě stromu. Při výdeji potřebují odhalit pouze specifickou větev stromu, která se používá. Nevyužité větve zůstávají skryté. To umožňuje složité chytré kontrakty, které jsou soukromé a efektivní z hlediska dat, dále rozšiřující potenciál Bitcoinu za jednoduchý převod hodnoty.
Aktuální debaty: Případ OP_CAT
Evoluce Bitcoinu pokračuje, s aktuálními diskuzemi zaměřenými na obnovení ztracené funkcionality. Jedním z nejvýznamnějších témat je OP_CAT. Jedná se o specifický opcode (operation code), který byl součástí původního softwaru Bitcoinu, ale byl vypnut Satoshi Nakamotem v roce 2010 kvůli obavám z použití paměti a bezpečnostních zranitelností.
Porozumění opcode
Opcody jsou příkazy, které jazyk skriptování Bitcoinu rozumí. Říkají síti, jak zpracovat transakci. Některé opcodes umožňují sčítání, jiné kontrolují podpisy a některé ověřují časové zámky. Když jsou opcodes vypnuté, schopnost provádět tyto specifické akce je z nástroje sítě odstraněna.
Odstranění OP_CAT a dalších výrazně omezilo skriptovací jazyk Bitcoinu. Toto omezení bylo v té době záměrné, upřednostňující bezpečnost a stabilitu před funkcionalitou. Jakmile však porozumění protokolu dozrálo, vývojáři nyní zkoumají bezpečné znovuzavedení těchto kódů pro umožnění nových funkcí.
Návrh na konkatenaci
OP_CAT konkrétně umožňuje konkatenaci (spojení) dvou řetězců dat. I když to zní jednoduše, umožňuje výkonnou funkci známou jako „covenants“. Covenants umožňují uživatelům ukládat omezení na to, jak mohou být budoucí bitcoiny utraceny, nejen kdo je může utratit.
Například covenant by mohl vynutit, že specifické UTXO může být odesláno pouze na specifický whitelist adres. To má masivní dopady na mechanismy vaultů, kde by uživatelé mohli vytvořit „undo“ tlačítka pro ukradené prostředky, a pro mosty vrstvy 2. Debata kolem OP_CAT ilustruje konzervativní povahu vývoje Bitcoinu; i jednoduchý příkaz vyžaduje roky bezpečnostní analýzy před znovuzavedením.
Dopad na řešení vrstvy 2
Návrhy protokolu často cílí na základní vrstvu, ale jejich primární užitek se realizuje na sítích vrstvy 2 (L2). Vztah mezi hlavním blockchainem a těmito sekundárními vrstvami je symbiotický. Zlepšení základního protokolu činí L2 levnějšími, bezpečnějšími a efektivnějšími.
Závislosti Lightning Network
Lightning Network je hlavním příkladem této závislosti. Spoléhá na bezpečnost základní vrstvy pro vypořádání transakcí. Jak bylo zmíněno, upgrade SegWit byl předpokladem pro spolehlivé fungování Lightning. Budoucí upgrady nadále cílí na efektivitu Lightning.
Například návrhy jako „Eltoo“ (SIGHASH_ANYPREVOUT) mají zjednodušit správu kanálů. Úpravou způsobu podpisování transakcí na základní vrstvě mohou uzly Lightning ukládat méně dat a snadněji se zotavovat z selhání. To ukazuje, jak jsou návrhy L1 často řízeny potřebami škálovatelnosti L2.
Integrace sidechainů
Sidechainy, jako Liquid nebo Rootstock, také těží z upgradů protokolu. Sidechainy jsou nezávislé blockchainy běžící paralelně k Bitcoinu. Používají obousměrný peg pro převod hodnoty tam a zpět. V současnosti tyto pegy často spoléhají na federace – skupiny důvěryhodných funkcionářů.
Upgrady jako OP_CAT nebo nové podpisové schémata by mohly umožnit bezdůvěrné mostní mechanismy. Pokud může Bitcoin script ověřit důkazy ze sidechainu (jako Zero-Knowledge proofs), umožnilo by to uživatelům přesouvat prostředky mezi řetězci bez důvěry v federaci. Toto zůstává hlavní oblastí výzkumu a motivace pro nové BIP.
Neúmyslná inovace: Fenomén Ordinals
Někdy upgrady protokolu vedou k úplně neočekávaným výsledkům. Vzestup Ordinals je svědectvím zákona neúmyslných důsledků v open-source softwaru. Ordinals využívají mechanismy jak SegWit, tak Taproot k napsání dat přímo na jednotlivé satoshi.
SegWit zlevnil ukládání witness dat a Taproot odstranil limit velikosti na data pushes v transakčních skriptech. V kombinaci tyto změny umožnily uživatelům vestřebat obrázky, text a dokonce videohry do blockchainu Bitcoin. To nebylo specifickým záměrem vývojářů, kteří tyto BIP psali.
Tento vývoj vyvolal zuřivou debatu v komunitě. Někteří považují nápisy za spam, který ucpává síť, zatímco jiní to vidí jako legitimní použití prostoru bloku zaplacené poplatky. Bez ohledu na pohled Ordinals demonstrují, že jakmile je návrh implementován, uživatelé sítě využijí nová pravidla způsoby, které autoři nikdy nečekali.
Závěr
Anatomie návrhu protokolu Bitcoinu odhaluje systém, který upřednostňuje přežití před vším ostatním. Od počátečního návrhu BIP po vyčerpávající proces budování rough consensus je každý krok navržen tak, aby filtroval rizika. Rozdíl mezi soft forks a hard forks ilustruje závazek k zpětné kompatibilitě, zajišťující, že síť zůstává inkluzivní i při pokroku.
Upgrady jako SegWit a Taproot ukazují, že Bitcoin může inovovat bez obětování svých jádrových principů. Zatímco probíhající debaty kolem OP_CAT a vznik Ordinals dokazují, že ekosystém zůstává živý a nepředvídatelný. Vzájemné působení mezi górníky, vývojáři a provozovateli uzlů vytváří systém kontrol a vyvažování, který žádná centralizovaná entita nemůže přepsat.
Bitcoin se mění pomalu ne proto, že nemůže jít rychle, ale protože cena jeho rozbití je příliš vysoká na riziko.