Spacechains: hoe dit nieuwe Bitcoin-sidechain-voorstel werkt

Bronknooppunt: 1544330

Spacechains is een voorgestelde Bitcoin-zijketen die een eenrichtingspeg-mechanisme biedt dat gebruik maakt van blind merge mine-ontwerp.

Het idee van zijketens als schaal- en functie-uitbreidingsmechanisme voor Bitcoin is een heel oud concept. Een soort basis "voorouder"-idee van zijketens, gedolven ketens samenvoegen, gaat zelfs terug tot voordat Satoshi verdween.

Dat voorstel was gewoon het idee dat twee volledig afzonderlijke en niet-gerelateerde ketens worden gedolven door dezelfde groep mijnwerkers, zonder de mogelijkheid om iets tussen ketens te verplaatsen. De origineel voorstel voor sidechain werd in 2014 gemaakt door veel van de mensen die Blockstream letterlijk een week of zo na de publicatie van de krant oprichtten. Het basisidee was om munten heen en weer te kunnen laten bewegen tussen de belangrijkste Bitcoin-blockchains en andere zijketens, met eenvoudige betalingsverificatie (SPV) bewijzen die worden gebruikt om te bewijzen dat dingen geldig zijn wanneer je munten van de ene keten naar de andere stuurt. Dit is nooit van de grond gekomen vanwege de complexiteit van de implementatie rond ketenreorganisaties, de kans op diefstal en de risico's van centralisatie van de mijnbouw (waarover u kunt lezen in paragraaf vier van de Bitcoin-wit papier).

Peg-mechanismen voor zijketens kunnen van twee soorten zijn, eenrichtingsverkeer en tweerichtingsverkeer. De betekenissen moeten duidelijk zijn - in een tweerichtingspeg kunnen munten heen en weer bewegen tussen de bovenliggende ketting en de zijketen, en in een eenrichtingspin kunnen ze alleen van de bovenliggende keten naar de zijketen bewegen en nooit teruggaan. Momenteel is de enige vorm van two-way sidechain-pegs die op Bitcoin zijn geรฏmplementeerd, via federatieve consensus, wat betekent dat de peg wordt gegarandeerd door een vertrouwde set van "bewaarders" die de controle behouden over fondsen die in de zijketen in een multisig-portemonnee zijn vastgemaakt totdat ze worden ingetrokken.

Mensen zijn echter blijven werken aan andere ontwerpen voor zijketenpinnen die niet zijn gefedereerd. Hier ga ik als voorbeeld het Spacechain-voorstel van Ruben Somsen doornemen. Het is een eenrichtingspinmechanisme dat een blind merge-mijnontwerp gebruikt, vergelijkbaar met: Paul Stztorc's. Dit betekent dat munten alleen in de zijketen kunnen gaan en nooit meer weggaan, en dat miners geen nieuwe software hoeven te gebruiken om compensatie te krijgen voor het minen van de zijketen (maar, zoals ik later zal bespreken, kunnen ze er meer van profiteren).

Het Spacechain-voorstel

Merge mining vereist dat miners de knooppunten van zowel de Bitcoin-keten als elke andere keten die ze minen, uitvoeren om de blokken voor beide ketens te compileren en zich eraan te committeren in de Bitcoin-blokheader die ze aan het minen zijn. Blind merge-mining maakt gebruik van het feit dat de Bitcoin-mijnwerkers in werkelijkheid alleen de blokheader van de andere keten nodig hebben om zich aan te binden in hun Bitcoin-blok, iemand anders kan de moeite nemen om het blok voor de andere keten samen te stellen.

Somsen's voorgestelde mechanisme hiervoor kan gebruik maken van: IEDEREEN (APO) om open concurrentie voor iedereen mogelijk te maken om te kunnen concurreren om het volgende zijketenblok te bouwen, terwijl wordt gegarandeerd dat er slechts รฉรฉn blok kan worden vastgelegd per Bitcoin-hoofdketenblok. Een ander voordeel van Rubens voorstel is dat er geen specifieke zachte vork nodig is om ruimteketens in te zetten. Eltoo/ANYPREVOUT wordt voorgesteld voor voordelen voor het Lightning Network, waardoor flexibele statechains en kanaalfabrieken mogelijk worden. Spacechains zijn gewoon een andere mogelijkheid van de vele dingen waarvoor het inschakelen van ANYPREVOUT de weg zou effenen.

Het algemene idee van zijn voorstel voor blind merge-mijnbouw is dat je, door gebruik te maken van APO, een lange reeks transacties vooraf kunt definiรซren waarbij dezelfde initiรซle UTXO wordt ingevoerd en je ertoe verbindt deze altijd opnieuw te creรซren. Stel je dus een enkele satoshi UTXO voor, waarbij elke vooraf gemaakte transactie garandeert dat diezelfde UTXO na bevestiging opnieuw wordt gemaakt als uitvoer. Zie het als een soort markering, deze speciale UTXO is de identifier waarmee iedereen die naar de belangrijkste Bitcoin-blockchain kijkt, weet: "Hier vind ik een verbintenis om de blokken van X in de zijketen te zetten." Dit laat echter รฉรฉn probleem open: mijnwerkersvergoedingen. Als die UTXO met hetzelfde bedrag opnieuw moet worden gemaakt, is er geen geld om kosten mee te betalen.

Dit kan worden aangepakt door gebruik te maken van SIGHASH_SINGLE (de handtekening van een invoer tekent alleen die ene invoer en de bijbehorende uitvoer) en SIGHASH_IEDEREEN KAN BETALEN (mensen zijn vrij in staat om extra inputs en outputs toe te voegen zonder de handtekening ongeldig te maken, zolang de input/output met SIGHASH_SINGLE wordt gelaten zoals het is, om die handtekening niet ongeldig te maken). Dan kan iedereen een invoer toevoegen en de uitvoer wijzigen om mijnwerkersvergoedingen voor de transactie te betalen.

Dit is ook het mechanisme dat wordt gebruikt om vast te leggen aan de blokkop van het zijketenblok. Op dezelfde manier waarop Taproot zich verbindt aan de boom met verschillende bestedingsvoorwaarden door de normale openbare sleutel aan te passen met de Merkle-wortel van de boom, kan iedereen de normale openbare sleutel aanpassen met de blokkop-hash van het zijketenblok. Sidechain-knooppunten kunnen vervolgens die block-header onthullen en doorgeven met een aanwijzer naar transactie in de hoofdketen om te bewijzen dat deze daadwerkelijk is gedolven. Van daaruit zouden zijketenknooppunten alle normale validatie uitvoeren om ervoor te zorgen dat het zijketenblok de juiste consensusregels volgt, en de daadwerkelijke blokken over het zijketennetwerk doorgeven, net als in de hoofdketen.

Als een van de transacties die zijn gebruikt om de zijketenblokken in de hoofdketen vast te leggen, werd gebruikt om een โ€‹โ€‹ongeldig blok vast te leggen, of zelfs om gegevens volledig weg te gooien, dan kunnen er twee dingen gebeuren wanneer zijketenknooppunten de vastleggingstransactie zien die in de keten is gebruikt: Eรฉn, een ongeldig blok wordt verspreid over het zijketennetwerk en wanneer het de validatiecontroles niet doorstaat, wordt het wees; of twee, de gegevens worden nooit onthuld, in welk geval het volgende zijketenblok bovenop het laatste blok zal bouwen en zich zal committeren aan het laatste daadwerkelijk onthulde blok, en de niet-geopenbaarde verplichting zal worden genegeerd. Deze tweede mogelijkheid volgt dezelfde soort logica van de langste keten als de hoofdketen, dus zelfs als iets later werd onthuld, zal het nog steeds wees zijn vanwege toekomstige blokken die er niet op voortbouwen.

Maar er is nog steeds het probleem van dubbele uitgaven. Iedereen met de privรฉsleutel die is gebruikt om de marker UTXO te genereren, kan mogelijk een van de vooraf gedefinieerde transacties die worden gebruikt om zich aan sidechain-blokken vast te leggen, verdubbelen en vanaf dat moment de hele set ongeldig maken.

Dit wordt opgelost door de handtekening daadwerkelijk in het vergrendelingsscript van de UTXO zelf in te voegen. Dit vergrendelt de handtekening op de invoer en uitvoer, waardoor de recreatie van de marker UTXO wordt gegarandeerd bij de volgende transactie die deze gebruikt. Omdat die handtekening automatisch wordt doorgegeven en gecontroleerd wanneer de UTXO wordt uitgegeven, is het niet mogelijk om deze eenvoudigweg door een andere te vervangen en naar een andere bestemming te besteden.

Dit laat nog een laatste openstaand probleem over. Het zou in theorie mogelijk zijn om meerdere transacties achter elkaar in een enkel Bitcoin-blok in te dienen, zodat een groot aantal zijketenblokken door miners worden bevestigd, allemaal in een enkel hoofdketenblok. Dit kan worden misbruikt om het zijketennetwerk aan te vallen.

Om dit probleem op te lossen, kan een CHECKSEQUENCEVERIFY (CSV) relatief tijdslot worden ingevoegd in het marker UTXO-script om te garanderen dat slechts รฉรฉn transactie met behulp van de marker UTXO kan worden bevestigd binnen een enkel gegeven hoofdketenblok.

Alles bij elkaar ziet het er zo uit: 

bron

Het is ook vermeldenswaard dat twee varianten van dit ontwerp kunnen worden geรฏmplementeerd met CHECKTEMPLATEVERIFY (CTV) of zonder enige wijziging. Deze twee ontwerpvarianten hebben simpelweg suboptimale afwegingen.

De CTV-variant zou die functionaliteit gebruiken om zich te committeren aan de keten van transacties met behulp van CTV in plaats van APO met de hack inclusief de handtekening in het UTXO-vergrendelingsscript. CTV verplicht zich tot alle resultaten van een transactie die de CTV UTXO besteedt, maar verbindt zich niet tot enige andere invoer dan zichzelf.

Dit betekent dat u inputs, maar geen outputs, aan een CTV-transactie kunt toevoegen. U kunt dus uw eigen vergoeding meenemen, net als in het APO-ontwerp, maar u kunt geen toezegging toevoegen aan de header van het zijketenblok.

Wat we hier dus moeten doen, is een transactie creรซren die volledig buiten de keten van CTV-transacties ligt voor de zijketentoezegging om een โ€‹โ€‹UTXO te creรซren die net genoeg is om de vergoeding voor de CTV-transactie te betalen (omdat u geen nieuwe wijzigingsuitvoer kunt creรซren in die transactie, 100% van de input die u toevoegt, gaat naar vergoedingen), en binnen de transactie die de vergoeding voorbereidt, is UTXO waar we ons committeren aan een sidechain-blokheader. Dus eerste stap: een transactie die een betalende output creรซert en een verbintenis tot een sidechain-blokheader. Tweede stap: we nemen de uitvoer van de vergoeding en voegen deze toe als invoer voor de CTV-transactie, die, wanneer bevestigd, ons specifieke zijketenblok "mijnt". Deze variant ziet er als volgt uit:

bron

De volgende variant maakt gewoon gebruik van vooraf ondertekende transacties. Het zou vandaag kunnen worden ingezet, maar vanwege de beperkingen van wat script kan doen, moeten alle vergoedingen voor de transacties vooraf worden betaald door degene die de ruimteketen maakt.

De keten van transacties begint met een enkele UTXO en creรซert in een keten twee outputs. De eerste output is de marker UTXO, die aangeeft dat de transactieketen gerelateerd is aan een specifieke spacechain, de tweede is een UTXO met een kleine waarde die openlijk besteed kan worden door iedereen die het mogelijk maakt om er een andere input/output aan te koppelen. Deze tweede transactie is waar iedereen zich openlijk kan verbinden om de eerste te zijn die die tweede output van de spacechain-transactieketen uitgeeft, en deze te gebruiken om zich te committeren aan hun sidechain-blokheader.

In de CTV-variant moest het zijketenblok worden vastgelegd in een secundaire transactie omdat CTV niet toestaat nieuwe outputs toe te voegen aan een transactie waarbij een input wordt uitgegeven die is vergrendeld door CTV. Deze variant vereist het gebruik van een secundaire transactie, want als u nieuwe invoer of uitvoer toevoegt aan de vooraf ondertekende keten, zou u de TXID van de transactie wijzigen en alle vooraf ondertekende transacties die erna komen ongeldig maken. Deze variant ziet er als volgt uit: 

bron

Het enige nadeel van deze laatste variant is dat als degene die alle transacties vooraf heeft ondertekend om te gebruiken voor sidechain-bloktoezeggingen niet de privรฉsleutels verwijdert die daarvoor zijn gebruikt, ze de keten effectief kunnen stoppen door de huidige marker UTXO dubbel te besteden tijd.

En daar heb je het. Dit is het meest recente voorstel voor een sidechain-ontwerp op Bitcoin, en het kan op drie verschillende manieren worden geรฏmplementeerd, met het voor de hand liggende voorbehoud dat het implementatiepad dat nu kan worden gedaan het probleem heeft dat iemand een privรฉsleutel moet verwijderen.

Dit artikel is gewoon het eerste in een reeks met betrekking tot de belangrijkste ontwerpvoorstellen voor zijketens die sinds het oorspronkelijke ontwerp van 2014 voor Bitcoin zijn gepubliceerd. Houd de rest in de gaten.

Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.

Tijdstempel:

Meer van Bitcoin Magazine