Är det farligt att ha flera implementeringar av Bitcoin? PlatoBlockchain Data Intelligence. Vertikal sökning. Ai.

Är det farligt att ha flera implementeringar av Bitcoin?

Detta är en opinionsledare av Bill Scoresby, en bitcoin-baserad småföretagare och författare till flera guider för bitcoin-självvård.

De buggar som nyligen fick många LND-noder att falla ur synk med Bitcoin-blockkedjan var troligen orsakad av en alternativ implementering.

Du kanske undrar, "Vem i hela världen använder något annat än Bitcoin Core?” Du kanske inte visste att andra implementeringar av Bitcoin fanns. Du kanske inte är säker på vad en annan implementering ens innebär.

Bitcoin Core började som programvaran som Satoshi Nakamoto skrev i C++ och släpptes till världen. Den har uppdaterats med nya versioner som leder till idag. En alternativ implementering är mjukvara som gör samma sak som Bitcoin Core – upprätthåller samma konsensusregler – men skrivs annorlunda, oftast på ett annat kodningsspråk.

Hur bröt en alternativ implementering noder på Lightning-nätverket?

En av de stora Lightning Network-nodversionerna (LND) förlitar sig på en alternativ Bitcoin-implementering som kallas btcd. När en utvecklare skapade en mycket stor multisig-transaktion, såg btcd den inte som giltig eftersom den innehöll för mycket vittnesdata. Andra Bitcoin-implementeringar - viktigast av allt Bitcoin Core - hade ingen sådan gräns för Taproot-transaktionsvittnesdata och accepterade därför transaktionen och blocket som innehöll den som giltiga.

Resultatet var att gruvarbetare fortsatte att lägga till nya block i kedjan eftersom de inte använde btcd och enligt deras regler var inget fel, men LND Lightning-noder kunde inte känna igen några av dessa nya block eftersom de byggdes ovanpå blocket som innehöll den ena transaktionen såg de som ogiltig.

När felet inträffade igen den 1 november var det inte bara LND-noder som drabbades. Vissa electrs-instanser (en implementering av backend-servern för Electrum Wallet) lyckades inte nå konsensus med resten av kedjan. Medan LND-noderna ställdes utanför konsensus på grund av ett liknande problem i btcd, var det en implementering av Bitcoin skriven i Rust som orsakade att elektrens noder hamnade på efterkälken, inklusive några mycket synliga servrar drivs av mempool.space.

Gränsen för storleken på vittnesdata finns för att förhindra DoS-attacker, och är också en del av Bitcoin Core (även om Core har en större gräns för Taproot-transaktioner). Det verkar som att de andra två implementeringarna som inte var synkroniserade hade kod som bibehöll den lägre gränsen.

Mycket små skillnader i implementeringar kan leda till bristande konsensus.

Att ha flera implementeringar av Bitcoin är farligt

Satoshi gillade inte tanken på flera implementeringar av Bitcoin. "Jag tror inte att en andra, kompatibel implementering av Bitcoin någonsin kommer att vara en bra idé." Anledningen han gav var, "Så mycket av designen beror på att alla noder får exakt identiska resultat i låst steg att en andra implementering skulle vara ett hot mot nätverket."

Hot? Vad är grejen?

Du har säkert hört att kedjan med flest proof-of-work är den sanna kedjan. När två olika gruvarbetare hittar ett block samtidigt splittras kedjan och andra gruvarbetare börjar bygga på vilket kvarter de hör om först.

Så snart ett nytt block läggs till på ena sidan av splittringen accepterar de flesta noder och gruvarbetare det som den nya sanna kedjan och överger den andra sidan av splittringen. Dessa block kallas inaktuella block, även om vissa människor kallar dem föräldralösa block.

Eftersom den genomsnittliga tiden mellan blocken i Bitcoin är 10 minuter, är det troligt att hela nätverket kommer att lära sig om detta nya block innan ett läggs till på den förlorande sidan av splitten, och kedjan med mest arbete vinner.

"Noder kommer att följa den giltiga kedjan med mest arbete... Nyckelordet här är giltigt. Om noden tar emot ett block som den bedömer vara ogiltigt spelar det ingen roll hur mycket arbete som görs ovanpå det blocket, noden kommer inte att acceptera den kedjan.” — Andrew Chow

Nyckelordet är "giltigt". Hotet dyker upp när en gruvarbetare hittar ett block som vissa andra gruvarbetare och noder tror inte är giltigt. Gruvarbetare som tror att det är giltigt kommer att försöka bygga nya block på den kedjan. Gruvarbetare som tror att det inte är giltigt kommer att försöka bygga på det sista giltiga blocket de känner till. Resultatet: Två kedjor och inget sätt att veta vad som är sant.

Hur i hela friden skulle något sådant gå till?

Tja, som vi såg i fallet med den senaste buggen med LND-noder, om det finns en bugg i en implementering av Bitcoin som inte finns i andra implementeringar, kan det leda till bristande konsensus om huruvida ett block är giltigt eller inte.

Bitcoin har ingen mekanism för att fixa detta. Samhället utanför protokollet måste bestämma vad som händer härnäst. Det låter väldigt obehagligt.

Så mycket att Bitcoin-utvecklaren Peter Todd har sagt det andra implementeringar måste matcha Bitcoin Core bugg för bugg.

Där har du: Flera implementeringar är farliga!

Vilka är de andra implementeringarna av Bitcoin och varför finns de?

Först och främst kör nästan alla Bitcoin Core.

Luke Dashjr ser cirka 43,000 XNUMX noder, 98% av dem kör Bitcoin Core och något som kallas Coin Dance ser närmare 15,000 XNUMX noder, 96% av dem kör Bitcoin Core. Så för tillfället ser det ut som att väldigt få människor använder alternativa implementeringar.

Ändå finns det aktiva projekt som försöker bygga och underhålla andra kodbaser som implementerar Bitcoin-protokollet. De inkluderar:

Jameson Lopp har en utmärkt sida med en mer uttömmande lista och länkar till alla andra implementeringar.

Alla dessa projekt har extremt begåvade utvecklare som arbetar med dem, och alla har funnits i mer än några år. Varför lägga så mycket ansträngning på något som verkar vara ett sådant problem?

Bitcoin är tillståndslöst. Vem som helst kan ladda ner kedjan; vem som helst kan interagera med nätverket; och ingen kan hindra dig från att koda eller köra en alternativ implementering.

Ändå klart vissa personer har ansvaret att göra ändringar i Bitcoin-förvaret och processen för att välja dem verkar informell. Medan det finns Bitcoin Improvement Proposal (BIP) process för att föreslå ändringar av Bitcoin Core är det också ganska informellt.

Inget av detta är ett direkt problem. Som Marty Bent påpekar, grov konsensus kan vara en styrka. Om processen att byta Bitcoin är svår och otydlig betyder det att förändringar kommer att granskas mer noggrant.

Nästa steg av grov konsensus är att ha mer än en populär implementering.

Att inte ha flera implementeringar kan vara farligare

Det kan inte råda några tvivel om att det redan är ett mycket svårt jobb att vara en av de personer som har begått tillgång till Bitcoin Core. I en värld där Bitcoin spelar en central roll som ett monetärt instrument kommer det här jobbet att bli mycket svårare. En liten grupp utvecklare kan bli ett mycket värdefullt mål. Åtminstone kommer deras uppmärksamhet att sökas för att lobba för olika inneslutningar eller uteslutningar i nästa programvaruversion.

Tänk på lobbybranschen som för närvarande finns i politiken. Varför skulle inte en sådan sak utvecklas kring de människor som har tillgång till den enda implementeringen av Bitcoin-protokollet?

Liksom politiker nu kommer de att uppfattas ha tillgång till makt. Som sådan kommer människor att rikta in sig på dem, förutom att dessa utvecklare inte kommer att ha en stats muskler att försvara dem. Vad ska det bli för liv? Vem skulle frivilligt välja det?

I slutändan är det globala finansiella systemet en ganska tung tyngd att vila på axlarna av den lilla grupp människor som har begått tillgång till ett GitHub-förråd. Kanske inte så olikt det globala finansiella system vi försöker komma ifrån där människors monetära framtid hänger på beslut från några få centralbanker.

Flera implementeringar till räddning!

Närvaron och den utbredda användningen av flera implementeringar på Bitcoin-nätverket kan mildra dessa tryck genom att göra det mycket svårare för en illvillig aktör att ändra Bitcoin-protokollet.

Om deltagarna i Bitcoin-nätverket är mer jämnt fördelade mellan olika implementeringar finns det mer utrymme för bra idéer att dyka upp. Att föreslå ändringar av Bitcoin eller förkasta dem är mycket mer decentraliserat om allt inte görs i ett läger.

Det är klart att användning av olika implementeringar av Bitcoin ökar risken för en kedjedelning. En katastrofal kedjeuppdelning – där en betydande del av noder och gruvarbetare av misstag klaffade av sig – skulle inte vara bra för Bitcoin, och absolut inte dess pris. Men det skulle inte hota Bitcoins tillåtelselösa natur.

En centraliserad utvecklingsmiljö där alla bara bygger på Bitcoin Core kan hota tillståndslösheten. Konversationen om ämnet måste ta upp riskerna med att förlita sig så mycket på Bitcoin Core snarare än att enbart fokusera på vilka problem som kan orsakas av en alternativ implementering.

Det finns en stor, äldre artikel om denna debatt av Aaron van Wirdum. Du kan också läsa en nyare, informativ tråd om det.

Detta är ett gästinlägg av Bill Scoresby. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis de från BTC Inc eller Bitcoin Magazine.

Tidsstämpel:

Mer från Bitcoin Magazine