Taproot, en foreslått oppgradering av protokollen som vil forbedre Bitcoins personvern og fleksibilitet, er i sine sene stadier av utvikling. Bitcoin Core-bidragsytere er enige om at oppgraderingen vil være til fordel for Bitcoin, og så langt ser det ut til å være ønsket velkommen av det bredere Bitcoin-økosystemet også. Det er derfor sannsynlig at Taproot vil komme seg inn i en Bitcoin Core-utgivelse, med andre Bitcoin-implementeringer muligens å følge.

Men ett spørsmål gjenstår: hvordan skal Bitcoin-nettverket selv oppgradere? Taproot er en konsensusprotokollendring, noe som betyr at Bitcoin-noder på en eller annen måte må bytte fra de gamle reglene til de nye reglene uten å splitte nettverket i fraksjoner som håndhever forskjellige regler. Av ulike grunner har dette tidligere noen ganger vist seg å være en utfordring.

Nå vurderes forbedrede strategier for å aktivere protokolloppgraderinger.

Tidligere myke gafler og BIP 9

Den gode nyheten er at Taproot vil være en myk gaffel. Denne typen oppgradering legger til eller strammer inn reglene – i motsetning til en hard gaffel som fjerner eller løsner reglene. Det fine med å legge til eller stramme inn regler er at alt som en oppgradert node anser som gyldig, en ikke-oppgradert node som også er gyldig. (Hvis en gammel node godtar begge transaksjonstypene A og B, men nye regler bare tillater transaksjonstype A, vil den gamle noden forbli kompatibel i et nettverk som håndhever de nye reglene.)

Bitcoins tidligste myke gafler ble aktivert gjennom flaggdager. Utviklere (spesielt Satoshi Nakamoto) innebygde en fremtidig dato i koden til en ny Bitcoin-programvareklientutgivelse, og spesifiserte et tidspunkt hvor oppgraderte noder ville håndheve de nye reglene. Gruvearbeidere og brukere ble oppfordret til å oppgradere før den datoen for å unngå splittelser i nettverket. (Som en side, i disse dager, var gruvearbeidere og brukere oftere de samme menneskene enn de er i dag.)

Siden ikke-oppgraderte noder forblir kompatible med nye regler, er en praktisk fordel med myke gafler at hvis et flertall av hashkraft tvinger oppgraderingen, finner hele Bitcoin-nettverket konsensus om deres versjon av blockchain. Dette betyr også at det er mindre presserende behov for at alle noder oppgraderes umiddelbart når de nye protokollreglene håndheves, noe som gir brukerne en viss fleksibilitet. (Selv om brukerne oppfordres til å oppgradere likevel; de er til slutt de som håndhever de nye reglene ved å avvise transaksjoner og blokkeringer som bryter dem.)

Siden rundt 2012 har myke gafler i økende grad benyttet hashkraft som en koordineringsmekanisme for å koordinere bytte til nye regler. Ved å legge inn litt data i blokkene sine, kan gruvearbeidere signalisere til andre gruvearbeidere og resten av nettverket at de oppgraderte programvaren, og dermed er klare til å håndheve de nye reglene. Når nok hash-kraft signaler støtter, utløses alle oppgraderte noder for å håndheve de nye reglene.

I løpet av noen få oppgraderinger utviklet denne strategien seg til Bitcoin Improvement Proposal 9 (BIP 9). BIP 9 var for eksempel mekanismen som ble brukt til å aktivere Bitcoins siste myke gaffeloppgradering, Segregated Witness (SegWit). Gruvearbeidere fikk et år på seg for å aktivere oppgraderingen, og krevde 95 prosent av blokkene innen ethvert vanskelighetsintervall for å inkludere en beredskapssignalbit. Hvis dette etter et år ikke hadde skjedd, ville aktiveringsperioden utløpe, og oppgraderingen ville ha mislyktes. (Det kunne da selvfølgelig rett og slett prøves igjen.)

For SegWit spilte imidlertid ikke BIP 9 greit. Som med noen av de tidligere oppgraderingene, kom nok ikke noen gruvearbeidere opp til å oppgradere på grunn av apati: det er ofte ikke et veldig stort incitament for gruvearbeidere til å oppgradere raskt. Men et større problem var at noen gruvearbeidere hadde forstått signalprosessen som en slags avstemning om oppgraderingen, der de i stedet for å signalisere beredskap (eller ikke) ville signalisere støtte for det. Verre, noen gruvearbeidere endte opp med å bruke denne “avstemningen” for å blokkere oppgraderingen for å prøve å få politisk innflytelse over Bitcoin-utviklingsprosessen, og / eller de “stemte” mot oppgraderingen for å skjult dra nytte av en særegenhet i Bitcoin protokoll som oppgraderingen vil fikse.

Etter en lengre periode med intens drama aktiverte SegWit til slutt, men bare etter at alternative Bitcoin-klienter inkluderte nye aktiveringsordninger. BIP 148, inkludert i BIP 148-klienten som drives av noen brukere, ble programmert til å bare akseptere blokkeringssignaleringsstøtte for protokolloppgraderingen fra en flaggdag. I mellomtiden senket BIP 91, inkludert i btc1-klienten og drevet av gruvearbeidere like før BIP 148-flaggdagen, effektivt hashkraftbehovet fra 95 prosent til 75 prosent. Overfor et potensielt delt nettverk og et mulig inntektstap, innrømmet de hindrende gruvearbeiderne. Men for de fleste Bitcoin Core-utviklere hadde BIP 9 avslørt å være en suboptimal løsning, og de begynte å tenke på alternativer.

BIP 8

BIP 8 var et tidlig alternativ for BIP 9, foreslått av BIP 148-forfatteren Shaolinfry og Bitcoin Knots og Bitcoin Core-bidragsyter Luke-jr. Det lignet opprinnelig BIP 9, men med en avgjørende forskjell: i stedet for at oppgraderingen mislyktes etter et år med utilstrekkelig hash-strømstøtte, ville den gjøre det stikk motsatte og aktivere den myke gaffelen på det tidspunktet. I likhet med en flaggdag, ville alle oppgraderte noder fra da av begynne å håndheve de nye reglene. Gruvearbeidere som fremdeles ikke hadde klart å oppgradere, risikerer gruvedrift som oppgraderte gruvearbeidere og brukere vil avvise.

Hovedideen bak BIP 8 er at – forutsatt selvfølgelig at brukere oppgraderer – kan gruvearbeidere ikke blokkere den myke gaffelen og kan derfor ikke bruke denne innflytelsen til deres fordel. De kan øke aktiveringen og hjelpe til med å koordinere en jevn oppgradering av protokollen, men oppgraderingen vil til slutt skje selv om de ikke aktiverer den selv.

Et nyere utkast til BIP 8 inkluderer noen bemerkelsesverdige endringer. For det første tillater BIP 8 at noder kan konfigureres for to forskjellige policyer når signalperioden er i ferd med å utløpe: tvungen aktivering, som forklart i de to foregående avsnittene, eller ingen tvungen aktivering, som med BIP 9. Videre, i stedet for å aktivere oppgraderer seg selv, noder (hvis det er konfigurert) faktisk håndhever signalering for oppgraderingen. Blokker som ikke signaliserer støtte for oppgraderingen blir deretter avvist, og garanterer fremdeles oppgraderingen, i det minste for de oppgraderte nodene. Kombinasjonen av disse to endringene har den interessante egenskapen at hvis et flertall av all Bitcoin-hashkraft er tvunget til å signalisere støtte for oppgraderingen, vil til og med BIP 8-noder som ikke er konfigurert for å håndheve signalering, følge med oppgraderingen..

Et argument mot BIP 8, og dens tvangssignalering (eller automatisk aktivering) spesifikt, er at det kan være risikabelt, spesielt på en kortere tidslinje. Hvis et hash-kraftflertall og i det minste noen brukere ikke oppgraderer, kan denne ordningen dele nettverket mellom oppgraderte og ikke-oppgraderte noder. Forutsatt at de fleste brukere støtter oppgraderingen, vil dette sannsynligvis løse til fordel for den oppgraderte delen av nettverket til slutt. Men ikke-oppgraderte brukere risikerer å miste penger i mellomtiden, mens ikke-oppgraderte gruvearbeidere vil kaste bort hashkraft til skade for Bitcoins sikkerhet.

Denne risikoen motvirkes sannsynligvis best ved å tilby nok tid til å oppgradere. Dessverre er ikke alle enige om hvor mye tid som er nok; noen mener tvungen signalering kan starte innen et år, andre mener det bør ta flere år.

En annen komplikasjon med BIP 8 er å sette standarder for tvangssignalering. Hvis tvangssignalering er slått av som standard, kan brukere finne seg ukoordinerte, noe som øker risikoen for nettverksdeling. Hvis tvangssignalering derimot er valgt som standard i en Bitcoin Core-utgivelse, garanterer den historisk utbredte adopsjonen av Bitcoin Core praktisk talt at oppgraderingen vil skje. Noen mener dette vil gi Bitcoin Core-utviklere for mye innflytelse over Bitcoins protokollregler. BIP 8 medforfatter Luke-jr foretrekker at BIP 8 bare distribueres gjennom spesielle klienter, i likhet med BIP 148-klienten.

Andre hevder at Bitcoin Core-utviklere alltid frigjør programvare etter eget skjønn, samtidig som brukernes etterspørsel i tankene og unngås omstridte oppgraderinger; innstilling av BIP 8-standard bør ikke være noe unntak fra denne policyen. Hvis noen tross alt er uenige i valgene Bitcoin Core-utviklere tar, kan de ganske enkelt velge å ikke oppgradere til en ny utgivelse eller til og med forkaste Bitcoin Core-koden for å starte en konkurrerende klient helt..

Moderne aktivering av myk gaffel

Mens Bitcoin Core-utviklere virkelig prøver å ta hensyn til brukernes etterspørsel og prøver å unngå omstridte oppgraderinger, er ikke alle overbevist om at dette alltid er fullt mulig. Kanskje bekymringer om en foreslått oppgradering bare kommer til overflaten når programvaren er distribuert i en ny utgivelse. Kanskje oppstår helt nye problemer etter denne utgivelsen. Eller kanskje savnet Bitcoin Core-utviklere rett og slett noe.

Dette er en av grunnene til at Bitcoin Core-bidragsyter Matt Corallo foreslo en strategi som ble kalt “Moderne aktivering av myk gaffel.”Modern Soft Fork Activation består av tre trinn, som i hovedsak realiserer en kombinasjon av BIP 9 (eller: BIP 8 uten tvungen signalering) og BIP 8 med aktivering av flaggdag (selv om tvungen signalering også kan være et alternativ).

Som det første trinnet, ville BIP 9 tillate gruvearbeidere å aktivere den myke gaffelen gjennom hashkraft. Hvis gruvearbeidere ikke aktiverer det om (si) et år, utløper det første aktiveringsvinduet. Så, som det andre trinnet, tar utviklere litt tid å analysere hvorfor aktivering mislyktes, og revurderer forslaget hvis de finner bekymring for det. Hvis de finner ut at det ikke var noe problem med forslaget, er det tredje trinnet imidlertid omplassering av den myke gaffelen, denne gangen ved hjelp av BIP 8 med aktivering av flaggdag: gruvearbeidere får en ny sjanse til å aktivere forslaget med hashkraft, men hvis de mislykkes igjen , aktiveres den myke gaffelen når denne andre signalperioden slutter. (I løpet av denne andre signalperioden kan terskelen for aktivering av hash også reduseres gradvis over tid, Bitcoin Core-bidragsyter AJ Towns foreslår.)

Ved eksplisitt å forplikte seg til BIP 8-omplassering hvis det viser seg at det ikke er noe galt med forslaget, mener Corallo at strategien vil gi fordelene med BIP 9 uten ulempen. Koden blir lagt ut der i løpet av den første signalperioden for alle å vurdere, gruvearbeidere kan koordinere en jevn oppgradering hvis de ønsker det, og uten tvungen aktivering kan utviklere ta seg tid til å revurdere forslaget hvis aktivering i utgangspunktet mislykkes. I mellomtiden vil gruvearbeidere ha mye mindre å tjene på å blokkere oppgraderingen uten god grunn, ettersom alle vet at den til slutt vil aktivere uansett.

Hovedargumentet mot Modern Soft Fork Activation er at prosessen uten relativt gruvearbeid vil ta relativt lang tid, og noen anser BIP 9-trinnet som bortkastet tid. Corallos opprinnelige forslag inkluderer ett år med BIP 9-signalering, etterfulgt av seks måneder å revurdere, og til slutt to år med BIP 8-signalering før automatisk aktivering: totalt tre og et halvt år. Selv om denne tidslinjen selvsagt ikke er satt i stein ennå, vil det forkorte de forskjellige trinnene med for mye, gi mindre tid til revurdering og / eller oppgradering (noe som øker risikoen for nettverksdeling).

På grunn av den lange tiden til potensiell tvungen aktivering, hevder noen også at gruvearbeidere tross alt kan prøve å få litt politisk innflytelse: de kan forsinke oppgraderingen i årevis.

BIP 8 + BIP 91

Et annet, nylig forslag som sirkulerer gjennom Bitcoins teknologikanaler, beskrives kanskje best som en fusjon mellom BIP 8 og Modern Soft Fork Activation, i det minste i ånden. Det ikke navngitte forslaget ville distribuere en lang BIP 8-signalperiode, kanskje så lenge Modern Soft Fork Activation er tre og et halvt år, hvoretter tvungen signalutløser. Men hvis oppgraderingen etter (si) ett år ikke ble aktivert ennå, ville utviklere ta litt tid å revurdere forslaget, slik de ville gjort med Modern Soft Fork Activation.

Hvis utviklere ikke fant noe problem med forslaget, og i stedet skulle konkludere med at det ganske enkelt ikke hadde blitt aktivert på grunn av gruvearbeiders apati eller en annen ugyldig grunn, kunne de velge å distribuere en ny myk gaffel i stil med BIP 91, brukt under SegWit. aktivering. Dette vil effektivt senke terskelen for hashkraft for aktivering, antagelig å øke prosessen.

Hvis utviklere derimot tross alt vil finne et problem med forslaget, kan de distribuere en ny myk gaffel som vil løse problemet, eller til og med angre den originale myke gaffelen (i dette tilfellet Taproot) helt. Forutsatt at Modern Soft Fork Activation har tre og et halvt års tidslinje til tvangssignalering, burde det være nok tid igjen til å ta seg av dette.

Hovedargumentet mot dette forslaget er sannsynligvis at det ikke er veldig elegant å distribuere en myk gaffel som om nødvendig angrer en annen myk gaffel. Mer konkret krever det at gruvearbeidere og brukere oppgraderer til nye utgivelser før fristene er nådd, eller risikerer å splitte nettverket.

Sporks

Til slutt, som litt av en outlier idé, foreslo Bitcoin Core-bidragsyter Jeremy Rubin at et konsept han oppfant, kalt Probabilistic Bitcoin soft gafler, eller “Sporks,”Kan være mer insentivkompatibelt enn typiske myke gafler med hashkraft.

Hjertet av problemet med BIP 9, hevder Rubin, er at gruvearbeidere kan forsinke oppgraderinger uten egne kostnader. Bare det å nekte å signalisere beredskap for en oppgradering er gratis, mens det potensielt gir dem politisk innflytelse.

Med Sporks er beredskapssignalet ikke lenger hentet fra litt data som gruvearbeidere inkluderer i blokkene de utvider, men avledet fra blokkoverskriften: det tilfeldig genererte beviset på arbeid de produserte ved å investere tid og ressurser. Oppgraderte noder vil være enige om at et lite delsett med gyldige blokkeringshodehasher – statistisk sett bare å finne hver sjette måned eller så – ville utløse oppgraderingen.

I henhold til tilfeldigheten av hasj, ville en gruvearbeider ikke kontrollere om han produserer vanlige blokk header hashes eller oppgraderingsaktiverende block header hashes; han ville bare tilfeldigvis slite en av de sistnevnte sporadisk. Så hvis hans investerte ressurser tilfeldigvis genererer en oppgraderingsaktiverende blokkhode-hash, ville han ha to valg. Enten, publiser det til Bitcoin-nettverket, tjen blokkbelønningen, og aktiver den myke gaffelen. Eller hold tilbake fra publisering, og forsink den myke gaffelen med omtrent seks måneder i gjennomsnitt i vårt eksempel … men samtidig gi opp blokkeringsbelønningen. Forsinkelse av oppgraderingen vil koste en betydelig kostnad.

Hovedproblemet med Sporks akkurat nå er sannsynligvis at det er en relativt ny ide som ikke har blitt utviklet ennå – enn si testet i naturen. Mens noen anser konseptet som interessant, er det foreløpig ikke den mest sannsynlige kandidaten til Taproot-aktivering.

Forfatterens merknad: Debatten om aktivering av myk gaffel (og Taproot-aktivering spesifikt) er i flyt; dette er en ikke-uttømmende oversikt over de forskjellige oppgraderingsforslagene, spesielt når det gjelder varianter av forslagene med alternative parametere og andre justeringer, og alle fordeler og ulemper.

Oppdater

En annen idé, som har fått litt trekkraft siden denne artikkelen ble skrevet (for det meste), er å først distribuere BIP 8 med en relativt lang signalperiode (for eksempel to år), konfigurert uten tvungen signalering på slutten av denne signalperioden. Dette gjør at gruvearbeidere kan aktivere den myke gaffelen relativt normalt, slik de har gjort flere ganger tidligere. Hvis den myke gaffelen etter en tid (for eksempel seks måneder) ikke er aktivert, og det ikke ser ut til å være en god grunn til forsinkelsen, kan en ny klient frigjøres med BIP 8 konfigurert til å tvinge signalisering nær slutten av den eksisterende signalperioden, eller før. Forutsatt at de fleste gruvearbeidere deretter aktiverer den myke gaffelen enten før eller under denne tvangssignaliseringsperioden, vil begge settene med BIP 8-noder (med og uten tvangssignaleringskonfigurasjonen) håndheve den myke gaffelen ved aktivering.