Den långvariga tvist om blockstorlek och den senaste introduktionen av flera nya Bitcoin-implementeringar betonade att inte alla Bitcoin-noder tillämpar exakt samma regel – och kanske viktigare, att inte alla utvecklingsteam tillämpar liknande policyer när det gäller att implementera dessa regler.

Utvecklingsteamet bakom Bitcoin Core, Bitcoins historiska “referensklient” kräver ett brett samförstånd i samhället innan det genomför regeländringar som att höja blockstorleksgränsen, medan andra ändringar inte hålls på samma standard. 

Under tiden har vissa Bitcoin gafflar, till exempel Bitcoin LJR, accepteras allmänt av utvecklingssamhället, medan andra, såsom Bitcoin Classic, lockar mycket kontroverser. Detta anses vara inkonsekvent av vissa.

Men denna skillnad kan förklaras. Vissa regeländringar, implementerade i vissa gafflar, påverkar Bitcoin-nätverket väldigt annorlunda än andra. Eller mer specifikt: Vissa regeländringar påverkar mycket olika lager i Bitcoin-nätverket. Och några av dessa ändringar av reglerna kan dela upp Bitcoin-nätverket medan andra inte kan göra det.

För att klargöra dessa skillnader, Bitcoin Core utvecklare och Ciphrex VD Eric Lombrozo föreslog nyligen att märka relevanta lager i alla Bitcoin-förbättringsförslag. Det här är de fyra huvudskikten i Bitcoin-nätverket som anges i hans BIP 123, respektive betydelse av konsensus om var och en.

Konsensusreglerna

Konsensusreglerna är Bitcoins viktigaste regler. De fastställer – bland många andra saker – mängden bitcoins som ingår i blockbelöningen, gruvsvårigheten, vilken typ av arbetsbevis som krävs och faktiskt blockstorleksgränsen. 

Dessa regler är så viktiga eftersom de avgör vilka block som anses vara giltiga av fullständiga noder. Och om alla fulla noder tillämpar samma konsensusregler säkerställer det att de alla har en identisk kopia av blockchain. 

Om olika noder tillämpar olika konsensusregler riskerar de dock att acceptera block som andra noder avvisar. Sådan avvikelse kan leda till att olika noder bibehåller helt inkompatibla versioner av blockchain, vilket effektivt splittrar Bitcoin-nätverket.

Bitcoins konsensusregler kan ändras på två sätt. En ändring som lägger till extra regler i protokollet (gör tidigare giltiga block ogiltiga) kallas en mjuk gaffel. Mjuka gafflar kräver en majoritet av hashkraft för att stödja förändringen. Blocken som produceras enligt de nya reglerna skulle också vara giltiga enligt de gamla reglerna, så noder som inte uppgraderade skulle fortfarande följa den längsta kedjan.

Men icke-uppgraderade gruvarbetare kan producera block som är ogiltiga enligt de nya reglerna och slösa hashkraft. Och icke-uppgraderade helnoder skulle inte längre kunna verifiera om block följer de nya reglerna, vilket kräver att de väntar ytterligare bekräftelser för att uppnå samma säkerhetsnivå. 

Av dessa och andra anledningar har Bitcoin Core-utvecklingsteamet sagt att det vanligtvis kommer att kräva en supermajoritet på 95 procent av hashkraften för att komma överens om mjuka gafflar.

En konsensusregeländring som tar bort regler från protokollet (vilket gör tidigare ogiltiga block giltiga) kallas en hård gaffel. En hård gaffel kräver att alla fullständiga noder i nätverket antas. Varje nod som inte implementerar förändringen kanske inte följer den längsta kedjan alls, eftersom den kan anse att kedjan är ogiltig och stannar kvar i den “gamla” kedjan istället. Detta kan dela upp Bitcoin-nätverket som beskrivs ovan. Hur länge en sådan splittring skulle fortsätta är egentligen inte en teknisk fråga utan snarare en debatt om politik, sociologi, ekonomi, spelteori och mer.

Mjuka gaffeländringar i konsensusreglerna utan konsensus kan – i värsta fall – få en minoritet av gruvarbetare att slösa hashkraft och (något) försämra säkerheten för fulla noder.

Hårdgaffeländringar i konsensusreglerna utan konsensus kan – i värsta fall – dela upp Bitcoin-nätverket.

Peer-to-Peer-lager

Peer-to-peer-lagret i Bitcoin-nätverket täcker hur fullständiga noder delar data och vilken data de delar. Detta inkluderar protokollregler för att skicka och ta emot transaktioner och block, samt speciella datapaket som Segregated Witnesses eller Invertible Bloom Lookup Tables.

Det viktigaste är att peer-to-peer-lagret måste se till att nya block hittar sig genom hela nätverket, samt datapaket som krävs för att verifiera block. Om denna reläpolicy misslyckas kan det resultera i en nätverksdelning där olika noder innehåller olika versioner av blockchain – åtminstone tills block hittar igenom hela nätverket igen.

Men i motsats till konsensusreglerna är det inte nödvändigtvis ett stort problem om inte varje enskild nod tillämpar exakt samma reläpolicy. Eftersom de flesta noder vidarebefordrar block till minst åtta kamrater, bör denna förstärkare säkerställa att alla noder tar emot alla block även om vissa av dem inte vidarebefordras ordentligt.

Noder har ännu mer utrymme när det gäller att vidarebefordra transaktioner. De flesta noder i Bitcoin-nätverket använder idag en “först sett” -policy: Om de får två eller flera motstridiga transaktioner avvisar de den senare. Men ett växande antal noder tillämpar variationer av “ersättningsavgiftspolicy”, vilket innebär att de väljer de transaktioner som inkluderar de högsta avgifterna – oavsett vilken som kom först. Dessutom avvisar vissa noder helt vissa typer av transaktioner eller vidarebefordrar inte några transaktioner alls.

Som sagt, gruvarbetare bestämmer i slutändan vilka transaktioner de inkluderar i block och varför. Det är bara när transaktionsreläpolicyer varierar enormt eller är tillräckligt restriktiva, att det kan bli oförutsägbart vilka transaktioner som bekräftas av dessa skäl enbart.

Ändringar i peer-to-peer-lagret utan konsensus kan – i värsta fall – dela upp nätverket. Denna risk finns om block inte kan hitta sig genom hela nätverket. Uppdelningen kommer dock att lösa sig automatiskt när nätverket återansluts.

Om ändringarna endast gäller transaktioner kan de – i värsta fall – förhindra att vissa transaktioner bekräftas. Det kan också minska tillförlitligheten för obekräftade transaktioner. Men det kan inte dela nätverket.

Applikationsprogrammeringsgränssnitt och fjärrprocedursamtal

Skikten Application Programming Interface (API) och Remote Procedure Call (RPC) är kommunikationsskikt ovanpå peer-to-peer-protokollet. Många Bitcoin-programvara – till exempel mobilplånböcker och blockutforskare – kommunicerar med blockkedjan genom dessa lager genom att ansluta till ett API eller ett programbibliotek.

Om ett av dessa lager misslyckas kan alla anslutna program inte kommunicera tillförlitligt med Bitcoin-nätverket. Mobilplånböcker vet inte om de fick Bitcoin, och blockchain-upptäckare kan inte berätta om ett nytt block hittades. Men alla andra Bitcoin-användare kommer inte att märka något; nätverket i sig fungerar fortfarande bra.

Ändringar i API- och RPC-lagren utan konsensus kan – i värsta fall – helt koppla bort användare av dessa lager från Bitcoin-nätverket. Men sådana förändringar kan inte dela nätverket i sig.

Applikationer

Sist hänvisar applikationslagret till hur Bitcoin-program skapar och använder vissa typer av data som inte riktigt berör nätverket direkt, men som är användbart för att synkronisera mellan applikationer.

Detta inkluderar till exempel adressformat, generering av privata nycklar eller säkerhetskopior av plånboken. Om en plånbok genererar en adress som en annan plånbok inte anser vara giltig, är det omöjligt att göra transaktioner mellan dem. Eller om en plånbok använder en metod för att skapa en reservadress, och en annan plånbok använder en annan, kan användarna inte återställa sina privata nycklar med varje plånbok. Detsamma gäller säkerhetskopior av plånboken.

Ändringar av applikationslagren utan samförstånd kan – i värsta fall – förhindra att vissa användare ömsesidigt handlar och orsakar andra besvär. Sådana ändringar kan inte dela nätverket. Tack gå till Lombrozo för teknisk vägledning.