Er det farlig å ha flere implementeringer av Bitcoin?

Dette er en meningsredaksjon av Bill Scoresby, en bitcoin-basert småbedriftseier og forfatter av flere guider for bitcoin-selvforvaring.

Feilene som nylig fikk mange LND-noder til å falle ut av synkronisering med Bitcoin-blokkjeden var sannsynligvis forårsaket av en alternativ implementering.

Kanskje du lurer på: «Hvem i all verden bruker noe annet enn Bitcoin Core?” Du visste kanskje ikke at andre implementeringer av Bitcoin fantes. Kanskje du ikke er sikker på hva en annen implementering betyr.

Bitcoin Core begynte som programvaren som Satoshi Nakamoto skrev i C++ og utgitt til verden. Den har blitt oppdatert med nye versjoner som fører til i dag. En alternativ implementering er programvare som gjør det samme som Bitcoin Core – håndhever de samme konsensusreglene – men er skrevet annerledes, oftest på et annet kodespråk.

Hvordan brøt en alternativ implementering noder på Lightning-nettverket?

En av de store Lightning Network-nodeversjonene (LND) er avhengig av en alternativ Bitcoin-implementering kalt btcd. Når en utvikler opprettet en veldig stor multisig-transaksjon, så btcd den ikke som gyldig fordi den inneholdt for mye vitnedata. Andre Bitcoin-implementeringer – viktigst av alt Bitcoin Core – hadde ingen slik begrensning på taproot-transaksjonsvitnedata, og aksepterte derfor transaksjonen og blokken som inneholdt den som gyldig.

Resultatet var at gruvearbeidere fortsatte å legge til nye blokker i kjeden fordi de ikke brukte btcd og i henhold til reglene deres var ingenting galt, men LND Lightning-nodene kunne ikke gjenkjenne noen av disse nye blokkene fordi de ble bygget på toppen av blokken som inneholdt den ene transaksjonen de så som ugyldig.

Da feilen skjedde igjen 1. november, var det ikke bare LND-noder som ble rammet. Noen electrs-instanser (en implementering av backend-serveren for Electrum Wallet) klarte heller ikke å oppnå konsensus med resten av kjeden. Mens LND-nodene ble satt utenfor konsensus på grunn av et lignende problem i btcd, var det en implementering av Bitcoin skrevet i Rust som forårsaket at elektrisitetsnodene falt bak, inkludert noen svært synlige servere drevet av mempool.space.

Grensen på størrelsen på vitnedata eksisterer for å forhindre DoS-angrep, og er også en del av Bitcoin Core (selv om Core har en større grense for Taproot-transaksjoner). Det ser ut til at de to andre implementeringene som falt ut av synkronisering hadde kode som opprettholdt den mindre grensen.

Svært små forskjeller i implementeringer kan føre til manglende konsensus.

Det er farlig å ha flere implementeringer av Bitcoin

Satoshi likte ikke ideen om flere implementeringer av Bitcoin. "Jeg tror ikke en annen, kompatibel implementering av Bitcoin noen gang vil være en god idé." Grunnen til at han ga var, "Så mye av designet avhenger av at alle noder får nøyaktig identiske resultater i låst trinn at en ny implementering ville være en trussel for nettverket."

Trussel? Hva er problemet?

Du har sikkert hørt at kjeden med mest bevis-på-arbeid er den sanne kjeden. Når to forskjellige gruvearbeidere finner en blokk samtidig, deler kjeden seg og andre gruvearbeidere begynner å bygge på den blokken de hører om først.

Så snart en ny blokk legges til på den ene siden av splitten, aksepterer de fleste noder og gruvearbeidere det som den nye sanne kjeden og forlater den andre siden av splittelsen. Disse blokkene blir referert til som foreldede blokker, selv om noen kaller dem foreldreløse blokker.

Siden gjennomsnittstiden mellom blokker i Bitcoin er 10 minutter, er det sannsynlig at hele nettverket vil lære om denne nye blokken før en legges til den tapende siden av splittelsen, og kjeden med mest arbeid vinner.

"Noder vil følge den gyldige kjeden med mest arbeid ... Nøkkelordet her er gyldig. Hvis noden mottar en blokk som den fastslår ugyldig, spiller det ingen rolle hvor mye arbeid som gjøres på toppen av den blokken, noden vil ikke akseptere den kjeden." — Andrew Chow

Nøkkelordet er "gyldig". Trusselen dukker opp når en gruvearbeider finner en blokk som noen andre gruvearbeidere og noder mener ikke er gyldig. Gruvearbeidere som tror det er gyldig vil prøve å bygge nye blokker på den kjeden. Gruvearbeidere som tror det ikke er gyldig vil prøve å bygge på den siste gyldige blokken de vet om. Resultatet: To kjeder og ingen måte å vite hva som er sant.

Hvordan i all verden skulle noe slikt skje?

Vel, som vi så i tilfellet med den nylige feilen med LND-noder, hvis det er en feil i en implementering av Bitcoin som ikke er i andre implementeringer, kan det føre til manglende konsensus om en blokkering er gyldig eller ikke.

Bitcoin har ingen mekanisme for å fikse dette. Fellesskapet utenfor protokollen må bestemme hva som skjer videre. Det høres veldig ubehagelig ut.

Så mye at Bitcoin-utvikleren Peter Todd har sagt det andre implementeringer må matche Bitcoin Core bug-for-bug.

Sånn: Flere implementeringer er farlige!

Hva er de andre implementeringene av Bitcoin og hvorfor eksisterer de?

Først av alt, de fleste kjører Bitcoin Core.

Luke Dashjr ser rundt 43,000 XNUMX noder, 98% av disse kjører Bitcoin Core og noe som heter Coin Dance ser nærmere 15,000 XNUMX noder, 96% av disse kjører Bitcoin Core. Så for øyeblikket ser det ut til at svært få mennesker bruker alternative implementeringer.

Likevel er det aktive prosjekter som prøver å bygge og vedlikeholde andre kodebaser som implementerer Bitcoin-protokollen. De inkluderer:

Jameson Lopp har en utmerket side med en mer uttømmende liste og lenker til alle de andre implementeringene.

Alle disse prosjektene har ekstremt dyktige utviklere som jobber med dem, og hver har eksistert i mer enn noen få år. Hvorfor legge så mye innsats i noe som virker som et slikt problem?

Bitcoin er tillatelsesløst. Hvem som helst kan laste ned kjeden; alle kan samhandle med nettverket; og ingen kan hindre deg i å kode eller kjøre en alternativ implementering.

Likevel, helt klart noen mennesker har ansvaret å gjøre endringer i Bitcoin-depotet og prosessen for å velge dem virker uformell. Mens det er Bitcoin Improvement Proposal (BIP) prosess for å foreslå endringer i Bitcoin Core, er det også ganske uformelt.

Ingenting av dette er et direkte problem. Som Marty Bent påpeker, grov konsensus kan være en styrke. Hvis prosessen med å endre Bitcoin er vanskelig og uklar, betyr det at endringer vil bli grundigere undersøkt.

Det neste trinnet i grov konsensus er å ha mer enn én populær implementering.

Å ikke ha flere implementeringer kan være farligere

Det kan ikke være noen tvil om at det allerede er en veldig vanskelig jobb å være en av personene som har forpliktet tilgang til Bitcoin Core. I en verden hvor Bitcoin spiller en sentral rolle som pengeinstrument, vil denne jobben bli mye vanskeligere. En liten gruppe utviklere kan bli et veldig verdig mål. I det minste vil oppmerksomheten deres søkes for å drive lobbyvirksomhet for ulike inkluderinger eller ekskluderinger i neste programvareutgivelse.

Tenk på lobbybransjen som for tiden eksisterer i politikken. Hvorfor vil ikke noe slikt utvikle seg rundt menneskene som har forpliktet tilgang til den eneste implementeringen av Bitcoin-protokollen?

I likhet med politikere nå, vil de bli oppfattet å ha tilgang til makt. Som sådan vil folk målrette dem, bortsett fra at disse utviklerne ikke vil ha en stats muskler til å forsvare dem. Hva slags liv skal det bli? Hvem ville frivillig valgt det?

På slutten av dagen er det globale finansielle systemet en ganske tung vekt å hvile på skuldrene til den lille gruppen mennesker som har forpliktet tilgang til ett GitHub-depot. Kanskje ikke så forskjellig fra det globale finanssystemet vi prøver å komme vekk fra der folks monetære fremtid avhenger av beslutningene til noen få sentralbanker.

Flere implementeringer til unnsetning!

Tilstedeværelsen og utbredt bruk av flere implementeringer på Bitcoin-nettverket kan dempe dette presset ved å gjøre det mye vanskeligere for en ondsinnet aktør å endre Bitcoin-protokollen.

Hvis deltakerne i Bitcoin-nettverket er mer jevnt fordelt på ulike implementeringer, er det mer rom for gode ideer. Å foreslå endringer i Bitcoin eller avvise dem er mye mer desentralisert hvis ikke alt gjøres i en leir.

Å bruke forskjellige implementeringer av Bitcoin øker tydeligvis risikoen for en kjededeling. En katastrofal kjedesplittelse – der en betydelig del av noder og gruvearbeidere ved et uhell forkastet seg – ville ikke være bra for Bitcoin, og absolutt ikke prisen. Men det ville ikke true Bitcoins tillatelsesløse natur.

Et sentralisert utviklingsmiljø der alle bare bygger på Bitcoin Core kan true tillatelsesløsheten. Samtalen om emnet må ta opp risikoen ved å stole så sterkt på Bitcoin Core i stedet for å fokusere utelukkende på hvilke problemer som kan være forårsaket av en alternativ implementering.

Det er en flott, eldre artikkel om denne debatten av Aaron van Wirdum. Du kan også lese en nyere, informativ tråd om det.

Dette er et gjesteinnlegg av Bill Scoresby. Uttrykte meninger er helt deres egne og reflekterer ikke nødvendigvis meningene til BTC Inc eller Bitcoin Magazine.