By Bitcoin Magasin - 1 år sedan - Lästid: 6 minuter
Softchains ger tvåvägspinnar och potentiellt utrymme för användningsfall - men inte utan säkerhetskostnader
Softchains är en sidokedjeimplementering som interagerar på en djupare nivå med konsensusmekanismer, vilket kan medföra fördelar och risker.
Detta är en åsiktsledare av Shinobi, en självlärd utbildare i Bitcoin rymd- och teknikinriktad Bitcoin poddvärd.
I det här nästa stycket och tittar på olika sidokedjeimplementeringsdesigner, ska vi gå igenom mjuka kedjor. Detta är ytterligare en av Ruben Somsens förslag till en sidokedjemekanism. Detta skiljer sig kraftigt från rymdkedjor, designen som behandlades i min tidigare artikel. Det kräver en specifik ändring av Bitcoin Kärnprotokoll som är specifikt strukturerat för att implementera en sidokedja pålägger en ny valideringskostnad Bitcoin fullständiga noder, och har stöd för en tvåvägs peg-mekanism som inte är beroende av en federation för att förvara medel.
Byggstenen
Kärnan i idén bygger på ett tidigare förslag från Somsen kallad PoW bedrägeribevis, en mekanism för att förbättra säkerheten för förenklad betalningsverifiering (SPV) för plånböcker. Idén bygger på en enkel observation om en blockkedja - om ett ogiltigt block produceras kommer det sannolikt att finnas en gaffel i blockkedjan eftersom alla ärliga gruvarbetare som finns kommer att vägra att bygga på det ogiltiga blocket och så småningom bryta ett giltigt. Ett ogiltigt block som produceras och ingen gaffel skapas av ärliga gruvarbetare betyder i huvudsak att det har skett en fullständig sammanbrott i konsensusprocessen för nätverket, så de statistiska oddsen för att det ska hända är obetydligt små. Därför kan en gaffel som inträffar ses som en slags signal om att "Hej, något kunde ha hänt här så du borde kolla upp det här." Klienter kan använda gafflar som denna som ett slags larm om att de faktiskt borde ladda ner dessa block och verifiera vad som händer.
Detta utgör dock ett grundläggande problem - för att verifiera ett block måste du ha en UTXO-uppsättning. För att ha en UTXO-uppsättning måste du ha verifierat alla tidigare block i kedjan för att konstruera den. Så hur fungerar detta som en SPV-mekanism? Svaret är UTXO-uppsatta åtaganden.
Varje block måste valideras mot UTXO-uppsättningen, en databas för varje bitcoin som finns som inte har använts ännu och för närvarande är detta bara en lokal databas som varje nod konstruerar och sparar när den skannar igenom blockkedjan från början. Ett UTXO-uppsättningsåtagande tar UTXO-setet, bygger ett Merkle-träd av det och begår helst hashen av det inuti varje block. Detta gör att du kan ta emot ett block med lite extra data - en Merkle-gren för varje inmatning av varje transaktion som bevisar att det var i den senaste UTXO-uppsättningen - och verifiera det på det sättet. Om ett system använde ett sådant åtagandesystem från första början, och det faktiskt användes av ett stort antal användare som fullständigt verifierade kedjan, skulle de ge en säkerhetsgaranti som nästan motsvarar en full nod. Närhelst en kedjedelning inträffar kan du ladda ner alla inblandade block och se till att kedjan du följer är giltig. Om båda sidorna av splittringen är giltiga vinner fortfarande den längsta. Men om en av dem var ogiltig, skulle detta låta dig upptäcka den direkt.
Tvåvägspinnen
Som en del av mjukkedjedesignen skulle huvudkedjenoder behöva ladda ner och validera blockhuvudena för varje mjukkedje, och i fallet med någon kedjedelning ladda ner och validera dessa block med UTXO-uppsättningens åtaganden. Detta skulle utgöra grunden för pegout-mekanismen för att möjliggöra en tvåvägs peg. För att migrera mynt till sidokedjan, skulle användaren skapa en huvudkedjetransaktion och tilldela dem till en specifik mjukkedja och sedan peka på den transaktionen när den bekräftades att göra anspråk på mynt på sidokedjan. Omvänt skulle du göra motsatsen när du försöker stifta ur sidokedjan. Det är här PoW-bedrägeribevisen kommer in i bilden. Under en pegout är tanken att skapa en transaktion på huvudkedjan som refererar till en uttagstransaktion på sidokedjan. Dessa mynt skulle inte kunna användas förrän efter en lång bekräftelseperiod (säg ett år) och skulle förbli "låsta i mjukkedjan" om uttagstransaktionen på sidokedjan omorganiserades eller befanns vara ogiltig. Det senare skulle upptäckas eftersom i händelse av en kedjedelning, kommer huvudkedjenoden att ladda ner alla block på varje sida av splittringen och verifiera dem med UTXO-uppsättningsåtaganden.
Det långa bekräftelsefönstret för pegouts är så att även en liten procentandel av ärliga gruvarbetare kan ha tillräckligt med tid för att producera ett enda giltigt block som delar upp kedjan och triggar en validering av allt från den punkten med UTXO-uppsättningar. Detta gör att huvudkedjans noder kan fånga bedrägliga sidokedjekopplingar innan uttaget bekräftas på huvudkedjan, vilket gör transaktionen ogiltig utan att kräva att de validerar hela sidokedjan – vilket inte skulle vara annorlunda än en ökning av blockstorlek.
Säkerhetsparametrar och risker
Denna design skapar några frågor när det gäller säkerhetsnivån baserat på vissa variabler och hur en sådan sidokedja skulle interagera med gruvarbetare. Först och främst bör alla mjukkedjor distribueras med ett krav på minsta svårighetsgrad för block, så att om hashhastigheten blir för låg istället för svårigheten att justera under detta minimiblock på sidokedjan helt enkelt skulle ta längre tid att hitta - dvs blockintervallet skulle öka. Detta är nödvändigt eftersom PoW-bedrägerisäkra valideringsnoder måste utföras som en del av denna design. Om svårighetsgraden för mjukkedjan är för låg, skulle det bli lätt för gruvarbetare att med uppsåt dela mjukkedjan regelbundet och effektivt utföra en denial-of-service-attack (DoS) mot mainchain-noder genom att öka mängden extra data de måste validera.
Sammanslagen gruvdrift är en lösning på detta problem. Om alla Bitcoin gruvarbetare bröt också block på sidokedjan, då löses problemet med DoS-attacker på huvudkedjan genom att skapa kedjedelningar på mjukkedjan ungefär så bra som det kan bli. Det skulle kräva lika mycket arbete att dela upp mjukkedjan som huvudkedjan, vilket förhindrar godtyckliga och lågkostnadsattacker för att öka mängden data som behövs för att validera huvudkedjan. Men när man löser DoS-attackproblemet skapar det ett annat problem: att öka valideringskostnaderna för gruvarbetare.
Om gruvarbetare ska bryta de mjuka kedjorna också, måste de köra noderna för dem för att säkerställa att blocken de bryter är giltiga. Om de inte är det riskerar de att bli föräldralösa och förlora avgiftsintäkterna från ett ogiltigt block. Om många dyra att verifiera mjuka kedjor aktiverades, såsom Ethereum-klonkedjor eller stora blockkedjor, skulle detta kunna göra gruvdrift mer centraliserad och dyrare att delta i. Gruvarbetare måste validera en kedja för att veta att de inte bygger på ett ogiltigt block och att förlora pengar, så detta är egentligen inte valfritt. Att göra validering dyrare undergräver ansträngningar för att maximera decentraliseringen av gruvdrift.
Det största problemet är risken för att en konsensusbugg på en mjukkedja faktiskt orsakar en konsensusdelning av själva huvudkedjan. Det finns en risk att större sidokedjereorganisationer ogiltigförklarar en giltig pegout-transaktion på sidokedjesidan till höger eftersom huvudkedjans sida är på väg att bli giltig. Kom ihåg att huvudkedjenoder också följer mjukkedjehuvudena. Detta kan leda till att huvudkedjan delas om olika delar av nätverket är på olika sidor av en mjukkedjedelad höger när en sidokedjekoppling valideras på huvudkedjan. Icke-deterministiska konsensusbuggar på mjukkedjan kan också orsaka en uppdelning av huvudkedjan, dvs om vissa noder såg en pegout som ogiltig men andra såg den som giltig.
Denna djupare koppling till huvudkedjans konsensus gör denna sidokedjedesign något riskabel och potentiellt något som inte bör göras. Åtminstone bör mjukkedjor aktiveras en i taget i individuella gafflar, istället för att använda en enda gaffel som gör att mjukkedjor kan snurras upp efter behag. Det faktum att kedjedelningar i denna design gör att huvudkedjenoder verifierar mer data gör möjligheten att helt enkelt slå på många mjukkedjor samtidigt till en attackvektor på huvudkedjan.
Mjuka kedjor blir mer involverade i konsensusskiktet i huvudkedjan än rymdkedjor, vilket medför många risker, men de tillåter en inbyggd tvåvägskoppling och därför mer potentiellt utrymme för olika användningsfall. Härnäst kommer jag att gå igenom drivkedjor, och sedan några sista tankar om sidokedjor i allmänhet.
Detta är ett gästinlägg av Shinobi. Åsikter som uttrycks är helt deras egna och återspeglar inte nödvändigtvis BTC Incs eller Bitcoin Tidskrift.
Ursprunglig källa: Bitcoin magazine