Drivkedjor tillåter sidokedjenodoperatörer att betala gruvarbetare för att bryta – och mer!

Detta är en åsiktsledare av Shinobi, en självlärd utbildare inom Bitcoin-utrymmet och teknikorienterad Bitcoin-podcast-värd.

Den här gången ska jag bryta ner och diskutera hur drivkedjor fungerar; de föreslogs ursprungligen 2015. Av alla förslag som hittills diskuterats är drivkedjorna de äldsta och de mest utförda när det gäller specifika implementeringsdetaljer och design, dokumenterade i BIP:er 300 och 301. Paul Sztorc, skaparen av konceptet, hade några huvuddesignmål i åtanke, och även om detta inte alls är heltäckande, är här några:

• Isolera varje sidokedja så att eventuella fel eller problem bara påverkar de som använder den.
• Tillåt sidokedjor att snurras upp utan att behöva en ny gaffel för var och en.
• Aktivera överföring av bitcoin in och ut ur en sidokedja med en tvåvägs peg.
• Tillåt fria experiment i design som han hoppas skulle utplåna behovet av altcoins.

Det finns två primära aspekter av hela designen, varför det finns två separata BIP:er. Den första är pegmekanismen (BIP300), vilket är det som gör att tvåvägspinnen kan fungera. Sztorc designade något som kallas en hash rate escrow, som i de mest grundläggande termerna tillåter gruvarbetare som en amorf grupp att kollektivt förvara mynten i alla sidokedjor. Det andra är ett "blindt" sammanslaget gruvsystem, där målet är att tillåta bitcoin-gruvarbetare att vara blockproducenter på en konsensusnivå utan att behöva validera sidokedjan för att göra det. Båda dessa delar presenterar tillsammans en tvåvägs peg-mekanism och ett sätt för bitcoin-gruvarbetare att ta del av mining av sidokedjorna samtidigt som de försöker mildra centraliseringsrisken som det innebär.

BIP300 specificerar logiken för förslaget till en ny sidokedja, aktiveringen av en ny sidokedja, förslaget om en buntad uppsättning uttag, godkännandet av en sådan uppsättning uttag, valideringslogiken för faktiska uttagstransaktioner och valideringen för insättningstransaktioner.

Att aktivera en ny sidokedja under drivkedjeförslaget är mycket lik processen med en mjuk gaffel som aktiveras genom gruvarbetarsignalering. Den stora skillnaden är naturligtvis att det faktiskt inte är en mjuk gaffel - en enda gaffel för att aktivera drivkedjans konsensusregler tillåter gruvarbetare att när som helst signalera att de aktiverar en ny sidokedja inom drivkedjans konsensusregler. För att föreslå aktivering av en ny sidokedja måste en gruvarbetare placera en OP_RETURN-data i sin myntbasutdata som inkluderar en unik identifierare för den sidokedjan, en offentlig nyckel att använda i insättningsoperationer, versionsdata, läsbara beskrivningar och hash för mjukvaruklienten. och GitHubs historia (det finns ingen konsensustillämpning här, bara data för människor att referera till).

När en gruvarbetare föreslår att aktivera en ny sidokedja och inkludera all nödvändig data i sin myntbas, blir det en slags "gruvarbetares signaleringsperiod" angående huruvida den här nya sidokedjan ska skapas eller inte ur huvudkedjans konsensussynpunkt. En gruvarbetare kan använda ett speciellt format för att inkludera ett förslag i sina myntbasutdata, och andra gruvarbetare kan skapa en annan utgång efter ett andra format för att signalera för aktivering. Ett nytt sidokedjeförslag kräver att 90 % av blocken under en svårighetsperiod signalerar för aktivering för att en ny sidokedjeskapelse ska kunna bekräftas. Detta skapar pegmekanismen för att möjliggöra sidokedjan, men interaktionen mellan sidokedja och huvudkedja är mer nyanserad än så.

Vid det här laget kan vem som helst fästa mynt i sidokedjan. För att koppla in i sidokedjan skapar en användare helt enkelt en transaktion med två ingångar med sin egen ingång och UTXO som motsvarar sidokedjans saldo med en enda utgång som tilldelar allt till sidokedjan. Detta garanterar att sidokedjan bara någonsin har en enda UTXO som innehåller alla pengar inlåsta. Uttag hanteras genom minar-röstning. Huvudkedjan har ingen förståelse för vem som äger vad i sidokedjan, och huvudkedjan kommer att betrakta alla uttag som godkänts av gruvarbetare inom röstningsmekanismen som giltiga. På grund av detta är det en lång fördröjning i uttagsprocessen. Det finns två faser i processen att dra sig ur en sidokedja: ett uttagsförslag (paket) och sedan uttagsomröstningsfasen. Gruvarbetare måste skapa en OP_RETURN-utdata i sin myntbastransaktion med en hash av den föreslagna uttagstransaktionen för att föreslå ett uttag. Denna hash, som liknar sighash, flaggar dock bara för att en del av en transaktion är i stället för hela saken. Den förbinder sig inte till ingången UTXO som representerar medel låsta i en drivkedja eller utdata som returnerar allt som inte dras tillbaka till en speciell sidokedja UTXO. Detta beror på att alla insättningar i drivkedjan skulle skapa en ny UTXO, och därmed ogiltigförklara åtagandet för uttagstransaktionen när folk gick för att validera den.

Härifrån börjar röstningsperioden för gruvarbetarna på uttagsförslaget. Efter att ett paket har föreslagits kan gruvarbetare rösta om de ska godkännas eller inte. Varje block som bryts gör att gruvarbetaren kan öka en godkännanderäknare, upp eller ner med ett eller två för att avstå från att göra någonting. Det finns några specifika begränsningar utöver detta, eftersom det är möjligt att ha mer än ett paket för en enskild sidokedja - om en gruvarbetare väljer att rösta "ja" (höja räknaren med ett) för ett uttagspaket för en sidokedja måste rösta "nej" (sänk räknaren med ett) för vartannat paket som är associerat med den specifika sidokedjan.

Detta för att garantera att det inte finns några "dubbla uttag", där någon har en produktion i flera paket som skulle betala ut dem mer bitcoin på huvudkedjan än vad de är skyldiga.

Å andra sidan får gruvarbetare också rösta nej för varje enskilt föreslaget paket. Detta är tänkt att fungera som ett slags larm för alla att en gruvarbetare som validerar dessa uttag (se till att de är legitimt ägda mynt på sidokedjan som dras ut) har märkt att något ogiltigt händer. Kom ihåg att en nyckelpunkt i den här designen är att gruvarbetare inte behöver validera något på sidokedjan, så om de inte väljer det ändå kan många gruvarbetare rösta upp paket som de inte verifierar. Denna larmfunktion är utformad för att de ska bli varnade om att de ska verifiera paketen för att säkerställa att ett bedrägligt uttag inte sker.

När ett paket har nått den nödvändiga tröskeln (13,150 90 block, eller ungefär 2017 dagar), blir transaktionen som faktiskt behandlar uttaget giltig och kan bekräftas. Men vad gör folk om gruvarbetare godkänner ett bedrägligt uttag som stjäl pengar från sidokedjan? Sztorcs förslag är att engagera sig i en användaraktiverad mjukgaffel (UASF) för att ogiltigförklara den ogiltiga kopplingstransaktionen. Detta utgör en enorm risk när det gäller konsensus för huvudkedjan. UASF XNUMX var ett högriskdrag som bara knappt lyckades och Bitcoin var mycket mindre än det är idag. Ju större Bitcoin växer, desto svårare blir sådana åtgärder att samordna.

Om du minns från artikel om rymdkedjor, den designen baserades på blind merged mining (BMM). Ruben Somsens BMM-design är faktiskt den andra varianten av det, den första är Sztorcs design enligt BIP301. BMM-specifikationen i drivkedjor är sammansatt av två meddelanden: ett begäranmeddelande och ett godkännandemeddelande. Båda koordineras genom en speciell transaktionstyp på huvudkedjan och specialutdata i en gruvarbetares myntbastransaktion.

Begäranstransaktionen konstrueras av den som skapar sidokedjeblock. Hela poängen med BMM är att den här personen kan vara någon som inte gruvdrift, så begäranstransaktionen är till för att de ska kunna betala gruvarbetare för att bekräfta sitt föreslagna sidokedjeblock. Sidokedjeblockförslaget konstruerar en transaktion som inkluderar hashen för sidokedjeblocket, det ID som tilldelades sidokedjan när den skapades och de sista fyra byten i det föregående huvudkedjeblockets rubrik. Det finns ytterligare tre konsensusregler som tillämpas på dessa typer av transaktioner. För det första är en begäranstransaktion ogiltig såvida det inte också finns en matchande acceptutgång i myntbastransaktionen för det blocket. Detta för att garantera att gruvarbetare inte kan ta ut en avgift från begäran utan att också acceptera och utvinna sidokedjeblocket. För det andra, för varje sidokedja tillåts endast en begäranstransaktion inkluderas i ett huvudkedjeblock. Detta för att säkerställa att endast ett block från en sidokedja faktiskt kan brytas per huvudkedjeblock. Slutligen måste de sista fyra byten av föregående huvudkedjeblock matcha. Detta säkerställer att en begäran endast är giltig för att mineras i nästa block, och sådana transaktioner kan inte brytas senare och stjäla pengar från en sidokedjeblockförslagsställare efter att någon annans block har minerats.

Acceptera utdata är mycket enkel: meddelandehuvuddata och hash för sidokedjeblocket. Om en gruvarbetare själva kör en drivkedjenod kan de helt enkelt ignorera begärandetransaktioner och alltid inkludera sin egen acceptutdata i sin myntbas för att bryta sina egna sidokedjeblock. Tillsammans tillåter dessa två aspekter gruvarbetare att antingen driva en sidokedjenod själva, eller en annan icke-gruvarbetare att göra det och betala gruvarbetaren för att bryta sina block. Tanken är att om gruvarbetare själva inte driver sidokedjorna och äter de extra valideringskostnaderna, så kan någon annan göra det åt dem. Om det finns konkurrens mellan icke-gruvarbetare som försöker tjäna avgifter på sidokedjan, kommer de sannolikt att fortsätta bjuda upp den avgift de är villiga att betala gruvarbetare i sin begärandetransaktion tills den representerar majoriteten av avgifterna de tjänar, med de icke- gruvarbetare som bara behåller en liten andel av vinsten och betalar resten till gruvarbetare.

Det är mekaniken bakom hur drivkedjor fungerar. Därefter, federerade sidokedjor, och sedan, efter det, en uppdelning av alla negativa och nackdelar varje design kan ha.

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