Taproot, en foreslået protokolopgradering, der forbedrer Bitcoins privatliv og fleksibilitet, er i sine sene stadier af udvikling. Bitcoin Core-bidragydere er enige om, at opgraderingen vil være til gavn for Bitcoin, og indtil videre ser det generelt ud til at være hilst velkommen af det bredere Bitcoin-økosystem. Det er derfor sandsynligt, at Taproot vil komme ind i en Bitcoin Core-udgivelse med andre Bitcoin-implementeringer, der muligvis følger.
Men et spørgsmål er stadig: hvordan skal Bitcoin-netværket selv opgradere? Taproot er en konsensusprotokolændring, hvilket betyder, at Bitcoin-noder på en eller anden måde skal skifte fra de gamle regler til de nye regler uden at opdele netværket i fraktioner, der håndhæver forskellige regler. Af forskellige årsager har dette tidligere undertiden vist sig at være en udfordring.
Forbedrede strategier til aktivering af protokolopgraderinger overvejes nu.
Tidligere blødgafler og BIP 9
Den gode nyhed er, at Taproot vil være en blød gaffel. Denne type opgradering tilføjer eller strammer reglerne – i modsætning til en hård gaffel, der fjerner eller løsner reglerne. Det pæne ved at tilføje eller stramme regler er, at alt, hvad en opgraderet node betragter som gyldig, en ikke-opgraderet node også betragter som gyldig. (Hvis en gammel node accepterer begge transaktionstyper A og B, men nye regler kun tillader transaktionstype A, vil den gamle node forblive kompatibel på et netværk, der håndhæver de nye regler.)
Bitcoins tidligste bløde gafler blev aktiveret gennem flagdage. Udviklere (især Satoshi Nakamoto) indlejrede en fremtidig dato i koden til en ny Bitcoin-softwareklientudgivelse og angav et tidspunkt, hvor opgraderede noder ville håndhæve de nye regler. Minearbejdere og brugere blev opfordret til at opgradere inden denne dato for at undgå netopdelinger. (Som en side, i disse dage, var minearbejdere og brugere oftere de samme mennesker, end de er i dag.)
Da ikke-opgraderede noder forbliver kompatible med nye regler, er en praktisk fordel ved bløde gafler, at hvis et flertal af hash-kraft tvinger opgraderingen, finder hele Bitcoin-netværket konsensus om deres version af blockchain. Dette betyder også, at der er mindre presserende behov for, at alle noder opgraderes med det samme, når de nye protokolregler håndhæves, hvilket giver brugerne en vis fleksibilitet. (Selvom brugerne opfordres til at opgradere alligevel; de er i sidste ende dem, der håndhæver de nye regler ved at afvise transaktioner og blokke, der bryder dem.)
Siden omkring 2012 har bløde gafler i stigende grad brugt hashkraft som en koordineringsmekanisme til at koordinere en skift til nye regler. Ved at indlejre lidt data i deres blokke kan minearbejdere signalere til andre minearbejdere og resten af netværket om, at de opgraderede deres software og dermed er klar til at håndhæve de nye regler. Når der er tilstrækkeligt med hash-effektsignaler, udløses alle opgraderede noder for at håndhæve de nye regler.
I løbet af nogle få opgraderinger udviklede denne strategi sig til Bitcoin Improvement Proposal 9 (BIP 9). BIP 9 var for eksempel den mekanisme, der blev brugt til at aktivere Bitcoins sidste soft fork-opgradering, Segregated Witness (SegWit). Minearbejdere fik et år til at aktivere opgraderingen, hvilket krævede 95 procent af blokke inden for ethvert vanskelighedsinterval for at inkludere en beredskabssignalbit. Hvis dette efter et år ikke var sket, ville aktiveringsperioden udløbe, og opgraderingen ville mislykkes. (Det kunne så naturligvis simpelthen blive prøvet igen.)
For SegWit spillede BIP 9 imidlertid ikke glat. Som med nogle af de tidligere opgraderinger kom nogle minearbejdere sandsynligvis ikke til at opgradere i nogen tid på grund af apati: der er ofte ikke et meget stort incitament for minearbejdere til at opgradere hurtigt. Men et større problem var, at nogle minearbejdere var kommet til at forstå signalprocessen som en slags afstemning om opgraderingen, hvor de (eller ikke) ville signalere støtte til den i stedet for at signalere parathed. Værre, nogle minearbejdere endte med at bruge denne “stemme” til at blokere opgraderingen for at forsøge at få politisk gearing over Bitcoin-udviklingsprocessen, og / eller de “stemte” imod opgraderingen for skjult at drage fordel af en besynderlighed i Bitcoin protokol, som opgraderingen vil rette.
Efter en længere periode med intens drama aktiverede SegWit i sidste ende, men først efter at alternative Bitcoin-klienter inkluderede nye aktiveringsordninger. BIP 148, inkluderet i BIP 148-klienten, der drives af nogle brugere, var programmeret til kun at acceptere blokke, der signalerer understøttelse af protokolopgraderingen, der starter på en flagdag. I mellemtiden sænkede BIP 91, der var inkluderet i btc1-klienten og drives af minearbejdere lige før BIP 148-flagdagen, effektivt hash-effektbehovet fra 95 procent til 75 procent. Stående over for et potentielt delt netværk og et muligt tab af indkomst indrømmede de hindrende minearbejdere. Men for de fleste Bitcoin Core-udviklere havde BIP 9 afsløret at være en suboptimal løsning, og de begyndte at tænke på alternativer.
BIP 8
BIP 8 var et tidligt alternativ til BIP 9, foreslået af BIP 148-forfatteren Shaolinfry og Bitcoin Knots og Bitcoin Core-bidragyder Luke-jr. Det lignede oprindeligt BIP 9, men med en afgørende forskel: i stedet for at opgraderingen mislykkedes efter et år med utilstrækkelig hash-strømstøtte, ville det gøre det nøjagtige modsatte og aktivere den bløde gaffel på det tidspunkt. I lighed med en flagdag ville alle opgraderede noder fra da af begynde at håndhæve de nye regler. Minearbejdere, der stadig ikke har opgraderet, risikerer minedrift, som opgraderede minearbejdere og brugere vil afvise.
Hovedideen bag BIP 8 er, at – forudsat selvfølgelig at brugerne opgraderer – minearbejdere ikke kan blokere den bløde gaffel og derfor ikke kan bruge denne gearing til deres fordel. De kan fremskynde aktiveringen og hjælpe med at koordinere en jævn protokolopgradering, men opgraderingen vil til sidst ske, selvom de ikke selv aktiverer den.
Et nyere udkast til BIP 8 indeholder nogle bemærkelsesværdige ændringer. For det første tillader BIP 8, at noder konfigureres til to forskellige politikker, når signalperioden er ved at udløbe: tvungen aktivering, som forklaret i de foregående to afsnit, eller ingen tvungen aktivering, som med BIP 9. Desuden i stedet for at aktivere opgraderer sig selv, noder (hvis de er konfigureret) faktisk tvinger signalering til opgraderingen. Blokke, der ikke signalerer understøttelse af opgraderingen, afvises derefter og garanterer derfor stadig opgraderingen, i det mindste for de opgraderede noder. Kombinationen af disse to ændringer har den interessante egenskab, at hvis et flertal af al Bitcoin-hashkraft er tvunget til at signalere support til opgraderingen, vil selv BIP 8-noder, der ikke er konfigureret til at håndhæve signalering, gå sammen med opgraderingen.
Et argument mod BIP 8 og dens tvungne signalering (eller automatisk aktivering) specifikt er, at det kan være risikabelt, især på en kortere tidslinje. Hvis et hash-magtflertal og i det mindste nogle brugere ikke opgraderer, kan denne ordning opdele netværket mellem opgraderede og ikke-opgraderede noder. Forudsat at de fleste brugere understøtter opgraderingen, vil dette sandsynligvis løses til fordel for den opgraderede del af netværket til sidst. Men ikke-opgraderede brugere risikerer at miste penge i mellemtiden, mens ikke-opgraderede minearbejdere vil spilde hashkraft til skade for Bitcoins sikkerhed.
Denne risiko modvirkes sandsynligvis bedst ved at tilbyde tid nok til at opgradere. Desværre er ikke alle enige om, hvor meget tid der er nok; nogle mener, at tvungen signalering kunne starte inden for et år, andre mener, at det skulle tage flere år.
En anden komplikation med BIP 8 er at indstille standarder for tvungen signalering. Hvis tvungen signalering er slået fra som standard, kan brugerne finde sig ukoordinerede, hvilket øger risikoen for netopdelinger. Hvis der på den anden side vælges tvunget signalering som standard i en Bitcoin Core-udgivelse, garanterer den historisk udbredte vedtagelse af Bitcoin Core næsten, at opgraderingen vil ske. Nogle mener, at dette ville give Bitcoin Core-udviklere for meget indflydelse på Bitcoins protokolregler. BIP 8-medforfatter Luke-jr foretrækker, at BIP 8 kun implementeres gennem specielle klienter svarende til BIP 148-klienten.
Andre hævder, at Bitcoin Core-udviklere altid frigiver software efter deres bedste vurdering, samtidig med at brugernes efterspørgsel tages i betragtning og undgår omstridte opgraderinger; indstilling af BIP 8-standarder bør ikke være nogen undtagelse fra denne politik. Hvis nogen trods alt er uenige i de valg, som Bitcoin Core-udviklere tager, kan de simpelthen vælge ikke at opgradere til en ny udgivelse eller endda forkaste Bitcoin Core-koden for at starte en konkurrerende klient helt..
Moderne aktivering af blød gaffel
Mens Bitcoin Core-udviklere faktisk forsøger at tage hensyn til brugernes efterspørgsel og forsøge at undgå omstridte opgraderinger, er ikke alle overbeviste om, at dette altid er fuldstændigt muligt. Måske bekymringer over en foreslået opgradering kun overflade, når softwaren er implementeret i en ny udgivelse. Måske opstår der helt nye problemer efter denne frigivelse. Eller måske savnede Bitcoin Core-udviklere simpelthen noget.
Dette er en af grundene til, at Bitcoin Core-bidragsyder Matt Corallo foreslog en strategi kaldet “Moderne aktivering af blød gaffel.”Modern Soft Fork Activation består af tre trin, som i det væsentlige realiserer en kombination af BIP 9 (eller: BIP 8 uden tvungen signalering) og BIP 8 med aktivering af flagdag (selvom tvungen signalering også kan være en mulighed).
Som det første trin ville BIP 9 tillade minearbejdere at aktivere den bløde gaffel gennem hashkraft. Hvis minearbejdere ikke aktiverer det om (siger) et år, udløber det første aktiveringsvindue. Derefter, som det andet trin, tager udviklere noget tid at analysere, hvorfor aktivering mislykkedes, og genoverveje forslaget, hvis de finder en bekymring med det. Hvis de finder ud af, at der ikke var noget problem med forslaget, er det tredje trin dog omfordeling af den bløde gaffel, denne gang ved hjælp af BIP 8 med aktivering af flagdag: minearbejdere får en ny chance for at aktivere forslaget med hashkraft, men hvis de fejler igen , aktiveres den bløde gaffel, når denne anden signalperiode slutter. (I løbet af denne anden signalperiode kunne hash-aktiveringsgrænsen også sænkes trinvis over tid, Bitcoin Core-bidragyder AJ Towns foreslår.)
Ved eksplicit at forpligte sig til BIP 8-omlægning, hvis det viser sig, at der ikke er noget galt med forslaget, mener Corallo, at strategien vil give fordelene ved BIP 9 uden ulempen. Koden placeres derude i den første signalperiode, som alle kan overveje, minearbejdere kan koordinere en jævn opgradering, hvis de vælger det, og uden tvungen aktivering kan udviklere tage sig tid til at genoverveje forslaget, hvis aktivering oprindeligt mislykkes. I mellemtiden ville minearbejdere have meget mindre at vinde ved at blokere opgraderingen uden god grund, da alle ved, at det til sidst vil aktivere alligevel.
Hovedargumentet mod Modern Soft Fork Activation er, at uden minearbejdersamarbejde ville processen tage relativt lang tid, og nogle betragter BIP 9-trinnet som spild af tid i det hele taget. Corallos oprindelige forslag inkluderer et års BIP 9-signalering, efterfulgt af seks måneder til at genoverveje, og til sidst to år med BIP 8-signalering før automatisk aktivering: i alt tre og et halvt år. Selvom denne tidslinje naturligvis endnu ikke er sat i sten, vil det medføre mindre tid til genovervejelse og / eller opgradering at forkorte de forskellige trin med for meget (hvilket øger risikoen for netopdelinger).
På grund af den lange tid indtil potentiel tvungen aktivering argumenterer nogle også for, at minearbejdere trods alt kan prøve at få en vis politisk gearing: de kan forsinke opgraderingen i årevis.
BIP 8 + BIP 91
Et andet, nyligt forslag, der cirkulerer gennem Bitcoins teknologikanaler, beskrives måske bedst som en fusion mellem BIP 8 og Modern Soft Fork Activation, i det mindste i ånden. Det ikke navngivne forslag ville anvende en lang BIP 8-signalperiode, måske så længe Modern Soft Fork Activation’s tre og et halvt år, hvorefter tvungen signaludløser. Men hvis opgraderingen efter (siger) et år endnu ikke blev aktiveret, ville udviklere tage noget tid på at genoverveje forslaget, som de ville med Modern Soft Fork Activation.
Hvis udviklere ikke finder noget problem med forslaget og i stedet skulle konkludere, at det simpelthen ikke var aktiveret på grund af minearbejde eller en anden ugyldig grund, kunne de vælge at implementere en ny blød gaffel i stil med BIP 91, der blev brugt under SegWit aktivering. Dette ville effektivt sænke tærsklen for hasheffekt til aktivering, hvilket sandsynligvis fremskynder processen.
Hvis udviklere på den anden side trods alt ville finde et problem med forslaget, kunne de implementere en ny blød gaffel, der ville løse problemet eller endda fortryde den originale bløde gaffel (i dette tilfælde Taproot) helt. Under forudsætning af, at Modern Soft Fork Activation’s tre og et halvt års tidslinje indtil tvungen signalering, burde der være nok tid tilbage til at tage sig af dette.
Hovedargumentet mod dette forslag er sandsynligvis, at det ikke er meget elegant at anvende en blød gaffel, der fortryder en anden blød gaffel, hvis det er nødvendigt. Mere konkret kræver det, at minearbejdere og brugere opgraderer til nye udgivelser, inden deadlines nås, eller risikerer at splitte netværket.
Sporks
Til sidst foreslog Bitcoin Core-bidragsyder Jeremy Rubin, som lidt af en udestående idé, at et koncept, han opfandt, kaldes Probabilistic Bitcoin soft gafler, eller “Sporks,”Kan være mere incitamentkompatibelt end typiske hash-kraft håndhævede bløde gafler.
Kernen i problemet med BIP 9 hævder Rubin, at minearbejdere kan forsinke opgraderinger uden egne omkostninger. Det er gratis at nægte at signalere beredskab til en opgradering, mens det potentielt giver dem politisk gearing.
Med Sporks hentes beredskabssignalet ikke længere fra en smule data, som minearbejdere inkluderer i de blokke, de udvinder, men stammer fra blokhovedhashen: det tilfældigt genererede bevis for arbejde, de producerede ved at investere tid og ressourcer. Opgraderede noder er enige om, at en lille delmængde af gyldige blokhoved-hashes – statistisk kun findes hver sjette måned eller deromkring – ville udløse opgraderingen.
I henhold til tilfældigheden af hashes kontrollerer en minearbejder ikke, om han producerer regelmæssige blok header hashes eller opgraderingsaktiverende block header hashes; han ville statistisk bare tilfældigvis slette en af sidstnævnte sporadisk. Så hvis hans investerede ressourcer tilfældigvis genererer en opgraderingsaktiverende blokhoved-hash, ville han have to valg. Enten skal du offentliggøre det på Bitcoin-netværket, optjene blokbelønningen og aktivere den bløde gaffel. Eller hold tilbage fra offentliggørelse og forsink den bløde gaffel med omkring seks måneder i gennemsnit i vores eksempel … men ved også at opgive blokbelønningen. Forsinkelse af opgraderingen koster betydelige omkostninger.
Det største problem med Sporks lige nu er sandsynligvis, at det er en relativt ny idé, der endnu ikke er udviklet – endsige testet i naturen. Mens nogle anser konceptet for interessant, er det endnu ikke den mest sandsynlige kandidat til Taproot-aktivering.
Forfatterens bemærkning: Debatten om aktivering af blødgaffel (og Taproot-aktivering specifikt) er i flux; dette er en ikke-udtømmende oversigt over de forskellige opgraderingsforslag, især når det kommer til varianter af forslagene med alternative parametre og andre tweaks og alle deres fordele og ulemper.
Opdatering
En anden idé, som har fået noget trækkraft siden denne artikel blev skrevet (for det meste), er at først implementere BIP 8 med en relativt lang signalperiode (f.eks. To år), konfigureret uden tvungen signalering i slutningen af denne signalperiode. Dette giver minearbejdere mulighed for at aktivere den bløde gaffel relativt normalt, som de har gjort flere gange tidligere. Men hvis den bløde gaffel efter et stykke tid (f.eks. Seks måneder) ikke er aktiveret, og der ikke ser ud til at være en god grund til forsinkelsen, kan en ny klient frigives med BIP 8 konfigureret til at tvinge signalering nær slutningen af den eksisterende signalperiode eller hurtigere. Under forudsætning af at de fleste minearbejdere derefter aktiverer den bløde gaffel enten før eller under denne tvungne signalperiode, vil begge sæt BIP 8-noder (med og uden tvangssignalkonfigurationen) håndhæve den bløde gaffel ved aktivering.