Taproot, en föreslagen protokolluppgradering som skulle förbättra Bitcoins integritet och flexibilitet, är i dess sena utvecklingsstadier. Bitcoin Core-bidragsgivare är överens om att uppgraderingen skulle gynna Bitcoin, och hittills verkar det generellt sett välkomnas av det bredare Bitcoin-ekosystemet. Det är därför troligt att Taproot tar sig in i en Bitcoin Core-utgåva, med andra Bitcoin-implementeringar som eventuellt kan följa.

Men en fråga kvarstår: hur ska Bitcoin-nätverket själv uppgradera? Taproot är en konsensusprotokolländring, vilket innebär att Bitcoin-noder på något sätt måste byta från de gamla reglerna till de nya reglerna utan att dela upp nätverket i fraktioner som verkställer olika regler. Av olika skäl har detta ibland visat sig vara en utmaning tidigare.

Förbättrade strategier för att aktivera protokolluppgraderingar övervägs nu.

Tidigare mjuka gafflar och BIP 9

Den goda nyheten är att Taproot kommer att vara en mjuk gaffel. Denna typ av uppgradering lägger till eller skärper reglerna – i motsats till en hård gaffel som tar bort eller lossar regler. Det fina med att lägga till eller skärpa regler är att allt som en uppgraderad nod anser vara giltig, en icke-uppgraderad nod anser också vara giltig. (Om en gammal nod accepterar båda transaktionstyperna A och B, men nya regler endast tillåter transaktionstyp A, skulle den gamla noden förbli kompatibel i ett nätverk som verkställer de nya reglerna.)

Bitcoins tidigaste mjuka gafflar aktiverades under flaggdagar. Utvecklare (i synnerhet Satoshi Nakamoto) inbäddade ett framtida datum i koden för en ny Bitcoin-mjukvaruklientutgåva och specificerade en tidpunkt där uppgraderade noder skulle genomdriva de nya reglerna. Gruvarbetare och användare uppmuntrades att uppgradera före det datumet för att undvika nätverksdelningar. (Vid sidan av tiden var gruvarbetare och användare oftare samma människor än de är idag.)

Eftersom icke-uppgraderade noder förblir kompatibla med nya regler, är en praktisk fördel med mjuka gafflar att om en majoritet av hashkraften upprätthåller uppgraderingen, finner hela Bitcoin-nätverket enighet om deras version av blockchain. Detta innebär också att det finns mindre behov av att alla noder uppgraderas omedelbart när de nya protokollreglerna tillämpas, vilket ger användarna viss flexibilitet. (Även om användarna uppmuntras att ändå uppgradera, är de i slutändan de som verkställer de nya reglerna genom att avvisa transaktioner och block som bryter mot dem.)

Sedan omkring 2012 har mjuka gafflar i allt högre grad använt hashkraft som en koordineringsmekanism för att samordna övergången till nya regler. Genom att bädda in lite data i sina block kan gruvarbetare signalera till andra gruvarbetare och resten av nätverket att de uppgraderade sin programvara och därmed är redo att genomdriva de nya reglerna. När tillräckligt med hashkraftsignaler stöds, utlöses alla uppgraderade noder för att genomdriva de nya reglerna.

Under loppet av några uppgraderingar utvecklades denna strategi till Bitcoin Improvement Proposal 9 (BIP 9). BIP 9 var till exempel den mekanism som användes för att aktivera Bitcoins senaste mjuka gaffeluppgradering, Segregated Witness (SegWit). Gruvarbetare fick ett år för att aktivera uppgraderingen, vilket krävde 95 procent av blocken inom varje svårighetsintervall för att inkludera en beredningssignalbit. Om detta efter ett år inte hade hänt skulle aktiveringsperioden löpa ut och uppgraderingen misslyckades. (Det kunde då naturligtvis helt enkelt prövas igen.)

För SegWit spelade BIP 9 emellertid inte smidigt. Som med några av de tidigare uppgraderingarna kom vissa gruvarbetare förmodligen inte till att uppgradera under en tid på grund av apati: det finns ofta inte ett mycket stort incitament för gruvarbetare att uppgradera snabbt. Men ett större problem var att vissa gruvarbetare hade kommit att förstå signalprocessen som en sorts omröstning om uppgraderingen, där de istället för att signalera beredskap skulle (eller inte) signalera stöd för den. Värre är att vissa gruvarbetare slutade använda denna “röst” för att blockera uppgraderingen för att försöka få politisk hävstångseffekt över Bitcoin-utvecklingsprocessen, och / eller de “röstade” mot uppgraderingen för att hemligt dra nytta av en besvikelse i Bitcoin protokoll som uppgraderingen skulle fixa.

Efter en längre period av intensivt drama aktiverades SegWit i slutändan, men först efter att alternativa Bitcoin-klienter inkluderade nya aktiveringsscheman. BIP 148, inkluderad i BIP 148-klienten som körs av vissa användare, var programmerad att endast acceptera block som signalerar stöd för protokolluppgraderingen med början på en flaggdag. Samtidigt sänkte BIP 91, som ingår i btc1-klienten och drivs av gruvarbetare strax före flaggdagen för BIP 148, hashkraftskravet från 95 procent till 75 procent. De hindrande gruvarbetarna medgav ett potentiellt splittrat nätverk och en möjlig inkomstförlust. Men för de flesta Bitcoin Core-utvecklare hade BIP 9 visat sig vara en suboptimal lösning, och de började tänka på alternativ.

BIP 8

BIP 8 var ett tidigt alternativ för BIP 9, föreslagit av BIP 148-författaren Shaolinfry och Bitcoin Knots och Bitcoin Core-bidragsgivaren Luke-jr. Det liknade ursprungligen BIP 9, men med en avgörande skillnad: istället för att uppgraderingen misslyckades efter ett år med otillräckligt hashkraftsstöd, skulle det göra exakt motsatsen och aktivera den mjuka gaffeln vid den tidpunkten. På samma sätt som en flaggdag skulle alla uppgraderade noder från och med då börja tillämpa de nya reglerna. Gruvarbetare som fortfarande inte lyckats uppgradera riskerar gruvblock som uppgraderade gruvarbetare och användare skulle avvisa.

Huvudidén bakom BIP 8 är att – förutsatt naturligtvis att användare uppgraderar – kan gruvarbetare inte blockera den mjuka gaffeln och kan därför inte använda denna hävstång till deras fördel. De kan påskynda aktiveringen och hjälpa till att samordna en smidig protokolluppgradering, men uppgraderingen kommer så småningom att ske även om de inte aktiverar den själva.

Ett nyare utkast till BIP 8 innehåller några anmärkningsvärda ändringar. För det första tillåter BIP 8 att noder kan konfigureras för två olika principer när signalperioden är på väg att löpa ut: tvångsaktivering, som förklarats i de föregående två styckena, eller ingen tvångsaktivering, som med BIP 9. Dessutom, istället för att aktivera uppgradera sig själva, tvingar noder (om så är konfigurerade) faktiskt signalering för uppgraderingen. Block som inte signalerar stöd för uppgraderingen avvisas sedan och garanterar därför fortfarande uppgraderingen, åtminstone för de uppgraderade noderna. Kombinationen av dessa två ändringar har den intressanta egenskapen att om en majoritet av all Bitcoin-hashkraft tvingas signalera stöd för uppgraderingen, kommer även BIP 8-noder som inte är konfigurerade för att genomdriva signalering gå med i uppgraderingen.

Ett argument mot BIP 8 och dess tvingade signalering (eller automatisk aktivering) specifikt är att det kan vara riskabelt, särskilt på en kortare tidslinje. Om en hash-kraftmässig majoritet och åtminstone vissa användare inte uppgraderar kan detta schema dela nätverket mellan uppgraderade och icke-uppgraderade noder. Förutsatt att de flesta användare stöder uppgraderingen, skulle detta troligen lösa till förmån för den uppgraderade delen av nätverket så småningom. Men icke-uppgraderade användare riskerar att förlora pengar under tiden, medan icke-uppgraderade gruvarbetare skulle slösa hashkraft till nackdel för Bitcoins säkerhet.

Denna risk motverkas troligen bäst genom att erbjuda tillräckligt med tid för att uppgradera. Tyvärr är inte alla överens om hur mycket tid som räcker; vissa tror att tvångssignalering kan börja inom ett år, andra anser att det borde ta flera år.

En annan komplikation med BIP 8 är att ställa in standardvärden för tvångssignalering. Om tvångssignalering är avstängd som standard kan användare befinna sig okoordinerade, vilket ökar risken för nätverksdelningar. Om å andra sidan tvångssignalering väljs som standard i en Bitcoin Core-utgåva garanterar den historiskt utbredda antagandet av Bitcoin Core praktiskt taget att uppgraderingen kommer att ske. Vissa tror att detta skulle ge Bitcoin Core-utvecklare för mycket inflytande över Bitcoins protokollregler. BIP 8-medförfattare Luke-jr föredrar att BIP 8 endast distribueras via specialklienter, liknande BIP 148-klienten.

Andra hävdar att Bitcoin Core-utvecklare alltid släpper programvara efter bästa bedömning, samtidigt som man tänker på användarnas efterfrågan och undviker omtvistade uppgraderingar; att ställa in BIP 8-standardvärden bör inte vara något undantag från denna policy. Om någon trots allt inte håller med om valen som Bitcoin Core-utvecklare gör kan de helt enkelt välja att inte uppgradera till en ny version eller till och med dela upp Bitcoin Core-koden för att starta en konkurrerande klient helt och hållet.

Modern mjuk gaffelaktivering

Medan Bitcoin Core-utvecklare verkligen försöker ta hänsyn till användarnas efterfrågan och försöka undvika omstridda uppgraderingar, är inte alla övertygade om att detta alltid är helt möjligt. Kanske oroar en föreslagen uppgradering bara ytan när programvaran distribueras i en ny version. Kanske helt nya problem uppstår efter denna release. Eller kanske Bitcoin Core-utvecklare helt enkelt missat något.

Detta är en anledning till att Bitcoin Core-bidragsgivaren Matt Corallo föreslog en strategi som kallades “Modern mjuk gaffelaktivering.”Modern mjuk gaffelaktivering består av tre steg, som i huvudsak realiserar en kombination av BIP 9 (eller: BIP 8 utan tvångssignalering) och BIP 8 med flaggdagsaktivering (även om tvångssignalering också kan vara ett alternativ).

Som det första steget skulle BIP 9 tillåta gruvarbetare att aktivera den mjuka gaffeln genom hashkraft. Om gruvarbetare inte aktiverar det på (säg) ett år går det första aktiveringsfönstret ut. Sedan, som det andra steget, tar utvecklare lite tid att analysera varför aktivering misslyckades, och ompröva förslaget om de finner problem med det. Om de finner att det inte fanns något problem med förslaget är det tredje steget dock omplacering av den mjuka gaffeln, den här gången med BIP 8 med flaggaktivering: gruvarbetare får en ny chans att aktivera förslaget med hashkraft, men om de misslyckas igen aktiveras den mjuka gaffeln när denna andra signalperiod slutar. (Under denna andra signalperiod kan tröskeln för hashkraftaktivering också sänkas stegvis över tiden, Bitcoin Core-bidragsgivare AJ Towns föreslår.)

Genom att uttryckligen förbinda sig till BIP 8-omplacering om det visar sig att det inte är något fel med förslaget, tror Corallo att strategin skulle erbjuda fördelarna med BIP 9 utan nackdelen. Koden läggs ut där under den första signalperioden för alla att överväga, gruvarbetare kan samordna en smidig uppgradering om de så önskar, och utan tvångsaktivering kan utvecklare ta sig tid att ompröva förslaget om aktiveringen initialt misslyckas. Under tiden skulle gruvarbetare ha mycket mindre att vinna på att blockera uppgraderingen utan goda skäl, eftersom alla vet att det så småningom kommer att aktiveras ändå.

Huvudargumentet mot Modern Soft Fork Activation är att processen utan gruvarbetare skulle ta relativt lång tid, och vissa anser att BIP 9-steget är helt slöseri med tid. Corallos ursprungliga förslag inkluderar ett år av BIP 9-signalering, följt av sex månader att ompröva och slutligen två år av BIP 8-signalering innan automatiserad aktivering: totalt tre och ett halvt år. Även om den här tidslinjen naturligtvis inte är fast i sten ännu, skulle det förkorta de olika stegen med för mycket mindre tid för omprövning och / eller uppgradering (vilket ökar risken för nätverksdelningar).

På grund av den långa tiden tills potentiell tvingad aktivering hävdar vissa också att gruvarbetare trots allt kan försöka få politisk hävstång: de kan försena uppgraderingen i flera år.

BIP 8 + BIP 91

Ett annat, nyligen förslag som cirkulerar genom Bitcoins tekniska kanaler beskrivs kanske bäst som en sammanslagning mellan BIP 8 och Modern Soft Fork Activation, åtminstone i anda. Det namngivna förslaget skulle distribuera en lång BIP 8-signalperiod, kanske så länge som Modern Soft Fork Activations tre och ett halvt år, varefter tvingad signalering utlöses. Men om efter (säg) ett år uppgraderingen inte aktiverades ännu, skulle utvecklare ta lite tid att ompröva förslaget, som de skulle med Modern Soft Fork Activation.

Om utvecklare inte skulle hitta några problem med förslaget och istället skulle dra slutsatsen att det helt enkelt inte hade aktiverats på grund av gruvarbetares apati eller annan ogiltig anledning, kunde de välja att distribuera en ny mjuk gaffel i stil med BIP 91, som användes under SegWit aktivering. Detta skulle effektivt sänka tröskeln för hashkraft för aktivering, förmodligen påskynda processen.

Om utvecklare å andra sidan trots allt skulle hitta ett problem med förslaget, skulle de kunna distribuera en ny mjuk gaffel som skulle lösa problemet eller till och med ångra den ursprungliga mjuka gaffeln (i det här fallet Taproot) helt. Om man antar att Modern Soft Fork Activations tre och ett halvt års tidslinje fram till tvångssignalering borde det finnas tillräckligt med tid kvar för att ta hand om detta.

Huvudargumentet mot detta förslag är förmodligen att det inte är så elegant att använda en mjuk gaffel som ångrar en annan mjuk gaffel, om så behövs. Mer konkret kräver det att gruvarbetare och användare uppgraderar till nya utgåvor innan deadlines nås, eller riskerar att dela upp nätverket.

Sporks

Slutligen, som lite av en outlier-idé, föreslog Bitcoin Core-bidragsgivaren Jeremy Rubin att ett koncept som han uppfann kallades Probabilistic Bitcoin soft forks, eller “Sporks,”Kan vara mer incitamentskompatibelt än typiska hashkrafttvungna mjuka gafflar.

Kärnan i problemet med BIP 9, argumenterar Rubin, är att gruvarbetare kan fördröja uppgraderingar utan egen kostnad. Att helt enkelt vägra att signalera beredskap för en uppgradering är gratis, medan det potentiellt ger dem politisk hävstång.

Med Sporks tas beredskapssignalen inte längre från lite data som gruvarbetare inkluderar i blocken de bryter, utan härleds från blockhuvudets hash: det slumpmässigt genererade beviset på arbete de producerade genom att investera tid och resurser. Uppgraderade noder skulle vara överens om att en liten delmängd av giltiga blockhuvudhashar – statistiskt sett bara var sjätte månad eller så – skulle utlösa uppgraderingen.

Per hashs slumpmässighet skulle en gruvarbetare inte styra om han producerar vanliga blockhuvudhashar eller uppgraderingsaktiverande blockhuvudhashar; han skulle statistiskt nog bara råka ut en av de senare sporadiskt. Så om hans investerade resurser råkar generera en uppgraderingsaktiverande blockhuvud hash, skulle han ha två val. Antingen publicera den till Bitcoin-nätverket, tjäna blockbelöningen och aktivera den mjuka gaffeln. Eller undvik att publicera, fördröja den mjuka gaffeln i genomsnitt cirka sex månader i vårt exempel … men samtidigt ge upp blockbelöningen. Att försena uppgraderingen skulle kosta betydande.

Det största problemet med Sporks just nu är förmodligen att det är en relativt ny idé som inte har utvecklats än – än mindre testad i naturen. Medan vissa anser att konceptet är intressant är det ännu inte den mest troliga utmanaren för Taproot-aktivering.

Författarens anmärkning: Debatten om aktivering av mjuk gaffel (och aktivering av Taproot i synnerhet) är i flöde; detta är en icke-uttömmande översikt över de olika uppgraderingsförslagen, särskilt när det gäller varianter av förslagen med alternativa parametrar och andra tweaks, och alla deras fördelar och nackdelar.

Uppdatering

En annan idé, som har fått en viss dragkraft sedan denna artikel skrevs (mestadels), är att först distribuera BIP 8 med en relativt lång signalperiod (säg två år), konfigurerad utan tvångssignalering i slutet av denna signalperiod. Detta gör att gruvarbetare kan aktivera den mjuka gaffeln relativt normalt, som de har gjort flera gånger tidigare. Men om mjukgaffeln efter en tid (säg sex månader) inte är aktiverad och det inte verkar finnas en bra anledning till förseningen, kan en ny klient släppas med BIP 8 konfigurerad för att tvinga signalering nära slutet av den befintliga signalperioden, eller tidigare. Förutsatt att de flesta gruvarbetare sedan aktiverar den mjuka gaffeln antingen före eller under denna tvångssignaleringsperiod, skulle båda uppsättningarna av BIP 8-noder (med och utan tvångssignalkonfigurationen) tvinga den mjuka gaffeln vid aktivering.