Taproot, navrhovaný upgrade protokolu, který by zlepšil soukromí a flexibilitu bitcoinů, je v pozdní fázi vývoje. Přispěvatelé bitcoinového jádra souhlasí s tím, že upgrade by byl pro bitcoiny přínosem, a zatím se obecně zdá, že je vítán i širším ekosystémem bitcoinů. Je tedy pravděpodobné, že se Taproot dostane do vydání bitcoinového jádra a případně budou následovat další implementace bitcoinů.

Zůstává však jedna otázka: jak by měla upgradovat samotná bitcoinová síť? Taproot je změna konsensuálního protokolu, což znamená, že bitcoinové uzly musí nějak přejít ze starých pravidel na nová pravidla, aniž by rozdělili síť na frakce prosazující odlišná pravidla. Z různých důvodů se to v minulosti někdy ukázalo jako výzva.

Nyní se uvažuje o vylepšených strategiích pro aktivaci upgradů protokolů.

Předchozí Soft Forks a BIP 9

Dobrou zprávou je, že Taproot bude měkkou vidličkou. Tento typ upgradu přidává nebo zpřísňuje pravidla – na rozdíl od hard forku, který odstraňuje nebo uvolňuje pravidla. Pěkná věc na přidání nebo zpřísnění pravidel je, že cokoli, co upgradovaný uzel považuje za platné, považuje i upgradovaný uzel za platné. (Pokud starý uzel přijímá oba typy transakcí A a B, ale nová pravidla povolují pouze typ transakce A, starý uzel by zůstal kompatibilní v síti prosazující nová pravidla.)

Nejdříve soft forky bitcoinu byly aktivovány během dnů vlajky. Vývojáři (zejména Satoshi Nakamoto) vložili do data nového vydání bitcoinového softwarového klienta budoucí datum a určili časový okamžik, kdy by upgradované uzly vynucovaly nová pravidla. Horníci a uživatelé byli vyzváni, aby před tímto datem upgradovali, aby se zabránilo rozdělení sítě. (Mimochodem, v té době byli horníci a uživatelé častěji stejnými lidmi než dnes.)

Vzhledem k tomu, že neupgradované uzly zůstávají kompatibilní s novými pravidly, užitečnou výhodou soft forků je, že pokud většina hash síly vynucuje upgrade, celá bitcoinová síť najde shodu na jejich verzi blockchainu. To také znamená, že je méně naléhavá potřeba upgradovat všechny uzly okamžitě po vynucení nových pravidel protokolu, což uživatelům umožňuje určitou flexibilitu. (Přesto se uživatelům doporučuje, aby upgradovali; v konečném důsledku jsou to ti, kdo prosazují nová pravidla odmítáním transakcí a blokováním, které je porušují.)

Od roku 2012 soft forky stále více využívají hashovací sílu jako koordinační mechanismus pro koordinaci přechodu na nová pravidla. Vložením trochu dat do svých bloků mohou těžaři signalizovat ostatním těžařům a zbytku sítě, že upgradovali svůj software, a jsou tak připraveni prosazovat nová pravidla. Jakmile je podporováno dostatečné množství hash výkonových signálů, spustí se všechny upgradované uzly, aby se vynucovala nová pravidla.

V průběhu několika upgradů se z této strategie vyvinul návrh na vylepšení bitcoinu 9 (BIP 9). BIP 9 byl například mechanismus používaný k aktivaci posledního upgradu bitcoinu Soft Seekated Witness (SegWit). Horníci dostali rok na aktivaci aktualizace, což vyžadovalo, aby 95 procent bloků v jakémkoli intervalu obtížnosti zahrnovalo bit připravenosti signálu. Pokud by se to po roce nestalo, doba aktivace by vypršela a upgrade by selhal. (Mohlo by to pak samozřejmě jednoduše zkusit znovu.)

Pro SegWit však BIP 9 nehrál hladce. Stejně jako u některých předchozích upgradů se někteří těžaři pravděpodobně nějakou dobu nedostali k upgradu kvůli apatii: pro horníky často není příliš velká pobídka k rychlému upgradu. Větším problémem však bylo, že někteří horníci pochopili proces signalizace jako jakési hlasování o upgradu, kde místo signalizace připravenosti signalizovali (nebo ne) podporu. Horší je, že někteří těžaři skončili pomocí tohoto „hlasování“ k zablokování upgradu, aby se pokusili získat politický vliv na proces vývoje bitcoinů, nebo „hlasovali“ proti upgradu, aby skrytě využili vtípky do bitcoinu protokol, který by upgrade opravil.

Po delší době intenzivního dramatu se SegWit nakonec aktivoval, ale až poté, co alternativní bitcoinoví klienti zahrnuli nová aktivační schémata. BIP 148, zahrnutý v klientu BIP 148 provozovaném některými uživateli, byl naprogramován tak, aby přijímal pouze bloky signalizující podporu pro upgrade protokolu počínaje dnem vlajky. Mezitím BIP 91, který je součástí klienta btc1 a provozován horníky těsně před vlajkovým dnem BIP 148, účinně snížil potřebu hašovací energie z 95 procent na 75 procent. Tváří v tvář potenciální rozdělené síti a možné ztrátě příjmů, obstrukční horníci připustili. Ale pro většinu vývojářů Bitcoin Core se BIP 9 ukázal jako neoptimální řešení a začali přemýšlet o alternativách.

BIP 8

BIP 8 byla časná alternativa pro BIP 9, kterou navrhl autor BIP 148, Shaolinfry a Bitcoin Knots a přispěvatel Bitcoin Core Luke-jr. Zpočátku to připomínalo BIP 9, ale s jedním zásadním rozdílem: místo toho, aby upgrade selhal po roce nedostatečné podpory hash energie, udělal by pravý opak a aktivoval soft fork v daném okamžiku. Podobně jako v den vlajky by všechny upgradované uzly od té doby začaly prosazovat nová pravidla. Horníci, kteří by se stále nepodařilo upgradovat, by riskovali těžařské bloky, které by upgradovaní horníci a uživatelé odmítli.

Hlavní myšlenkou BIP 8 je, že – za předpokladu, že uživatelé upgradují – těžaři nemohou blokovat soft vidličku, a proto nemohou využít tuto páku ve svůj prospěch. Mohou zrychlit aktivaci a pomoci koordinovat plynulý upgrade protokolu, ale k upgradu nakonec dojde, i když ho sami neaktivují.

Novější koncept BIP 8 obsahuje některé významné změny. U jednoho BIP 8 umožňuje, aby uzly byly konfigurovány pro dvě různé zásady, když má vypršet doba signalizace: vynucená aktivace, jak je vysvětleno v předchozích dvou odstavcích, nebo žádná vynucená aktivace, jako u BIP 9. Kromě toho místo aktivace samotná aktualizace, uzly (pokud jsou nakonfigurovány) skutečně vynucují signalizaci pro aktualizaci. Bloky, které nesignalizují podporu pro upgrade, jsou poté odmítnuty, a proto stále zaručují upgrade, alespoň pro upgradované uzly. Kombinace těchto dvou změn má zajímavou vlastnost, že pokud je většina veškeré bitcoinové hash síly přinucena signalizovat podporu pro upgrade, spolu s upgradem půjdou i uzly BIP 8, které nejsou nakonfigurovány pro vynucení signalizace.

Argumentem proti BIP 8 a konkrétně jeho vynucené signalizaci (nebo automatické aktivaci) je, že to může být riskantní, zejména na kratší časové ose. Pokud většina hash síly a alespoň někteří uživatelé neaktualizují, mohlo by toto schéma rozdělit síť mezi upgradované a neinovované uzly. Za předpokladu, že většina uživatelů podporuje upgrade, by se to pravděpodobně nakonec vyřešilo ve prospěch upgradované části sítě. Neupgradovaní uživatelé by však mezitím riskovali ztrátu finančních prostředků, zatímco neaktualizovaní těžaři by plýtvali hašovací energií na úkor bezpečnosti bitcoinu.

Tomuto riziku je pravděpodobně nejlépe čelit nabídkou dostatku času na upgrade. Bohužel ne každý souhlasí s tím, kolik času je dost; někteří si myslí, že vynucená signalizace by mohla začít do roku, jiní věří, že by to mělo trvat několik let.

Další komplikací BIP 8 je nastavení výchozích hodnot pro vynucenou signalizaci. Pokud je vynucená signalizace ve výchozím nastavení vypnutá, uživatelé by se mohli ocitnout nekoordinovaní, což by zvýšilo riziko rozdělení sítě. Pokud je naopak ve vydání bitcoinového jádra jako výchozí vybrána nucená signalizace, historicky rozšířené přijetí bitcoinového jádra prakticky zaručuje, že k upgradu dojde. Někteří se domnívají, že by to vývojářům bitcoinového jádra poskytlo příliš velký vliv na pravidla protokolu bitcoinu. Spoluautor BIP 8 Luke-jr upřednostňuje nasazení BIP 8 pouze prostřednictvím speciálních klientů, podobně jako u klienta BIP 148.

Jiní tvrdí, že vývojáři Bitcoin Core vydávají software vždy podle svého nejlepšího úsudku, přičemž mají na paměti poptávku uživatelů a vyhýbají se sporným upgradům; nastavení výchozích hodnot BIP 8 by nemělo být výjimkou z této zásady. Pokud kdokoli nesouhlasí s možnostmi, které vývojáři Bitcoin Core dělají, může se jednoduše rozhodnout, že nebude upgradovat na nové vydání, nebo dokonce rozdvojí kód Bitcoin Core, aby mohl úplně spustit konkurenčního klienta..

Moderní aktivace měkké vidlice

Zatímco se vývojáři bitcoinového jádra skutečně snaží zohlednit poptávku uživatelů a pokusit se vyhnout sporným upgradům, ne každý je přesvědčen, že je to vždy naprosto možné. Možná se obavy z navrhované aktualizace projeví pouze v případě, že je software nasazen v nové verzi. Po tomto vydání možná nastanou zcela nové problémy. Nebo snad vývojářům bitcoinového jádra něco chybělo.

To je jeden z důvodů, proč přispěvatel Bitcoin Core Matt Corallo navrhl strategii nazvanou „Moderní aktivace měkké vidlice.„Modern Soft Fork Activation sestává ze tří kroků, které společně v podstatě realizují kombinaci BIP 9 (nebo: BIP 8 bez vynucené signalizace) a BIP 8 s aktivací příznakového dne (i když vynucená signalizace může být také možností).

Jako první krok by BIP 9 umožnil těžařům aktivovat měkkou vidličku pomocí hash síly. Pokud ho horníci neaktivují (řekněme) za rok, první aktivační okno vyprší. Jako druhý krok pak vývojářům nějaký čas trvá, než analyzují, proč se aktivace nezdařila, a znovu prozkoumají návrh, pokud s ním zjistí problém. Pokud zjistí, že s návrhem nebyl žádný problém, třetím krokem je přerozdělení soft forku, tentokrát pomocí BIP 8 s aktivací vlajkového dne: těžaři dostanou další šanci aktivovat návrh pomocí hash síly, ale pokud znovu selžou , měkká vidlice se aktivuje, když skončí tato druhá signalizační doba. (Během tohoto druhého signalizačního období může být prahová hodnota aktivace hash energie také časem postupně snížena, přispěvatel Bitcoin Core AJ Towns navrhuje.)

Tím, že se Corallo výslovně zaváže k přesunu BIP 8, pokud se ukáže, že s návrhem není nic v nepořádku, věří, že by strategie nabídla výhody BIP 9 bez negativního dopadu. Kód je zveřejněn během prvního signalizačního období, které musí každý zvážit, těžaři mohou koordinovat plynulý upgrade, pokud se tak rozhodnou, a bez nucené aktivace mohou vývojáři věnovat svůj čas přehodnocení návrhu, pokud aktivace zpočátku selže. Mezitím by horníci měli z blokování upgradu bez dobrého důvodu mnohem méně, protože každý ví, že se nakonec aktivuje.

Hlavním argumentem proti aktivaci Modern Soft Fork Activation je, že bez spolupráce s horníky by proces trval relativně dlouho a někteří považují krok BIP 9 za ztrátu času. Původní návrh společnosti Corallo zahrnuje jeden rok signalizace BIP 9, poté následuje šest měsíců na nové posouzení a nakonec dva roky signalizace BIP 8 před automatizovanou aktivací: celkem tři a půl roku. I když tato časová osa samozřejmě ještě není vytesána do kamene, přílišné zkrácení různých kroků by ponechalo méně času na nové posouzení a / nebo upgrade (zvýšení rizika rozdělení sítě).

Kvůli dlouhé době do potenciální vynucené aktivace někteří také tvrdí, že těžaři se mohou nakonec pokusit získat nějaký politický vliv: mohou upgrade odložit o roky.

BIP 8 + BIP 91

Další nedávný návrh, který koluje technologickými kanály bitcoinu, je možná nejlépe popsán jako trochu fúze mezi BIP 8 a Modern Soft Fork Activation, alespoň v duchu. Nepojmenovaný návrh by zavedl dlouhé signalizační období BIP 8, možná tak dlouho, jak bude aktivována společnost Modern Soft Fork Activation tři a půl roku, po které se spustí vynucená signalizace. Pokud se však po (řekněme) jednom roce aktualizace ještě neaktivovala, vývojářům by nějaký čas trvalo přehodnotit návrh, jako by to bylo u Modern Soft Fork Activation.

Pokud vývojáři nenajdou s návrhem žádný problém a místo toho by dospěli k závěru, že se jednoduše neaktivoval kvůli apatii horníka nebo kvůli jinému neplatnému důvodu, mohli by se rozhodnout nasadit novou soft vidličku ve stylu BIP 91, používanou během SegWit aktivace. To by účinně snížilo prahovou hodnotu hashového výkonu pro aktivaci, pravděpodobně by to urychlilo proces.

Pokud by na druhou stranu vývojáři našli problém s návrhem, mohli by nasadit novou soft vidličku, která by problém vyřešila, nebo dokonce úplně vrátit původní soft fork (v tomto případě Taproot). Za předpokladu tři a půl roku trvající časové osy Modern Soft Fork Activation do vynucené signalizace by měl zůstat dost času na to, aby se o to postaral.

Hlavním argumentem proti tomuto návrhu je pravděpodobně to, že není příliš elegantní nasadit měkkou vidličku, která v případě potřeby zruší další měkkou vidličku. Přesněji řečeno, vyžaduje to, aby těžaři a uživatelé upgradovali na nová vydání před dosažením termínů, nebo aby došlo k rozdělení sítě.

Sporks

A konečně, trochu odlehlý nápad, přispěvatel Bitcoin Core Jeremy Rubin navrhl, že koncept, který vynalezl, se jmenuje Probabilistic Bitcoin soft forks, nebo „Sporks,„Může být více kompatibilní s pobídkami než typické měkké vidličky vynucené hashovací silou.

Jádrem problému BIP 9, tvrdí Rubin, je to, že horníci mohou odkládat aktualizace bez vlastních nákladů. Pouhé odmítnutí signalizovat připravenost na upgrade je zdarma, což jim potenciálně nabízí politickou páku.

U Sporks se signál připravenosti již nepřijímá z bitů dat, která těžaři zahrnují do bloků, které těží, ale odvozuje se z hash záhlaví bloku: náhodně generovaného důkazu o práci, kterou vyprodukovali investováním času a zdrojů. Upgradované uzly by souhlasily s tím, že malá podmnožina platných hashů záhlaví bloku – statisticky k nalezení pouze každých šest měsíců – spustí aktualizaci.

Podle náhodnosti hashů by horník nekontroloval, zda produkuje pravidelné hash hlavičky bloku nebo hash hlavičky bloku aktivující upgrade; statisticky by náhodou jeden z nich chrlil sporadicky. Pokud tedy jeho investované prostředky generují hash záhlaví bloku aktivujícího upgrade, měl by dvě možnosti. Buď to publikujte v bitcoinové síti, získejte blokovou odměnu a aktivujte soft fork. Nebo zadržet publikování, v našem příkladu zdržet soft vidličku v průměru asi o šest měsíců… ale přitom se také vzdát blokové odměny. Zpoždění aktualizace by znamenalo značné náklady.

Hlavním problémem Sporks právě teď je pravděpodobně to, že se jedná o relativně nový nápad, který dosud nebyl vyvinut – natož otestován ve volné přírodě. Někteří považují tento koncept za zajímavý, ale zatím není nejpravděpodobnějším uchazečem o aktivaci Taproot.

Poznámka autora: Debata o aktivaci soft fork (a konkrétně o aktivaci Taproot) se mění; toto není vyčerpávající přehled různých návrhů na upgrade, zejména pokud jde o varianty návrhů s alternativními parametry a dalšími vylepšeními, a všechny jejich výhody a nevýhody.

Aktualizace

Další myšlenkou, která získává určitou pozornost od doby, kdy byl napsán tento článek (většinou), je nejprve nasadit BIP 8 s relativně dlouhou signalizační periodou (řekněme dva roky), nakonfigurovanou bez nucené signalizace na konci této signalizační periody. To umožňuje těžařům aktivovat měkkou vidličku relativně normálně, jak tomu bylo v minulosti několikrát. Pokud se však po určité době (řekněme šesti měsících) soft fork neaktivuje a nezdá se, že by to mělo dobrý důvod pro zpoždění, lze uvolnit nového klienta s konfigurací BIP 8, která vynutí signalizaci v blízkosti konec stávající signalizační periody nebo dříve. Za předpokladu, že většina těžařů poté aktivuje soft fork buď před nebo během této doby vynucené signalizace, obě sady uzlů BIP 8 (s konfigurací vynucené signalizace a bez ní) by vynucovaly soft fork při aktivaci.