Taproot, predlagana nadgradnja protokola, ki bi izboljšala zasebnost in prožnost Bitcoina, je v pozni fazi razvoja. Prispevci Bitcoin Core se strinjajo, da bi nadgradnja koristila Bitcoinu, in zaenkrat se zdi, da jo na splošno pozdravlja tudi širši ekosistem Bitcoin. Zato je verjetno, da se bo Taproot prebil v izdajo Bitcoin Core, ki bi ji lahko sledile tudi druge implementacije Bitcoinov.

A eno vprašanje ostaja: kako naj se Bitcoin omrežje samo nadgradi? Taproot je soglasna sprememba protokola, kar pomeni, da morajo bitcoin vozlišča nekako preiti s starih pravil na nova, ne da bi omrežje razdelili na frakcije, ki uveljavljajo drugačna pravila. Iz različnih razlogov se je to v preteklosti včasih izkazalo za izziv.

Zdaj se razmišlja o izboljšanih strategijah za aktiviranje nadgradenj protokola.

Prejšnje mehke vilice in BIP 9

Dobra novica je, da bo Taproot mehka vilica. Ta vrsta nadgradnje dodaja ali zaostruje pravila – v nasprotju s trdimi vilicami, ki pravila odstranijo ali razrahljajo. Lepo pri dodajanju ali zaostrovanju pravil je, da vse, kar nadgrajeno vozlišče šteje za veljavno, velja tudi za nenadgrajeno vozlišče. (Če staro vozlišče sprejme obe vrsti transakcij A in B, nova pravila pa dovoljujejo samo vrsto transakcije A, bo staro vozlišče ostalo združljivo v omrežju, ki uveljavlja nova pravila.)

Najzgodnejše mehke vilice Bitcoina so bile aktivirane v dneh zastave. Razvijalci (zlasti Satoshi Nakamoto) so v kodo nove izdaje odjemalca programske opreme Bitcoin vdelali prihodnji datum, pri čemer so določili trenutek, ko bodo nadgrajena vozlišča uveljavila nova pravila. Rudarje in uporabnike smo spodbujali, naj nadgradijo pred tem datumom, da se izognejo razcepom omrežja. (Poleg tega so bili v tistih časih rudarji in uporabniki pogosteje isti ljudje kot danes.)

Ker nenadgrajena vozlišča ostajajo združljiva z novimi pravili, je priročna prednost mehkih vilic ta, da če večina razpršene moči uveljavi nadgradnjo, celotno omrežje Bitcoin najde soglasje o svoji različici verige blokov. To tudi pomeni, da ni nujno nujno, da se vsa vozlišča takoj nadgradijo, ko se uveljavijo nova pravila protokola, kar uporabnikom omogoča določeno prilagodljivost. (Čeprav uporabnike kljub temu spodbujamo, da nadgradijo; navsezadnje oni uveljavljajo nova pravila z zavračanjem transakcij in blokov, ki jih prekinejo.)

Od približno leta 2012 mehke vilice vedno bolj uporabljajo hash power kot koordinacijski mehanizem za usklajevanje prehoda na nova pravila. Z vdelavo malo podatkov v svoje bloke lahko rudarji drugim rudarjem in ostalemu omrežju sporočijo, da so nadgradili svojo programsko opremo in so tako pripravljeni uveljaviti nova pravila. Ko podpre dovolj signalov zgoščevalne moči, se za uveljavitev novih pravil sprožijo vsa nadgrajena vozlišča.

V nekaj nadgradnjah se je ta strategija razvila v predlog za izboljšanje Bitcoin 9 (BIP 9). BIP 9 je bil na primer mehanizem, ki se uporablja za aktiviranje zadnje Bitcoin-ove nadgradnje soft fork, Segregated Witness (SegWit). Rudarji so imeli na voljo eno leto za aktiviranje nadgradnje, pri čemer je bilo treba 95 odstotkov blokov v katerem koli težavnostnem intervalu vključiti bit signala pripravljenosti. Če se po enem letu to ne bi zgodilo, bi se obdobje aktiviranja izteklo in nadgradnja ne bi uspela. (Potem bi ga lahko preprosto preprosto poskusili znova.)

Za SegWit pa BIP 9 ni potekal gladko. Kot pri nekaterih prejšnjih nadgradnjah tudi nekateri rudarji nekaj časa verjetno niso prišli do nadgradnje zaradi apatije: rudarji pogosto nimajo velike spodbude za hitro nadgradnjo. Toda večja težava je bila v tem, da so nekateri rudarji postopek signalizacije razumeli kot nekakšno glasovanje o nadgradnji, kjer namesto da bi signalizirali pripravljenost, (ali ne) signalizirajo podporo zanj. Še huje, nekateri rudarji so na koncu s tem “glasovanjem” blokirali nadgradnjo, da bi poskušali pridobiti politični vzvod nad postopkom razvoja Bitcoina, in / ali so “glasovali” proti nadgradnji, da bi prikrito imeli koristi od Bitcoin-a protokol, ki bi ga nadgradnja popravila.

Po daljšem obdobju močne drame se je SegWit na koncu aktiviral, vendar šele potem, ko so alternativni Bitcoin odjemalci vključili nove aktivacijske sheme. BIP 148, vključen v odjemalca BIP 148, ki ga izvajajo nekateri uporabniki, je bil programiran tako, da sprejema le blokovske signalizacijske podpore za nadgradnjo protokola, ki se začnejo na dan zastave. Medtem je BIP 91, vključen v odjemalca btc1 in ga rudarji vodijo tik pred dnevom zastave BIP 148, dejansko znižal potrebo po moči razprševanja s 95 na 75 odstotkov. Rudarji, ki ovirajo, so se soočili z morebitno razdeljeno mrežo in morebitno izgubo dohodka. Toda za večino razvijalcev Bitcoin Core se je BIP 9 izkazal za neoptimalno rešitev in začeli so razmišljati o drugih možnostih.

BIP 8

BIP 8 je bila zgodnja alternativa za BIP 9, ki jo je predlagal avtor BIP 148 Shaolinfry in Bitcoin Knots ter sodelavec Bitcoin Core Luke-jr. Sprva je spominjal na BIP 9, vendar z eno ključno razliko: namesto da bi nadgradnja propadla po letu nezadostne podpore hash power, bi storila ravno nasprotno in v tistem trenutku aktivirala soft fork. Podobno kot dan zastave bi vsa nadgrajena vozlišča od takrat naprej začela uveljavljati nova pravila. Rudarji, ki jih še vedno ne bi nadgradili, bi tvegali rudarske bloke, ki bi jih nadgrajeni rudarji in uporabniki zavrnili.

Glavna ideja BIP 8 je, da – ob predpostavki, da uporabniki nadgrajujejo – rudarji ne morejo blokirati mehke vilice in zato tega vzvoda ne morejo uporabiti v svojo korist. Lahko pospešijo aktivacijo in pomagajo pri usklajevanju nemotene nadgradnje protokola, vendar se bo nadgradnja sčasoma zgodila, tudi če je sami ne aktivirajo.

Novejši osnutek BIP 8 vključuje nekaj pomembnih sprememb. Prvič, BIP 8 omogoča konfiguriranje vozlišč za dva različna pravilnika, ko se bo izteklo obdobje signalizacije: prisilno aktiviranje, kot je razloženo v prejšnjih dveh odstavkih, ali nobeno prisilno aktiviranje, kot pri BIP 9. Poleg tega namesto aktiviranja sama nadgradi, vozlišča (če so tako konfigurirana) dejansko uveljavijo signalizacijo nadgradnje. Bloki, ki ne signalizirajo podpore za nadgradnjo, se nato zavrnejo, zato še vedno zagotavljajo nadgradnjo, vsaj za nadgrajena vozlišča. Kombinacija teh dveh sprememb ima zanimivo lastnost, da če je večina vseh Bitcoin hash moči prisiljena signalizirati podporo za nadgradnjo, bodo skupaj z nadgradnjo šla tudi vozlišča BIP 8, ki niso konfigurirana za uveljavljanje signalizacije..

Argument proti BIP 8 in njegovemu prisilnemu signaliziranju (ali samodejnemu aktiviranju) je, da je lahko tvegan, zlasti na krajši časovni osi. Če večina zgoščene moči in vsaj nekateri uporabniki ne nadgradijo, lahko ta shema razdeli omrežje na nadgrajena in nenadgrajena vozlišča. Ob predpostavki, da večina uporabnikov podpira nadgradnjo, bi se to sčasoma verjetno razrešilo v prid nadgrajenega dela omrežja. Toda nenadgrajeni uporabniki bi v tem času tvegali izgubo sredstev, medtem ko bi nenadgrajeni rudarji izgubljali razpršeno moč na škodo varnosti Bitcoinov..

Verjetno je temu tveganju najbolje odpraviti ponudbo dovolj časa za nadgradnjo. Žal se vsi ne strinjajo, koliko časa je dovolj; nekateri menijo, da bi se prisilno signaliziranje lahko začelo v enem letu, drugi pa menijo, da bi moralo trajati nekaj let.

Drug zaplet pri BIP 8 je nastavitev privzetih vrednosti za prisilno signalizacijo. Če je prisilna signalizacija privzeto izklopljena, se lahko uporabniki znajdejo neusklajeno in s tem povečajo tveganje za razcep omrežja. Če je po drugi strani prisilna signalizacija izbrana kot privzeta v izdaji Bitcoin Core, zgodovinsko razširjeno sprejemanje Bitcoin Core praktično zagotavlja, da se bo nadgradnja zgodila. Nekateri verjamejo, da bi to razvijalcem Bitcoin Core omogočilo preveč vpliva na pravila protokola Bitcoin. Soavtor BIP 8 Luke-jr raje uporablja BIP 8 samo prek posebnih odjemalcev, podobno kot odjemalec BIP 148.

Drugi trdijo, da razvijalci Bitcoin Core vedno izdajo programsko opremo po svoji najboljši presoji, hkrati pa upoštevajo povpraševanje uporabnikov in se izogibajo spornim nadgradnjam; nastavitev privzetih vrednosti BIP 8 ne sme biti nobena izjema od tega pravilnika. Če se kdo kljub vsemu ne strinja z odločitvami razvijalcev Bitcoin Core, se lahko preprosto odloči, da ne bo nadgradil na novo različico ali celo razkril kodo Bitcoin Core, da bo sploh zagnal konkurenčno stranko.

Sodobna aktivacija mehkih vilic

Medtem ko razvijalci Bitcoin Core resnično želijo upoštevati povpraševanje uporabnikov in se poskušajo izogniti spornim nadgradnjam, niso vsi prepričani, da je to vedno povsem mogoče. Morda se pomisleki glede predlagane nadgradnje pojavijo šele, ko je programska oprema uvedena v novi izdaji. Morda se po tej izdaji pojavijo povsem nova vprašanja. Ali pa so razvijalci Bitcoin Core preprosto nekaj zamudili.

To je eden od razlogov, zakaj je sodelavec Bitcoin Core Matt Corallo predlagal strategijo, imenovano “Sodobna aktivacija mehkih vilic.”Sodobna aktivacija mehkih vilic je sestavljena iz treh korakov, ki v bistvu uresničujejo kombinacijo BIP 9 (ali: BIP 8 brez prisilne signalizacije) in BIP 8 z aktivacijo dneva zastave (čeprav bi bila prisilna signalizacija lahko tudi možnost).

Kot prvi korak bi BIP 9 rudarjem omogočil aktiviranje mehkih vilic s pomočjo zgoščevalne moči. Če ga rudarji ne aktivirajo v (recimo) enem letu, prvo okno za aktiviranje poteče. Nato razvijalci kot drugi korak vzamejo nekaj časa, da analizirajo, zakaj aktivacija ni uspela, in ponovno preučijo predlog, če ugotovijo, da je zaskrbljen. Če ugotovijo, da s predlogom ni bilo težav, pa je tretji korak prerazporeditev soft forka, tokrat z uporabo BIP 8 z aktivacijo dneva zastave: rudarji dobijo še eno priložnost, da predlog aktivirajo s hash power, če pa spet ne uspejo , mehka vilica se aktivira, ko se konča to drugo signalno obdobje. (V tem drugem signalnem obdobju se lahko tudi prag aktiviranja razpršene moči sčasoma postopoma znižuje, sodelavec Bitcoin Core AJ Towns predlaga.)

Z izrecno zavezo k prerazporeditvi BIP 8, če se izkaže, da s predlogom ni nič narobe, Corallo meni, da bi strategija ponudila prednosti BIP 9 brez negativne strani. Koda je tam objavljena v prvem signalnem obdobju, da jo lahko vsi razmislijo, rudarji lahko uskladijo nemoteno nadgradnjo, če se tako odločijo, in brez prisilnega aktiviranja si lahko razvijalci vzamejo čas, da premislijo o predlogu, če aktivacija na začetku ne uspe. Medtem bi rudarji brez blokiranja nadgradnje imeli nič manj koristi, saj vsi vedo, da se bo sčasoma vseeno aktivirala.

Glavni argument zoper sodobno aktiviranje mehkih vilic je, da bi brez sodelovanja rudarjev postopek trajal razmeroma dolgo, nekateri pa menijo, da je korak BIP 9 povsem izguba časa. Prvotni predlog podjetja Corallo vključuje eno leto signalizacije BIP 9, čemur sledi še šest mesecev za razmislek in na koncu dve leti signalizacije BIP 8 pred samodejnim aktiviranjem: skupaj tri leta in pol. Čeprav ta časovni načrt seveda še ni zasnovan, bi skrajšanje različnih korakov za preveč ostalo manj časa za ponovni premislek in / ali nadgradnjo (povečanje tveganja za razcep omrežja).

Zaradi dolgega časa do potencialne prisilne aktivacije nekateri trdijo tudi, da lahko rudarji kljub vsemu poskusijo pridobiti nekaj političnega vzvoda: nadgradnjo lahko odložijo za leta.

BIP 8 + BIP 91

Drugi nedavni predlog, ki kroži po Bitcoin-ovih tehnoloških kanalih, je mogoče najbolje opisati kot nekoliko združitev med BIP 8 in Modern Soft Fork Activation, vsaj v duhu. Neimenovani predlog bi uvedel dolgo signalno obdobje BIP 8, morda toliko kot tri leta in pol Modern Soft Fork Activation, po katerem se sproži prisilno signaliziranje. Če pa se po (recimo) enem letu nadgradnja še ne aktivira, bi razvijalci vzeli nekaj časa, da ponovno premislijo o predlogu, kot bi to storili z aktivacijo Modern Soft Fork.

Če razvijalci s predlogom ne bi našli težav in bi namesto tega ugotovili, da se preprosto ni aktiviral zaradi apatije rudarja ali drugega neveljavnega razloga, bi se lahko odločili za uvedbo novega soft vilice v stilu BIP 91, ki se uporablja med SegWit aktivacija. To bi učinkovito znižalo prag moči zgoščevanja za aktivacijo, kar naj bi pospešilo postopek.

Če bi po drugi strani razvijalci kljub vsemu našli težavo s predlogom, bi lahko namestili novo soft fork, ki bi odpravila težavo, ali celo razveljavili prvotno soft fork (v tem primeru Taproot). Ob predpostavki, da je tri leta in pol časovna premica Modern Soft Fork Activation do prisilne signalizacije, bi moralo ostati dovolj časa za to.

Glavni argument proti temu predlogu je verjetno ta, da ni preveč elegantno uporabiti mehke vilice, ki po potrebi razveljavijo še eno mehko vilico. Natančneje, zahteva, da rudarji in uporabniki nadgradijo nove izdaje, preden se dosežejo roki, ali tvegajo razdelitev omrežja.

Šporke

Nazadnje je sodelavec Bitcoin Coreja Jeremy Rubin kot nekoliko bolj nenavadna ideja predlagal, da je koncept, ki ga je izumil, imenoval probabilistične mehke vilice Bitcoin ali “Šporke,”Je morda bolj spodbudno združljiv kot tipične mehke vilice, ki jih poganja hash power.

Srž problema BIP 9, trdi Rubin, je, da lahko rudarji odlašajo z nadgradnjo brez lastnih stroškov. Preprosto zavrnitev sporočanja o pripravljenosti na nadgradnjo je brezplačna, medtem ko jim potencialno ponuja politični vzvod.

Pri programu Sporks signal za pripravljenost ni več vzet iz koščkov podatkov, ki jih rudarji vključujejo v bloke, ki jih rudarijo, ampak izhaja iz razpršilne glave glave bloka: naključno ustvarjenega dokaza o delu, ki so ga ustvarili z vlaganjem časa in virov. Nadgrajena vozlišča bi se strinjala, da bi majhna podmnožica veljavnih zgoščenih blokov blokov – statistično najdemo le vsakih šest mesecev – sprožila nadgradnjo.

V skladu z naključnostjo zgoščevanja rudar ne bi mogel nadzorovati, ali ustvarja običajna zgoščevanja glav blokov ali zgoščenja glav blokov, ki jih aktivira nadgradnja; statistično bi slučajno enega od slednjih izpustil občasno. Če torej njegova vložena sredstva ustvarijo zgoščevalno glavo glave bloka, ki aktivira nadgradnjo, bi imel dve možnosti. Ali ga objavite v Bitcoin omrežju, zaslužite nagrado za blok in aktivirajte soft fork. Ali pa zavrnite objavo, tako da soft fork v našem primeru v povprečju zakasnite za približno šest mesecev … vendar se pri tem odpovemo tudi blokovski nagradi. Zamuda pri nadgradnji bi imela znatne stroške.

Glavna težava Sporksa trenutno je verjetno ta, da gre za razmeroma novo idejo, ki še ni bila razvita – kaj šele preizkušena v naravi. Nekateri menijo, da je koncept zanimiv, vendar še vedno ni najverjetnejši kandidat za aktivacijo taproota.

Opomba avtorja: Debata o aktivaciji mehkih vilic (in o aktivaciji taproot posebej) je v toku; to je neizčrpen pregled različnih predlogov za nadgradnjo, zlasti ko gre za različice predlogov z nadomestnimi parametri in drugimi popravki ter vse njihove prednosti in slabosti.

Nadgradnja

Druga ideja, ki si je pridobila nekaj zanimanja, odkar je bil napisan ta članek (večinoma), je najprej uvesti BIP 8 z razmeroma dolgim ​​signalnim obdobjem (recimo dve leti), konfiguriranim brez prisilnega signaliziranja na koncu tega signalnega obdobja. To rudarjem omogoča, da mehko vilico aktivirajo razmeroma normalno, kot so to že večkrat storili. Če pa se čez nekaj časa (recimo šest mesecev) soft fork ne aktivira in se zdi, da ni utemeljenega razloga za zamudo, lahko sprostite novega odjemalca z BIP 8, konfiguriranim za prisilno signalizacijo v bližini konec obstoječega obdobja signalizacije ali prej. Ob predpostavki, da večina rudarjev nato aktivira soft fork pred ali med tem obdobjem prisilne signalizacije, bi oba sklopa vozlišč BIP 8 (z in brez konfiguracije prisilne signalizacije) sprožila soft fork ob aktivaciji..