Den langvarige tvist om blokstørrelse og den nylige introduktion af flere nye Bitcoin-implementeringer fremhævede, at ikke alle Bitcoin-noder anvender nøjagtig den samme regel – og måske vigtigere, at ikke alle udviklingsteam anvender lignende politikker, når det gælder implementering af disse regler.

Udviklingsteamet bagved Bitcoin Core, Bitcoins historiske “referenceklient” kræver bred enighed i samfundet, før den implementerer regelændringer som f.eks. At hæve blokstørrelsesgrænsen, mens andre ændringer ikke holdes på de samme standarder. 

I mellemtiden er nogle Bitcoin gafler, såsom Bitcoin LJR, accepteres generelt af udviklingssamfundet, mens andre, såsom Bitcoin Classic, tiltrække en masse kontroverser. Dette betragtes som inkonsekvent af nogle.

Men denne forskel kan forklares. Visse regelændringer, implementeret i visse gafler, påvirker Bitcoin-netværket meget anderledes end andre. Eller mere specifikt: Visse regelændringer påvirker meget forskellige lag af Bitcoin-netværket. Og nogle af disse regler kan ændre Bitcoin-netværket, mens andre ikke kan.

For at afklare disse forskelle, Bitcoin Core udvikler og Ciphrex CEO Eric Lombrozo foreslog for nylig at tagge de relevante lag i alle Bitcoin-forbedringsforslag. Dette er de fire hovedlag på Bitcoin-netværket som specificeret i hans BIP 123, og den relevante betydning af konsensus om hver.

Konsensusreglerne

Konsensusreglerne er Bitcoins vigtigste regler. De fastlægger – blandt mange andre ting – mængden af ​​bitcoins inkluderet i blokbelønningen, minedriftens vanskeligheder, typen af ​​krævet bevis for arbejde, og faktisk blokstørrelsesgrænsen. 

Disse regler er så vigtige, fordi de bestemmer, hvilke blokke der anses for gyldige af fulde noder. Og hvis alle fulde noder anvender de samme konsensusregler, sikrer det, at de alle opretholder en identisk kopi af blockchain. 

Hvis forskellige noder anvender forskellige konsensusregler, risikerer de dog at acceptere blokke, som andre noder afviser. En sådan uoverensstemmelse kan føre til, at forskellige noder opretholder fuldstændig uforenelige versioner af blockchain, hvilket effektivt splitter Bitcoin-netværket.

Bitcoins konsensusregler kan ændres på to måder. En ændring, der tilføjer ekstra regler til protokollen (hvilket gør tidligere gyldige blokke ugyldige) kaldes en soft fork. Bløde gafler kræver et flertal af hashkraft til at understøtte ændringen. Blokkene, der produceres under de nye regler, vil også være gyldige under de gamle regler, så noder, der ikke opgraderede, vil stadig følge den længste kæde.

Ikke-opgraderede minearbejdere kan dog producere blokke, der er ugyldige i henhold til de nye regler, og spilder hashkraft. Og ikke-opgraderede fulde noder ville ikke længere være i stand til at kontrollere, om blokke overholder de nye regler, hvilket kræver, at de venter på yderligere bekræftelser for at opnå det samme sikkerhedsniveau. 

Af disse og andre grunde har Bitcoin Core-udviklingsteamet sagt, at det typisk vil kræve et superflertal på 95 procent af hashkraft for at blive enige om bløde gafler.

En konsensusregelændring, der fjerner regler fra protokollen (hvilket gør tidligere ugyldige blokke gyldige) kaldes en hård gaffel. En hård gaffel kræver, at alle fulde noder på netværket skal vedtages. Enhver node, der ikke implementerer ændringen, følger muligvis ikke den længste kæde, da den kunne betragte den kæde som ugyldig og forblive i den “gamle” kæde i stedet. Dette kan splitte Bitcoin-netværket som beskrevet ovenfor. Hvor længe en sådan splittelse vil fortsætte, er ikke rigtig et teknisk spørgsmål, men snarere en debat om politik, sociologi, økonomi, spilteori og mere.

Blød gaffelændringer i konsensusreglerne uden konsensus kunne – i værste fald – få et mindretal af minearbejdere til at spilde hashkraft og (let) forringe sikkerheden for fulde noder.

Hard fork ændringer til konsensusreglerne uden konsensus kunne – i værste fald – splitte Bitcoin-netværket.

Peer-to-Peer-lag

Peer-to-peer-laget i Bitcoin-netværket dækker, hvordan fulde noder deler data, og hvilke data de deler. Dette inkluderer protokolregler til at sende og modtage transaktioner og blokke såvel som specielle datapakker såsom Segregated Witnesses eller Invertible Bloom Lookup Tables.

Vigtigst er det, at peer-to-peer-laget skal sikre, at nye blokke finder vej gennem hele netværket samt datapakker, der kræves for at bekræfte blokke. Hvis denne relæpolitik mislykkes, kan det resultere i en netværksopdeling, hvor forskellige noder indeholder forskellige versioner af blockchain – i det mindste indtil blokke finder vej gennem hele netværket igen.

Men i modsætning til konsensusreglerne er det ikke nødvendigvis et stort problem, hvis ikke hver enkelt node anvender nøjagtig den samme relæpolitik. Da de fleste noder videresender blokke til mindst otte jævnaldrende, bør denne forstærker sikre, at alle noder modtager alle blokke, selvom nogle af dem ikke videresendes korrekt.

Noder har endnu mere spillerum, når det kommer til videresendelse af transaktioner. De fleste noder på Bitcoin-netværket bruger i dag en “først set” -politik: Hvis de modtager to eller flere modstridende transaktioner, afviser de sidstnævnte. Men et voksende antal noder anvender variationer af “udskiftningsgebyr” -politikker, hvilket betyder, at de vælger de transaktioner, der inkluderer de højeste gebyrer – uanset hvilke der kom først. Derudover afviser nogle knudepunkter visse typer transaktioner helt eller videregiver slet ikke nogen transaktioner.

Når det er sagt, beslutter minearbejdere i sidste ende, hvilke transaktioner de inkluderer i blokke, og hvorfor. Det er kun når transaktionsrelæpolitikker varierer voldsomt eller er tilstrækkeligt restriktive, at det kan blive uforudsigeligt, hvilke transaktioner der kun bekræftes af disse grunde.

Ændringer i peer-to-peer-laget uden konsensus kunne – i værste fald – splitte netværket. Denne risiko eksisterer, hvis blokke ikke kan finde vej gennem hele netværket. Opdelingen løses dog automatisk, når netværket tilsluttes igen.

Hvis ændringerne kun vedrører transaktioner, kunne de – i værste fald – forhindre visse transaktioner i at blive bekræftet. Det kan også mindske pålideligheden af ​​ubekræftede transaktioner. Men det kan ikke opdele netværket.

Applikationsprogrammeringsgrænseflader og fjernprocedureopkald

Application Programming Interface (API) og Remote Procedure Call (RPC) lag er kommunikationslag oven på peer-to-peer-protokollen. Mange Bitcoin-softwareapplikationer – såsom mobile tegnebøger og block explorers – kommunikerer med blockchain gennem disse lag ved at oprette forbindelse til et API eller softwarebibliotek.

Hvis et af disse lag fejler, vil alle tilsluttede softwareapplikationer ikke være i stand til at kommunikere pålideligt med Bitcoin-netværket. Mobile tegnebøger ved ikke, om de modtog Bitcoin, og blockchain-opdagelsesrejsende kan ikke fortælle, om der blev fundet en ny blok. Imidlertid bemærker alle andre Bitcoin-brugere ikke noget; selve netværket kører stadig fint.

Ændringer i API- og RPC-lagene uden konsensus kunne – i værste fald – afbryde brugere af disse lag fuldstændigt fra Bitcoin-netværket. Men sådanne ændringer kan ikke splitte selve netværket.

Ansøgninger

Endelig henviser applikationslaget til, hvordan Bitcoin-softwareapplikationer opretter og bruger visse typer data, der ikke rigtig rører netværket direkte, men som er nyttigt at synkronisere på tværs af applikationer.

Dette inkluderer f.eks. Adresseformater, generering af private nøgler eller sikkerhedskopier af tegnebogen. Hvis en tegnebog genererer en adresse, som en anden tegnebog ikke anser for gyldig, er det umuligt at foretage transaktioner mellem dem. Eller hvis en tegnebog bruger en metode til at oprette et backup-adressefrø, og en anden tegnebog bruger en anden, kan brugerne ikke gendanne deres private nøgler med hver tegnebog. Det samme gælder for sikkerhedskopier af tegnebogen.

Ændringer i applikationslagene uden konsensus kunne – i værste fald – forhindre, at nogle brugere gensidigt handler og forårsager andre gener. Sådanne ændringer kan ikke splitte netværket. Tak gå ud til Lombrozo for teknisk vejledning.