Spacechains: Hvordan dette nye Bitcoin Sidechain-forslaget fungerer

Spacechains er en foreslått Bitcoin-sidekjede som tilbyr en enveis pinnemekanisme som bruker blind sammenslåingsgruvedesign.

Ideen om sidekjeder som en skalerings- og funksjonsutvidelsesmekanisme for Bitcoin er et veldig gammelt konsept. En slags grunnleggende "forfedre" idé om sidekjeder, slå sammen utvunnede kjeder, går til og med tilbake til før Satoshi forsvant.

Det forslaget var rett og slett ideen om at to helt separate og urelaterte kjeder ble utvunnet av samme gruppe gruvearbeidere, uten mulighet til å flytte noe mellom kjeder. De originalt sidekjedeforslag ble laget i 2014 av mange av menneskene som fortsatte med å grunnlegge Blockstream bokstavelig talt en uke eller så etter at avisen ble publisert. Den grunnleggende ideen var å kunne få mynter til å bevege seg frem og tilbake mellom den viktigste Bitcoin-blokkjeden og andre sidekjeder, med enkel betalingsverifisering (SPV) bevis som ble brukt for å bevise at ting er gyldige når du sender mynter fra den ene kjeden til den andre. Dette ble aldri realisert på grunn av kompleksiteten i implementeringen rundt kjedereorganiseringer, potensialet for tyveri og risikoen for sentralisering av gruvedrift (som alt kan leses om i avsnitt fire av Hvitbok fra Bitcoin).

Pinnemekanismer for sidekjeder kan være av to varianter, enveis og toveis. Betydningen bør være åpenbar - i en toveis knagg kan mynter bevege seg frem og tilbake mellom overordnet kjede og sidekjede, og i en enveis knagg kan de bare bevege seg fra overordnet kjede til sidekjede og aldri flytte tilbake. Foreløpig er den eneste formen for toveis sidekjedepinner implementert på Bitcoin gjennom føderert konsensus, noe som betyr at pinnen er garantert av et pålitelig sett med "depotforvaltere" som opprettholder kontroll over midler som er koblet til sidekjeden i en multisig-lommebok til de trekkes tilbake.

Folk har imidlertid fortsatt å jobbe med andre design for sidekjedepinner som ikke er forent. Her skal jeg gå gjennom Ruben Somsens Spacechain-forslag som ett eksempel. Det er en enveis pinnemekanisme som bruker en blind sammenslåingsgruvedesign, lik Paul Stztorc's. Dette betyr at mynter bare kan gå inn i sidekjeden og aldri forlate, og at gruvearbeidere ikke trenger å kjøre ny programvare for å få kompensasjon for utvinning av sidekjeden (men, som jeg skal gå inn på senere, kan de tjene mer på å gjøre det).

Spacechain-forslaget

Sammenslåing av gruvedrift krever at gruvearbeidere kjører nodene til både Bitcoin-kjeden og hvilken som helst annen kjede de utvinner, for å kompilere blokkene for begge kjedene og forplikte seg til dem i Bitcoin-blokkoverskriften de utvinner. Blind merge mining utnytter det faktum at i virkeligheten trenger Bitcoin-gruvearbeiderne egentlig bare å ha den andre kjedens blokkhode å forplikte seg til i sin Bitcoin-blokk, noen andre kan faktisk ta bryet med å sette sammen blokken for den andre kjeden.

Somsens foreslåtte mekanisme for dette kan utnytte NOEN FORHÅNDEN (APO) for å tillate åpen konkurranse for alle å kunne konkurrere om å konstruere den neste sidekjedeblokken mens man garanterer at kun én blokk kan forpliktes per Bitcoin hovedkjedeblokk. En annen fordel med Rubens forslag er at det ikke krever en spesifikk myk gaffel for å muliggjøre muligheten for å distribuere romkjeder. Eltoo/ANYPREVOUT blir foreslått for fordeler til Lightning Network, som muliggjør fleksible statechains, så vel som kanalfabrikker. Romkjeder er ganske enkelt en annen mulighet for de mange tingene som muliggjøring av ANYPREVOUT ville bane vei for.

Den generelle ideen med hans blinde fusjonsgruveforslag er at du ved å bruke APO kan forhåndsdefinere et langt sett med transaksjoner som tar den samme initiale UTXO matet inn i dem og forplikter deg til å alltid gjenskape den. Så forestill deg en enkelt satoshi UTXO, med hver forhåndsopprettede transaksjon som garanterer at den samme UTXO gjenskapes som en utgang når den bekreftes. Tenk på det som en slags markør, denne spesielle UTXO er identifikatoren som lar alle som ser på den viktigste Bitcoin-blokkkjeden vite, "Det er her jeg finner en forpliktelse til sidekjede Xs blokker." Dette etterlater imidlertid ett problem åpent: gruvearbeideravgifter. Hvis den UTXO må gjenskapes med samme beløp, er det ingen midler å betale gebyrer med.

Dette kan håndteres ved å benytte SIGHASH_SINGLE (signaturen fra en inngang signerer bare den enkeltinngangen, og den tilsvarende utgangen) og SIGHASH_ANYONECANPAY (Folk kan fritt legge til flere innganger og utganger uten å ugyldiggjøre signaturen så lenge inngangen/utgangen ved bruk av SIGHASH_SINGLE blir stående som den er, for ikke å ugyldiggjøre den signaturen). Deretter kan hvem som helst legge til en inngang og endre utgang for å betale gruvearbeideravgifter for transaksjonen.

Dette er også mekanismen som brukes til å binde seg til blokkhodet til sidekjedeblokken. På samme måte som Taproot forplikter seg til treet av forskjellige forbruksbetingelser ved å justere den vanlige offentlige nøkkelen med Merkle-roten til treet, kan hvem som helst justere den vanlige offentlige nøkkelen med blokkhode-hashen til sidekjedeblokken. Sidekjede-noder kan deretter avsløre og videresende blokkhodet med en peker til transaksjonen i hovedkjeden for å bevise at den faktisk ble utvunnet. Derfra vil sidekjede-noder gjøre all normal validering for å sikre at sidekjedeblokken følger riktige konsensusregler, og videresende de faktiske blokkene over sidekjedenettverket akkurat som på hovedkjeden.

Hvis en av transaksjonene som brukes til å forplikte seg til sidekjedeblokkene på hovedkjeden ble brukt til å forplikte seg til en ugyldig blokk, eller til og med fullstendig søppeldata, så når sidekjedens noder ser forpliktelsestransaksjonen brukt på kjeden, kan to ting skje: En, en ugyldig blokk vil spres over sidekjedenettverket, og når den ikke klarer å bestå valideringssjekker, vil den bli foreldreløs; eller to, dataene avsløres aldri, i så fall vil den neste sidekjedeblokken bygge på toppen av og forplikte seg til den siste blokken som faktisk avsløres, og den uavslørte forpliktelsen vil bli ignorert. Denne andre muligheten følger samme type logikk med lengste kjede som hovedkjeden, så selv om noe ble avslørt senere, vil det fortsatt være foreldreløst på grunn av fremtidige blokker som ikke bygget på det.

Men det er fortsatt problemet med dobbeltforbruk. Alle som har den private nøkkelen som brukes til å generere markøren UTXO, kan potensielt doble en hvilken som helst av de forhåndsdefinerte transaksjonene som brukes til å forplikte seg til sidekjedeblokker og ugyldiggjøre hele settet fra det tidspunktet og fremover.

Dette løses ved å faktisk sette inn signaturen i låseskriptet til selve UTXO. Dette låser signaturen på inngangen og utgangen, og garanterer gjenskaping av markøren UTXO i neste transaksjon som bruker den. Fordi den signaturen automatisk skal sendes og sjekkes når UTXO er brukt, er det ikke mulig å bare erstatte den med en annen og bruke den til en annen destinasjon.

Dette etterlater et siste utestående problem. Det ville være mulig, i teorien, å sende inn flere transaksjoner alle på rad i en enkelt Bitcoin-blokk, slik at et stort antall sidekjedeblokker bekreftes av gruvearbeidere alle i en enkelt hovedkjedeblokk. Dette kan misbrukes til å angripe sidekjedenettverket.

For å løse dette problemet, kan en CHECKSEQUENCEVERIFY (CSV) relativ tidslås settes inn i markør UTXO-skriptet for å garantere at bare én transaksjon ved bruk av markør UTXO kan bekreftes inne i en enkelt gitt hovedkjedeblokk.

Til sammen ser det slik ut: 

Det er også verdt å merke seg at to varianter av denne designen kan implementeres med CHECKTEMPLATEVERIFY (CTV) eller uten endringer i det hele tatt. Disse to designvariantene har rett og slett suboptimale avveininger.

CTV-varianten vil bruke denne funksjonaliteten til å forplikte seg til kjeden av transaksjoner ved å bruke CTV i stedet for APO med hacket inkludert signaturen inne i UTXO-låseskriptet. CTV forplikter seg til alle utgangene av en transaksjon som bruker CTV UTXO, men den forplikter seg ikke til noen input utenom seg selv.

Dette betyr at du kan legge til innganger, men ikke utganger, til en CTV-transaksjon. Så du kan ta med din egen avgift akkurat som i APO-designen, men du kan ikke legge til en forpliktelse til sidekjedeblokkoverskriften.

Så det vi må gjøre her er å opprette en transaksjon helt utenfor kjeden av CTV-transaksjoner for sidekjedeforpliktelsen for å lage en UTXO som akkurat er nok til å betale gebyret for CTV-transaksjonen (fordi du ikke kan opprette en ny endringsutgang i den transaksjonen går 100 % av inndataene du legger til gebyrer), og inne i transaksjonen forbereder gebyret UTXO hvor vi forplikter oss til en sidekjedeblokkoverskrift. Så, første trinn: en transaksjon som skaper et gebyr som betaler utgang og en forpliktelse til en sidekjedeblokkoverskrift. Andre trinn: vi tar gebyrutgangen og legger den til som en input til CTV-transaksjonen, som når den er bekreftet "miner" vår spesifikke sidekjedeblokk. Denne varianten ser slik ut:

Den neste varianten bruker ganske enkelt forhåndssignerte transaksjoner. Det kan distribueres i dag, men på grunn av begrensningene for hva skriptet kan gjøre, krever det at alle avgiftene for transaksjonene skal betales på forhånd av den som lager romkjeden.

Transaksjonskjeden starter med en enkelt UTXO, og i en kjede skapes to utganger. Den første utgangen er markøren UTXO, som signaliserer at kjeden av transaksjoner er relatert til en spesifikk romkjede, den andre er en liten verdi UTXO som kan brukes åpent av alle som tillater å knytte en annen inngang/utgang til den. Denne andre transaksjonen er der hvem som helst åpent kan forplikte seg til å være den første til å bruke den andre utgangen fra romkjedetransaksjonskjeden, og bruke den til å forplikte seg til sidekjedeblokkoverskriften.

I CTV-varianten måtte sidekjedeblokken forpliktes i en sekundær transaksjon fordi CTV ikke tillater å legge til nye utganger i en transaksjon med en inngang som er låst av CTV. Denne varianten krever bruk av en sekundær transaksjon fordi hvis du legger til nye innganger eller utganger til den forhåndssignerte kjeden, vil du endre TXID-en til transaksjonen og ugyldiggjøre alle forhåndssignerte transaksjoner som kommer etter den. Denne varianten ser slik ut: 

Den ene ulempen med denne siste varianten er at hvis den som forhåndssignerte alle transaksjonene som skal brukes for sidekjedeblokkforpliktelser ikke sletter de private nøklene som ble brukt til å gjøre det, kan de effektivt stoppe kjeden ved å dobbeltbruke gjeldende markør UTXO til enhver tid. tid.

Og der har du det. Dette er det siste forslaget for et sidekjededesign på Bitcoin, og det kan implementeres på tre forskjellige måter, med det åpenbare forbeholdet at implementeringsveien som kan gjøres nå har problemet med å kreve at noen sletter en privat nøkkel.

Denne artikkelen er rett og slett den første i en serie relatert til de store sidekjededesignforslagene som har blitt publisert for Bitcoin siden det opprinnelige 2014-designet. Hold øye med resten.

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

• Myntsmart. Europas beste Bitcoin og Crypto Exchange.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. FRI TILGANG.
• CryptoHawk. Altcoin Radar. Gratis prøveperiode.
• Kilde: https://bitcoinmagazine.com/technical/how-bitcoin-spacechains-work