Den langvarige tvist om blokkstørrelse og den nylige introduksjonen av flere nye Bitcoin-implementeringer, fremhevet at ikke alle Bitcoin-noder bruker nøyaktig samme regel – og kanskje enda viktigere, at ikke alle utviklingsteam bruker lignende policyer når det gjelder å implementere disse reglene.

Utviklingsteamet bak Bitcoin Core, Bitcoins historiske “referanseklient” krever bred enighet i samfunnet før den implementerer regelendringer som å heve blokkstørrelsesgrensen, mens andre endringer ikke holdes på samme standard.. 

I mellomtiden, noen Bitcoin gafler, for eksempel Bitcoin LJR, er generelt akseptert av utviklingssamfunnet, mens andre, som f.eks Bitcoin Classic, tiltrekke seg mye kontrovers. Dette regnes som inkonsekvent av noen.

Men denne forskjellen kan forklares. Visse regelendringer, implementert i visse gafler, påvirker Bitcoin-nettverket veldig annerledes enn andre. Eller mer spesifikt: Visse regelendringer påvirker veldig forskjellige lag i Bitcoin-nettverket. Og noen av disse reglene kan endres i Bitcoin-nettverket, mens andre ikke kan gjøre det.

For å avklare disse forskjellene, Bitcoin Core utvikler og Ciphrex Konsernsjef Eric Lombrozo foreslo nylig å merke de aktuelle lagene i alle Bitcoin-forbedringsforslag. Dette er de fire hovedlagene på Bitcoin-nettverket som spesifisert i hans BIP 123, og den respektive viktigheten av konsensus om hver.

Konsensusreglene

Konsensusreglene er Bitcoins viktigste regler. De etablerer – blant mange andre ting – mengden bitcoins som er inkludert i blokkbelønningen, gruvedriftens vanskeligheter, typen arbeidskrav som kreves, og faktisk grensen for blokkstørrelse.. 

Disse reglene er så viktige fordi de bestemmer hvilke blokker som anses som gyldige av fulle noder. Og hvis alle fulle noder bruker de samme konsensusreglene, sikrer det at de alle har en identisk kopi av blockchain. 

Hvis forskjellige noder bruker forskjellige konsensusregler, risikerer de imidlertid å akseptere blokker som andre noder avviser. Slike avvik kan føre til at forskjellige noder opprettholder helt inkompatible versjoner av blockchain, og effektivt splitter Bitcoin-nettverket.

Bitcoins konsensusregler kan endres på to måter. En endring som legger til ekstra regler i protokollen (gjør tidligere gyldige blokker ugyldige) kalles en myk gaffel. Myke gafler krever et flertall av hashkraft for å støtte endringen. Blokkene som produseres under de nye reglene, vil også være gyldige under de gamle reglene, så noder som ikke oppgraderer, vil fortsatt følge den lengste kjeden.

Imidlertid kan ikke-oppgraderte gruvearbeidere produsere blokker som er ugyldige i henhold til de nye reglene, og kaste bort hashkraft. Og ikke-oppgraderte fullnoder ville ikke lenger være i stand til å verifisere om blokker følger de nye reglene, og krever at de venter på ytterligere bekreftelser for å oppnå samme sikkerhetsnivå. 

Av disse og andre grunner har utviklingen av Bitcoin Core sagt at det vanligvis vil kreve et superflertall på 95 prosent av hashkraften for å bli enige om myke gafler..

En konsensusregelendring som fjerner regler fra protokollen (gjør tidligere ugyldige blokker gyldige) kalles en hard gaffel. En hard gaffel krever at alle fulle noder på nettverket blir tatt i bruk. Enhver node som ikke implementerer endringen, følger kanskje ikke den lengste kjeden i det hele tatt, da den kan vurdere at kjeden er ugyldig og forbli i den “gamle” kjeden i stedet. Dette kan splitte Bitcoin-nettverket som beskrevet ovenfor. Hvor lenge en slik splittelse vil fortsette er egentlig ikke et teknisk spørsmål, men snarere en debatt om politikk, sosiologi, økonomi, spillteori og mer.

Myk gaffelendring av konsensusreglene uten konsensus kan – i verste fall – føre til at et mindretall av gruvearbeidere kaster bort hashkraft, og (litt) forringer sikkerheten til fulle noder.

Hard fork endringer i konsensusreglene uten konsensus kunne – i verste fall – dele Bitcoin-nettverket.

Peer-to-Peer Layer

Peer-to-peer-laget i Bitcoin-nettverket dekker hvor fulle noder deler data og hvilke data de deler. Dette inkluderer protokollregler for å sende og motta transaksjoner og blokker, samt spesielle datapakker som Segregated Witnesses eller Invertible Bloom Lookup Tables.

Viktigst, peer-to-peer-laget må sikre at nye blokker finner veien gjennom hele nettverket, samt datapakker som kreves for å verifisere blokker. Hvis denne relépolitikken mislykkes, kan det resultere i en nettverksdeling der forskjellige noder har forskjellige versjoner av blockchain – i hvert fall til blokker finner veien gjennom hele nettverket igjen.

Men i motsetning til konsensusreglene, er det ikke nødvendigvis et stort problem hvis ikke hver eneste node bruker nøyaktig samme relépolitikk. Siden de fleste noder videresender til minst åtte jevnaldrende, bør denne forsterkeren sørge for at alle noder mottar alle blokker, selv om noen av dem ikke videresender ordentlig.

Noder har enda større spillerom når det gjelder videresending av transaksjoner. De fleste noder i Bitcoin-nettverket i dag bruker en “først sett” -policy: Hvis de mottar to eller flere motstridende transaksjoner, avviser de sistnevnte. Men et økende antall noder bruker varianter av policyer for “bytt ut avgift”, noe som betyr at de velger transaksjonene som inkluderer de høyeste gebyrene – uavhengig av hvilken som kom først. I tillegg avviser noen noder visse typer transaksjoner helt, eller overfører ikke noen transaksjoner i det hele tatt.

Når det er sagt, bestemmer gruvearbeidere til slutt hvilke transaksjoner de inkluderer i blokker, og hvorfor. Det er først når transaksjonsoverføringsretningslinjer varierer voldsomt, eller er tilstrekkelig restriktive, at det kan bli uforutsigbart hvilke transaksjoner som er bekreftet av disse grunnene alene..

Endringer i peer-to-peer-laget uten konsensus kan – i verste fall – splitte nettverket. Denne risikoen eksisterer hvis blokker ikke finner veien i hele nettverket. Oppdelingen løser seg imidlertid automatisk når nettverket er koblet til igjen.

Hvis endringene bare gjelder transaksjoner, kan de – i verste fall – forhindre at visse transaksjoner bekreftes. Det kan også redusere påliteligheten til ubekreftede transaksjoner. Men det kan ikke dele nettverket.

Programmeringsgrensesnitt for applikasjoner og eksterne prosedyreanrop

Applikasjonsprogrammeringsgrensesnittet (API) og Remote Procedure Call (RPC) -lagene er kommunikasjonslag på toppen av peer-to-peer-protokollen. Mange Bitcoin-programvareapplikasjoner – for eksempel mobile lommebøker og blokkutforskere – kommuniserer med blockchain gjennom disse lagene ved å koble til et API eller programvarebibliotek.

Hvis et av disse lagene mislykkes, vil ikke alle tilkoblede programvare kunne kommunisere pålitelig med Bitcoin-nettverket. Mobile lommebøker vet ikke om de mottok Bitcoin, og blockchain-oppdagere kan ikke fortelle om en ny blokk ble funnet. Imidlertid vil ikke alle andre Bitcoin-brukere legge merke til noe; selve nettverket fungerer fortsatt bra.

Endringer i API- og RPC-lagene uten konsensus kan – i verste fall – koble brukere av disse lagene helt fra Bitcoin-nettverket. Men slike endringer kan ikke splitte selve nettverket.

applikasjoner

Til slutt henviser applikasjonslaget til hvordan Bitcoin-programvareapplikasjoner oppretter og bruker bestemte typer data som ikke berører nettverket direkte, men som er nyttig for å synkronisere på tvers av applikasjoner..

Dette inkluderer for eksempel adresseformater, generering av private nøkler eller sikkerhetskopier av lommeboken. Hvis en lommebok genererer en adresse som en annen lommebok ikke anser som gyldig, vil det være umulig å gjøre transaksjoner mellom dem. Eller hvis en lommebok bruker en metode for å opprette en reserveadressekilde, og en annen lommebok bruker en annen, kan brukerne ikke gjenopprette sine private nøkler med hver lommebok. Det samme gjelder sikkerhetskopier av lommeboken.

Endringer i applikasjonslagene uten konsensus kan – i verste fall – forhindre at noen brukere gjensidig handler, og forårsake andre ulemper. Slike endringer kan ikke dele nettverket. Takk, gå ut til Lombrozo for teknisk veiledning.