Spacechains: Hur detta nya Bitcoin Sidechain-förslag fungerar

Tidsstämpel: 29 juni 2022 5:00
Källnod: 1544330

Spacechains är en föreslagen Bitcoin-sidokedja som erbjuder en enkelriktad pegmekanism som använder blind sammanslagningsmindesign.

Idén med sidokedjor som en skalnings- och funktionsförlängningsmekanism för Bitcoin är ett mycket gammalt koncept. En slags grundläggande "förfader" idé om sidokedjor, slå samman minerade kedjor, går till och med tillbaka till innan Satoshi försvann.

Det förslaget var helt enkelt tanken på att två helt separata och orelaterade kedjor bryts av samma grupp av gruvarbetare, utan möjlighet att flytta något mellan kedjorna. De ursprungliga sidokedjeförslaget gjordes 2014 av många av de personer som fortsatte med att grunda Blockstream bokstavligen en vecka eller så efter att tidningen publicerades. Grundidén var att kunna få mynt att flytta fram och tillbaka mellan den huvudsakliga Bitcoin-blockkedjan och andra sidokedjor, med enkla betalningsbevis (SPV) som används för att bevisa att saker är giltiga när du skickar mynt från en kedja till den andra. Detta kom aldrig att förverkligas på grund av komplexiteten i implementeringen kring kedjeomorganisationer, risken för stöld och risker för centralisering av gruvdrift (som allt kan läsas om i avsnitt fyra av Bitcoin vitbok).

Pinnmekanismer för sidokedjor kan vara av två varianter, envägs och tvåvägs. Innebörden bör vara uppenbara - i en tvåvägspinne kan mynt röra sig fram och tillbaka mellan föräldrakedjan och sidokedjan, och i en enkelriktad pinne kan de bara flytta från förälderkedjan till sidokedjan och aldrig flytta tillbaka. För närvarande är den enda formen av tvåvägs sidokedjepinnar som implementeras på Bitcoin genom federerad konsensus, vilket innebär att pegningen garanteras av en pålitlig uppsättning "förvarare" som upprätthåller kontrollen över medel kopplade till sidokedjan i en multisig-plånbok tills de dras tillbaka.

Människor har dock fortsatt att arbeta med andra konstruktioner för sidokedjepinnar som inte är federerade. Här ska jag gå igenom Ruben Somsens Spacechain-förslag som ett exempel. Det är en enkelriktad pinnemekanism som använder en blind sammanslagningsmindesign, liknande Paul Stztorcs. Det betyder att mynt bara kan gå in i sidokedjan och aldrig lämna, och att gruvarbetare inte behöver köra ny mjukvara för att få kompensation för att bryta sidokedjan (de kan dock, som jag kommer in på senare, dra mer nytta av att göra det).

Spacechain-förslaget

Merge mining kräver att gruvarbetare kör noderna för både Bitcoin-kedjan och vilken annan kedja de bryter, för att kunna kompilera blocken för båda kedjorna och förbinda sig till dem i Bitcoin-blockhuvudet som de bryter. Blind merge mining utnyttjar det faktum att Bitcoin-gruvarbetarna egentligen bara behöver ha den andra kedjans blockheader att förbinda sig till i sitt Bitcoin-block, någon annan kan faktiskt ta sig besväret med att sätta ihop blocket för den andra kedjan.

Somsens föreslagna mekanism för detta kan utnyttja NÅGOT FÖREGÅENDE (APO) för att tillåta öppen konkurrens för alla att kunna tävla om att bygga nästa sidokedjeblock samtidigt som man garanterar att endast ett block kan begås per Bitcoins huvudkedjeblock. En annan fördel med Rubens förslag är att det inte kräver en specifik mjuk gaffel för att möjliggöra möjligheten att distribuera rymdkedjor. Eltoo/ANYPREVOUT föreslås för fördelar till Lightning Network, vilket möjliggör flexibla tillståndskedjor, såväl som kanalfabriker. Rymdkedjor är helt enkelt en annan möjlighet av många saker som möjliggörande av ANYPREVOUT skulle bana väg för.

Den allmänna idén med hans förslag till blind sammanslagning av gruvdrift är att du, genom att använda APO, kan fördefiniera en lång uppsättning transaktioner som tar samma initiala UTXO som matas in i dem och förbinder dig att alltid återskapa den. Så föreställ dig en enda satoshi UTXO, där varje förskapad transaktion garanterar att samma UTXO återskapas som en utdata när den bekräftas. Tänk på det som en sorts markör, denna speciella UTXO är identifieraren som låter alla som tittar på den huvudsakliga Bitcoin-blockkedjan veta, "Det är här jag finner ett engagemang för sidokedjan X:s block." Detta lämnar dock ett problem öppet: gruvarbetaravgifter. Om den UTXO måste återskapas med samma summa finns det inga medel att betala avgifter med.

Detta kan hanteras genom att använda SIGHASH_SINGLE (signaturen från en ingång signerar bara den enstaka ingången och motsvarande utgång) och SIGHASH_ANYONECANPAY (människor kan fritt lägga till ytterligare ingångar och utgångar utan att ogiltigförklara signaturen så länge ingången/utgången som använder SIGHASH_SINGLE lämnas som den är, för att inte ogiltigförklara signaturen). Sedan kan vem som helst lägga till en ingång och ändra utdata för att betala gruvarbetaravgifter för transaktionen.

Detta är också den mekanism som används för att binda till sidokedjeblockets blockhuvud. På samma sätt som Taproot förbinder sig till trädet för olika utgiftsvillkor genom att justera den normala publika nyckeln med Merkle-roten av trädet, kan vem som helst justera den normala publika nyckeln med blockhuvudets hash för sidokedjeblocket. Sidokedjenoder kan sedan avslöja och vidarebefordra blockhuvudet med en pekare till transaktionen i huvudkedjan för att bevisa att den faktiskt bröts. Därifrån skulle sidokedjenoder göra all normal validering för att säkerställa att sidokedjeblocket följer korrekta konsensusregler och vidarebefordra de faktiska blocken över sidokedjenätverket precis som i huvudkedjan.

Om en av transaktionerna som användes för att binda till sidokedjeblocken i huvudkedjan användes för att förbinda sig till ett ogiltigt block, eller till och med fullständigt skräpdata, då när sidokedjenoder ser engagemangstransaktionen som används på kedjan, kan två saker hända: En, ett ogiltigt block kommer att spridas över sidokedjenätverket, och när det inte klarar valideringskontroller kommer det att göras föräldralöst; eller två, data avslöjas aldrig, i vilket fall nästa sidokedjeblock kommer att bygga ovanpå och förbinda sig till det sista blocket som faktiskt avslöjas, och det oupptäckta åtagandet kommer att ignoreras. Denna andra möjlighet följer samma typ av längsta kedjas logik som huvudkedjan, så även om något avslöjades senare kommer det fortfarande att vara föräldralöst på grund av framtida block som inte byggde på det.

Men det finns fortfarande problemet med dubbla utgifter. Vem som helst med den privata nyckeln som används för att generera markören UTXO skulle potentiellt kunna dubbelspendera vilken som helst av de fördefinierade transaktionerna som används för att binda sig till sidokedjeblock och ogiltigförklara hela uppsättningen från den punkten och framåt.

Detta löses genom att faktiskt infoga signaturen i låsskriptet för själva UTXO. Detta låser signaturen på ingången och utgången, vilket garanterar återskapandet av markören UTXO i nästa transaktion som använder den. Eftersom den signaturen kommer att skickas automatiskt och kontrolleras när UTXO förbrukas, är det inte möjligt att helt enkelt ersätta den med en annan och spendera den till en annan destination.

Detta lämnar ett sista utestående problem. Det skulle i teorin vara möjligt att skicka in flera transaktioner alla i rad till ett enda Bitcoin-block, så att ett stort antal sidokedjeblock bekräftas av gruvarbetare, alla i ett enda huvudkedjeblock. Detta kan missbrukas för att angripa sidokedjenätverket.

För att lösa detta problem kan ett relativ tidslås för CHECKSEQUENCEVERIFY (CSV) infogas i markör UTXO-skriptet för att garantera att endast en transaktion som använder markören UTXO kan bekräftas inuti ett enda givet huvudkedjeblock.

Sammantaget ser det ut så här: 

Källa

Det är också värt att notera att två varianter av denna design kan implementeras med CHECKTEMPLATEVERIFY (CTV) eller utan några ändringar alls. Dessa två designvarianter har helt enkelt suboptimala avvägningar.

CTV-varianten skulle använda den funktionen för att förbinda sig till kedjan av transaktioner med CTV istället för APO med hacket inklusive signaturen inuti UTXO-låsningsskriptet. CTV förbinder sig till alla utgångar från en transaktion som spenderar CTV UTXO, men den förbinder sig inte till någon input förutom sig själv.

Det betyder att du kan lägga till ingångar, men inte utgångar, till en CTV-transaktion. Så du kan ta med din egen avgift precis som i APO-designen, men du kan inte lägga till ett åtagande till sidokedjeblockets rubrik.

Så vad vi behöver göra här är att skapa en transaktion helt utanför kedjan av CTV-transaktioner för sidokedjans åtagande att skapa en UTXO som precis räcker för att betala avgiften för CTV-transaktionen (eftersom du inte kan skapa en ny ändringsutgång i den transaktionen går 100 % av indata du lägger till till avgifter), och i transaktionen förbereder avgiften UTXO är där vi förbinder oss till ett sidokedjeblockhuvud. Så, första steget: en transaktion som skapar en avgift som betalar utdata och ett åtagande till ett sidokedjeblockhuvud. Andra steget: vi tar avgiftsutgången och lägger till den som en input till CTV-transaktionen, som när den bekräftas "minerar" vårt specifika sidokedjeblock. Denna variant ser ut så här:

Källa

Nästa variant använder helt enkelt försignerade transaktioner. Det skulle kunna distribueras idag, men på grund av begränsningarna för vad skript kan göra, kräver det att alla avgifter för transaktionerna ska betalas i förväg av den som skapar rymdkedjan.

Transaktionskedjan börjar med en enda UTXO och skapar i en kedja två utgångar. Den första utgången är markören UTXO, som signalerar att transaktionskedjan är relaterad till en specifik rymdkedja, den andra är en UTXO med litet värde som kan spenderas öppet av alla som tillåter att en annan ingång/utgång kan kopplas till den. Denna andra transaktion är där vem som helst öppet kan förbinda sig att vara den första att spendera den andra produktionen från rymdkedjans transaktionskedja och använda den för att förbinda sig till sin sidokedjeblockhuvud.

I CTV-varianten måste sidokedjeblocket bindas till i en sekundär transaktion eftersom CTV inte tillåter att lägga till nya utgångar i en transaktion som spenderar en ingång låst av CTV. Denna variant kräver att du använder en sekundär transaktion eftersom om du lägger till några nya ingångar eller utgångar till den försignerade kedjan, skulle du ändra TXID för transaktionen och ogiltigförklara alla försignerade transaktioner som kommer efter den. Denna variant ser ut så här: 

Källa

Nackdelen med den här sista varianten är att om den som förhandssignerade alla transaktioner som ska användas för sidokedjeblockeringsåtaganden inte tar bort de privata nycklarna som används för att göra det, kan de effektivt stoppa kedjan genom att dubbla utgifterna för den aktuella markören UTXO när som helst tid.

Och där har du det. Detta är det senaste förslaget för en sidokedjedesign på Bitcoin, och det kan implementeras på tre olika sätt, med den uppenbara varningen att implementeringsvägen som kan göras nu har frågan om att kräva att någon raderar en privat nyckel.

Den här artikeln är helt enkelt den första i en serie som rör de stora sidokedjedesignförslagen som har publicerats för Bitcoin sedan den ursprungliga designen från 2014. Håll utkik efter resten.

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.

Tidsstämpel:

Mer från Bitcoin Magazine