Dlouhodobý spor o velikost bloku a nedávné zavedení několika nových implementací bitcoinů zdůraznily, že ne všechny uzly bitcoinů používají přesně stejné pravidlo – a co je možná důležitější, že ne všechny vývojové týmy uplatňují při provádění těchto pravidel podobné zásady..

Vývojový tým v pozadí Bitcoinové jádro, Historický „referenční klient“ bitcoinu vyžaduje rozsáhlý konsenzus komunity, než implementuje změny pravidel, jako je zvýšení limitu velikosti bloku, zatímco jiné změny nejsou dodržovány podle stejných standardů. 

Mezitím některé bitcoinové vidličky, jako např Bitcoin LJR, jsou obecně přijímány vývojovou komunitou, zatímco jiné, jako např Bitcoin Classic, přilákat hodně kontroverze. Někteří to považují za nekonzistentní.

Tento rozdíl však lze vysvětlit. Určité změny pravidel implementované na určitých forcích ovlivňují bitcoinovou síť velmi odlišně než ostatní. Nebo konkrétněji: Určité změny pravidel mají dopad na velmi odlišné vrstvy sítě bitcoinů. A některé z těchto změn pravidel mohou síť bitcoinů rozdělit, zatímco jiné nikoli.

Vyjasnit tyto rozdíly, Bitcoinové jádro vývojář a Ciphrex Generální ředitel Eric Lombrozo nedávno navrhl označit příslušné vrstvy ve všech návrzích na vylepšení bitcoinů. Jedná se o čtyři hlavní vrstvy v bitcoinové síti, jak je uvedeno v jeho BIP 123, a příslušná důležitost shody na každém z nich.

Pravidla konsensu

Konsenzuální pravidla jsou nejdůležitějšími pravidly bitcoinu. Stanovují – mimo jiné – množství bitcoinů zahrnutých do odměny za blok, obtížnost těžby, typ požadovaného důkazu o práci a skutečně limit velikosti bloku. 

Tato pravidla jsou tak důležitá, protože určují, které bloky jsou považovány za platné úplnými uzly. A pokud všechny plné uzly používají stejná pravidla konsensu, zajišťuje, že si všechny zachovají identickou kopii blockchainu. 

Pokud však různé uzly použijí různá pravidla konsensu, riskují přijetí bloků, které ostatní uzly odmítnou. Taková nesrovnalost by mohla vést k tomu, že by různé uzly udržovaly zcela nekompatibilní verze blockchainu, což by účinně rozdělilo bitcoinovou síť.

Pravidla konsensu bitcoinů lze změnit dvěma způsoby. Změna, která do protokolu přidává další pravidla (což zneplatňuje dříve platné bloky), se nazývá soft fork. Měkké vidlice vyžadují většinu hash síly na podporu změny. Bloky, které jsou vytvářeny podle nových pravidel, by byly platné také podle starých pravidel, takže uzly, které neaktualizovaly, by stále sledovaly nejdelší řetězec.

Neupgradovaní těžaři však mohou podle nových pravidel vytvářet bloky, které jsou neplatné, a plýtvají hashovací silou. Neupgradované plné uzly by již nebyly schopny ověřit, zda bloky dodržují nová pravidla, což by vyžadovalo, aby počkali na další potvrzení, aby dosáhli stejné úrovně zabezpečení. 

Z těchto a dalších důvodů vývojový tým Bitcoin Core uvedl, že k dohodě na soft forcích bude obvykle zapotřebí nadpoloviční většina 95% hash síly.

Změna konsensuálního pravidla, která odstraní pravidla z protokolu (učiní dříve neplatné bloky platnými), se nazývá hard fork. Hard fork vyžaduje přijetí všech plných uzlů v síti. Jakýkoli uzel, který změnu neimplementuje, nemusí vůbec následovat nejdelší řetězec, protože by tento řetězec mohl považovat za neplatný a místo toho by zůstal ve „starém“ řetězci. To by mohlo rozdělit bitcoinovou síť, jak je popsáno výše. Jak dlouho by takové rozdělení vydrželo, není ve skutečnosti technická otázka, ale spíše debata o politice, sociologii, ekonomii, teorii her a dalších.

Soft fork změny pravidel konsensu bez konsensu by mohly – v nejhorším případě – způsobit, že menšina těžařů bude plýtvat hashovací silou a (mírně) degradovat zabezpečení plných uzlů.

Tvrdé změny pravidel konsensu bez konsensu by mohly – v nejhorším případě – rozdělit bitcoinovou síť.

Vrstva typu peer-to-peer

Vrstva peer-to-peer bitcoinové sítě pokrývá, jak plné uzly sdílejí data a jaká data sdílejí. To zahrnuje pravidla protokolu pro odesílání a přijímání transakcí a bloků, jakož i speciální datové balíčky, jako jsou Segregated Witnesses nebo Invertible Bloom Lookup Tables.

Nejdůležitější je, že vrstva peer-to-peer musí zajistit, aby si nové bloky našly cestu v celé síti, stejně jako datové balíčky potřebné k ověření bloků. Pokud tato zásada přenosu selže, může to mít za následek rozdělení sítě, kde různé uzly obsahují různé verze blockchainu – alespoň dokud si bloky znovu nenajdou cestu přes celou síť.

Ale na rozdíl od pravidel konsensu to nemusí být nutně obrovský problém, pokud ne každý uzel uplatňuje přesně stejnou politiku předávání. Vzhledem k tomu, že většina uzlů předává bloky alespoň osmi vrstevníkům, měl by tento zesilovač zajistit, aby všechny uzly přijímaly všechny bloky, i když některé z nich nepředávají správně.

Uzly mají ještě větší volnost, pokud jde o předávání transakcí. Většina uzlů v bitcoinové síti dnes používá zásadu „první vidění“: Pokud obdrží dvě nebo více konfliktních transakcí, odmítnou tyto. Rostoucí počet uzlů však používá variace zásad „nahradit za poplatek“, což znamená, že vybírají transakce, které zahrnují nejvyšší poplatky – bez ohledu na to, které byly dříve. Některé uzly navíc zcela odmítají určité typy transakcí nebo nepřenášejí žádné transakce vůbec.

To znamená, že horníci nakonec rozhodnou, které transakce zahrnou do bloků a proč. Pouze když se zásady přenosu transakcí divoce liší nebo jsou dostatečně omezující, může se stát nepředvídatelné, které transakce jsou potvrzeny pouze z těchto důvodů.

Změny vrstvy peer-to-peer bez konsensu by mohly – v nejhorším případě – rozdělit síť. Toto riziko existuje, pokud si bloky nemohou najít cestu v celé síti. Rozdělení se však automaticky vyřeší, jakmile se síť znovu připojí.

Pokud se změny týkají pouze transakcí, mohou – v nejhorším případě – zabránit tomu, aby se určité transakce potvrdily. Mohlo by to také snížit spolehlivost nepotvrzených transakcí. Ale nemůže rozdělit síť.

Rozhraní aplikačního programování a vzdálená volání procedur

Vrstvy aplikačního programového rozhraní (API) a vzdálené volání procedur (RPC) jsou komunikační vrstvy nad protokolem peer-to-peer. Mnoho bitcoinových softwarových aplikací – například mobilní peněženky a průzkumníci bloků – komunikuje s blockchainem prostřednictvím těchto vrstev připojením k API nebo softwarové knihovně.

Pokud některá z těchto vrstev selže, nebudou všechny připojené softwarové aplikace schopny spolehlivě komunikovat se sítí bitcoinů. Mobilní peněženky nebudou vědět, zda dostaly bitcoin, a průzkumníci blockchainu nemohou zjistit, zda byl nalezen nový blok. Všichni ostatní uživatelé bitcoinů si však nic nevšimnou; samotná síť stále funguje dobře.

Změny vrstev API a RPC bez konsensu by mohly – v nejhorším případě – zcela odpojit uživatele těchto vrstev od bitcoinové sítě. Ale takové změny nemohou rozdělit samotnou síť.

Aplikace

A konečně aplikační vrstva odkazuje na to, jak bitcoinové softwarové aplikace vytvářejí a používají určité typy dat, která se ve skutečnosti přímo nedotýkají sítě, ale to je užitečné pro synchronizaci napříč aplikacemi.

To zahrnuje například formáty adres, generování soukromých klíčů nebo zálohy peněženky. Pokud jedna peněženka vygeneruje adresu, kterou jiná peněženka nepovažuje za platnou, transakce mezi nimi nebude možná. Nebo pokud jedna peněženka používá jednu metodu k vytvoření semene záložní adresy a jiná peněženka používá jinou, uživatelé nemohou obnovit své soukromé klíče s každou peněženkou. Totéž platí pro zálohy peněženky.

Změny aplikačních vrstev bez konsensu by mohly – v nejhorším případě – zabránit některým uživatelům ve vzájemné transakci a způsobit další nepříjemnosti. Takové změny nemohou síť rozdělit. Děkujeme za technické vedení společnosti Lombrozo.