Er det farligt at have flere implementeringer af Bitcoin?

Dette er en meningsredaktion af Bill Scoresby, en bitcoin-baseret lille virksomhedsejer og forfatter af adskillige guides til bitcoin-selvforvaring.

De fejl, der for nylig fik mange LND-noder til at falde ud af synkronisering med Bitcoin blockchain, var sandsynligvis forårsaget af en alternativ implementering.

Måske undrer du dig over, "Hvem i alverden bruger andet end Bitcoin Core?” Du vidste måske ikke, at der fandtes andre implementeringer af Bitcoin. Måske er du ikke sikker på, hvad en anden implementering overhovedet betyder.

Bitcoin Core begyndte som softwaren, der Satoshi Nakamoto skrev i C++ og udgivet til verden. Det er blevet opdateret med nye versioner, der fører til i dag. En alternativ implementering er software, der gør det samme som Bitcoin Core - håndhæver de samme konsensusregler - men er skrevet anderledes, oftest i et andet kodesprog.

Hvordan knækkede en alternativ implementering noder på Lightning-netværket?

En af de store Lightning Network-nodeversioner (Lnd) er afhængig af en alternativ Bitcoin-implementering kaldet btcd. Da en udvikler oprettede en meget stor multisig-transaktion, så btcd den ikke som gyldig, fordi den indeholdt for mange vidnedata. Andre Bitcoin-implementeringer - vigtigst af alt Bitcoin Core - havde ingen sådan begrænsning på Taproot-transaktionsvidnedata og accepterede derfor transaktionen og den blok, der indeholdt den, som gyldige.

Resultatet var, at minearbejdere blev ved med at tilføje nye blokke på kæden, fordi de ikke brugte btcd, og ifølge deres regler var der intet galt, men LND Lightning noder kunne ikke genkende nogen af ​​disse nye blokke, fordi de blev bygget oven på blokken, der indeholdt den ene transaktion, de så som ugyldig.

Da fejlen opstod igen den 1. november, var det ikke kun LND-knuder, der blev ramt. Nogle electrs-instanser (en implementering af backend-serveren til Electrum Wallet) nåede heller ikke at nå til enighed med resten af ​​kæden. Mens LND-noderne blev sat ude af konsensus på grund af et lignende problem i btcd, var det en implementering af Bitcoin skrevet i Rust, der fik elektrikerknuderne til at komme bagud, herunder nogle meget synlige servere drevet af mempool.space.

Grænsen for størrelsen af ​​vidnedata findes for at forhindre DoS-angreb, og er også en del af Bitcoin Core (selvom Core har en større grænse for Taproot-transaktioner). Det ser ud til, at de to andre implementeringer, der faldt ud af synkronisering, havde kode, der fastholdt den mindre grænse.

Meget små forskelle i implementeringer kan føre til manglende konsensus.

Det er farligt at have flere implementeringer af Bitcoin

Satoshi kunne ikke lide ideen om flere implementeringer af Bitcoin. "Jeg tror ikke, at en anden, kompatibel implementering af Bitcoin nogensinde vil være en god idé." Grunden til han gav var, "Så meget af designet afhænger af, at alle noder får nøjagtigt identiske resultater i låst trin, at en anden implementering ville være en trussel for netværket."

Trussel? Hvad er den store sag?

Du har sikkert hørt, at kæden med mest bevis-på-arbejde er den sande kæde. Når to forskellige minearbejdere finder en blok på samme tid, splittes kæden, og andre minearbejdere begynder at bygge på den blok, de hører om først.

Så snart en ny blok er tilføjet til den ene side af splittet, accepterer de fleste noder og minearbejdere det som den nye sande kæde og forlader den anden side af splittelsen. Disse blokke omtales som uaktuelle blokke, selvom nogle mennesker kalder dem forældreløse blokke.

Da den gennemsnitlige tid mellem blokke i Bitcoin er 10 minutter, er det sandsynligt, at hele netværket vil lære om denne nye blok, før en føjes til den tabende side af splittelsen, og kæden med mest arbejde vinder.

"Noder vil følge den gyldige kæde med mest arbejde ... Nøgleordet her er gyldigt. Hvis noden modtager en blok, som den fastslår ugyldig, er det lige meget, hvor meget arbejde der udføres oven på den blok, noden vil ikke acceptere den kæde." — Andrew Chow

Nøgleordet er "gyldig". Truslen dukker op, når en minearbejder finder en blok, som nogle andre minearbejdere og noder mener ikke er gyldige. Minearbejdere, der tror, ​​det er gyldigt, vil forsøge at bygge nye blokke på den kæde. Minearbejdere, der mener, at det ikke er gyldigt, vil forsøge at bygge videre på den sidste gyldige blok, de kender til. Resultatet: To kæder og ingen måde at vide, hvad der er sandt.

Hvordan i alverden skulle sådan noget ske?

Nå, som vi så i tilfældet med den seneste fejl med LND-noder, hvis der er en fejl i en implementering af Bitcoin, som ikke er i andre implementeringer, kan det føre til manglende konsensus om, hvorvidt en blokering er gyldig eller ej.

Bitcoin har ikke en mekanisme til at rette op på dette. Fællesskabet uden for protokollen skal beslutte, hvad der derefter skal ske. Det lyder meget ubehageligt.

Så meget, at Bitcoin-udvikler Peter Todd har sagt det andre implementeringer skal matche Bitcoin Core bug-for-bug.

Der går du: Flere implementeringer er farlige!

Hvad er de andre implementeringer af Bitcoin, og hvorfor eksisterer de?

Først og fremmest kører de fleste alle Bitcoin Core.

Luke Dashjr ser omkring 43,000 noder, 98% af dem kører Bitcoin Core og noget kaldet Coin Dance ser tæt på 15,000 noder, 96% af dem kører Bitcoin Core. Så i øjeblikket ser det ud til, at meget få mennesker bruger alternative implementeringer.

Ikke desto mindre er der aktive projekter, der forsøger at bygge og vedligeholde andre kodebaser, der implementerer Bitcoin-protokollen. De omfatter:

Jameson Lopp har en fremragende side med en mere udtømmende liste og links til alle de andre implementeringer.

Alle disse projekter har ekstremt dygtige udviklere, der arbejder på dem, og hver har eksisteret i mere end et par år. Hvorfor bruge så mange kræfter på noget, der virker som sådan et problem?

Bitcoin er tilladelsesløst. Alle kan downloade kæden; alle kan interagere med netværket; og ingen kan forhindre dig i at kode eller køre en alternativ implementering.

Alligevel klart nogle mennesker har ansvaret at lave ændringer i Bitcoin-lageret og processen for at vælge dem virker uformel. Mens der er Bitcoin Improvement Proposal (BIP) proces for at foreslå ændringer til Bitcoin Core er det også ret uformelt.

Intet af dette er et direkte problem. Som Marty Bent påpeger, grov konsensus kan være en styrke. Hvis processen med at ændre Bitcoin er svær og uklar, betyder det, at ændringer vil blive gennemgået mere grundigt.

Det næste trin i grov konsensus er at have mere end én populær implementering.

Ikke at have flere implementeringer kan være mere farligt

Der kan ikke være nogen tvivl om, at det allerede er et meget vanskeligt job at være en af ​​de mennesker, der har forpligtet adgang til Bitcoin Core. I en verden, hvor Bitcoin spiller en central rolle som et monetært instrument, vil dette job blive meget vanskeligere. En lille gruppe udviklere kan blive et meget værdifuldt mål. Deres opmærksomhed vil i det mindste blive søgt for at lobbye for forskellige inkluderinger eller udelukkelser i den næste softwareudgivelse.

Tænk på den lobbyindustri, der i øjeblikket eksisterer i politik. Hvorfor ville sådan en ting ikke udvikle sig omkring de mennesker, der har commit-adgang til den eneste implementering af Bitcoin-protokollen?

Ligesom politikere nu, vil de blive opfattet som at have adgang til magten. Som sådan vil folk målrette dem, bortset fra at disse udviklere ikke har en stats muskler til at forsvare dem. Hvad er det for et liv? Hvem ville frivilligt vælge det?

I slutningen af ​​dagen er det globale finansielle system en temmelig tung vægt at hvile på skuldrene af den lille gruppe mennesker, der har forpligtet adgang til ét GitHub-lager. Måske ikke så forskelligt fra det globale finansielle system, vi forsøger at komme væk fra, hvor folks monetære fremtid afhænger af nogle få centralbankers beslutninger.

Flere implementeringer til redning!

Tilstedeværelsen og den udbredte brug af flere implementeringer på Bitcoin-netværket kan afbøde dette pres ved at gøre det meget sværere for en ondsindet aktør at ændre Bitcoin-protokollen.

Hvis deltagerne i Bitcoin-netværket er mere jævnt fordelt på forskellige implementeringer, er der mere plads til, at gode ideer dukker op. At foreslå ændringer til Bitcoin eller afvise dem er meget mere decentraliseret, hvis det hele ikke foregår i én lejr.

Det er klart, at brug af forskellige implementeringer af Bitcoin øger risikoen for en kædeopdeling. En katastrofal kædeopdeling - hvor en betydelig del af knudepunkter og minearbejdere ved et uheld forkastede sig - ville ikke være godt for Bitcoin, og bestemt ikke dens pris. Men det ville ikke true Bitcoins tilladelsesløse natur.

Et centraliseret udviklingsmiljø, hvor alle kun bygger på Bitcoin Core, kan true tilladelsesløsheden. Samtalen om emnet skal tage fat på risiciene ved at stole så meget på Bitcoin Core i stedet for udelukkende at fokusere på, hvilke problemer der kan være forårsaget af en alternativ implementering.

Der er en stor, ældre artikel om denne debat af Aaron van Wirdum. Du kan også læse en nyere, informativ tråd om det.

Dette er et gæsteindlæg af Bill Scoresby. Udtalte meninger er helt deres egne og afspejler ikke nødvendigvis dem fra BTC Inc eller Bitcoin Magazine.