Federated Sidechains zijn de originele upgradebare sidechain-implementatie van Bitcoin

Dit is een opinieredactioneel commentaar van Shinobi, een autodidactische opvoeder in de Bitcoin-ruimte en technisch georiënteerde Bitcoin-podcasthost.

Federatieve zijketens zijn momenteel het enige gebruikte type Bitcoin-zijketen (de meest recente paper) hier). Het idee om een ​​federated peg- en consensussysteem te gebruiken was eigenlijk een aanhangsel in de originele sidechains whitepaper. Er was geen concreet ontwerp voor elk type tweerichtingspeg waarbij mijnwerkers betrokken waren, dus een gefedereerde peg werd beschreven als een manier om nu een zijketen in te zetten en te upgraden naar een tweerichtingsverificatie peg met behulp van eenvoudige betalingsverificatie (SPV) bewijzen vergelijkbaar met wat zachte kettingen doen, wanneer er concreet iets is ontworpen dat veilig en inzetbaar was. Er werd ook op gewezen dat het voor zeer kleine systemen gevaarlijk kan zijn om een ​​op mijnwerkers gebaseerde pin te gebruiken, omdat ze van een zeer kleine groep mensen kunnen stelen zonder veel consensus om er iets aan te doen vanuit het bredere Bitcoin-systeem . Federaties kunnen nuttig zijn voor kleinere systemen waar de groep gebruikers niet groot genoeg is om miners te ontmoedigen om munten te stelen.

Het algemene idee is om effectief een blockchain te hebben waarbij een geselecteerde groep vertrouwde partijen bitcoin in het systeem vastgepend met multisig bewaren en de blokken op de zijketen produceren, ondertekenen met cryptografische sleutels in plaats van proof-of-work te gebruiken. Het hele beveiligingsmodel is gebaseerd op het hebben van een behoorlijk groot aantal verschillende deelnemers in de groep, of federatie, die zeer geografisch verspreid zijn en publiekelijk bekend zijn.

Federaties gebruiken een drempel van leden voor zowel de bewaring van bitcoin op de mainchain als blocksigning, dwz een 5-of-7 multisig. Dit gebeurt in plaats van dat alle zeven leden moeten tekenen om de twee belangrijkste risico's van een dergelijk systeem in evenwicht te brengen: diefstal versus verlies. De federatie kan samen alle fondsen stelen die opgesloten zitten in een gefedereerde zijketen als ze ervoor kiezen om samen te werken om dit te doen; daarom is het hele beveiligingsmodel gebaseerd op veel verschillende actoren in veel verschillende rechtsgebieden. Je wilt dat het buitengewoon moeilijk en onwaarschijnlijk is dat veel verschillende regeringen allemaal samenwerken om een ​​federatie te dwingen iets kwaadaardigs te doen, dus je wilt dat een groot aantal mensen dingen moet ondertekenen. Aan de andere kant, als u wilt dat alle zeven leden alles ondertekenen, is alles wat nodig is een enkel lid om de toegang tot hun sleutels te verliezen, wat resulteert in permanent verlies van alle fondsen in de zijketen. Daarom moet een meerderheid van de leden ondertekenen, maar niet allemaal. Dit laat enige foutenmarge over voor sleutelverlies, terwijl er ook nog steeds een groot aantal leden moet worden gedwongen of samengespannen om te resulteren in diefstal van fondsen.

Dit maakt het beveiligingsmodel van het systeem tweerichtingsverkeer in termen van beveiligingsdrempels. Zoals eerder vermeld, moeten vijf van de zeven deelnemers in deze hypothetische situatie, om het geld actief te stelen, samenspannen of worden gedwongen tot samenspannen om de zijketenfondsen te stelen. Slechts drie van de zeven deelnemers moeten echter hun sleutels verliezen, vernietigen of gedwongen worden om hun sleutels uit te schakelen om de zijketenfondsen bevroren te laten en niet te kunnen verplaatsen - mogelijk permanent. De drempels zijn een evenwichtsoefening tussen deze twee risico's.

Beide moeten tegelijkertijd hoog genoeg zijn om te voorkomen dat beide ergste gevallen zich voordoen.

Afgezien van deze kerneigenschappen is er een grote mate van vrijheid in hoe u een gefedereerde zijketen zou kunnen implementeren, zowel wat betreft het ontwerpen van de zijketen zelf als hoe u het sleutelbeheer voor de blokondertekening en peg-bewaringssleutels afhandelt.

Vloeistof

Liquid was de eerste gefedereerde zijketen die op Bitcoin werd ingezet, ontworpen voor privétransacties tussen beurzen voor handel en uitgifte van andere activa zoals stablecoins of equity-tokens. De codebase is bijna volledig gebaseerd op die van Bitcoin zelf. Een van de belangrijkste kenmerken van het Liquid-netwerk was de implementatie van: Vertrouwelijke transacties, een functie die gebruikmaakt van cryptografische bereikbewijzen om de bedragen die in transacties worden verzonden te verbergen, maar onder bepaalde veronderstellingen toch een garantie te bieden dat er geen geld wordt uitgegeven dat niet bestaat. Vloeistof ook geïmplementeerd Vertrouwelijke activa, een uitbreiding op Vertrouwelijke Transacties. Confidential Assets verbergt welk token naast het bedrag wordt uitgegeven.

Deze twee functies gecombineerd bieden een sterke oplossing voor een van de grote tekortkomingen die mogelijk zijn met een gefedereerde zijketen: censuur. Een drempelmeerderheid (in onze hypothetische 5-van-7-federatie hierboven) zou allemaal kunnen instemmen met het censureren van specifieke transacties of UTXO's als ze daar allemaal reden voor hadden, zoals vermoedelijke of bevestigde illegale activiteiten. In zo'n geval zouden ze zelfs een rationele prikkel hebben om dat te doen, om regeringen geen reden te geven om achter het hele systeem aan te gaan. Vertrouwelijke transacties/activa kunnen een voldoende hoog niveau van privacy bieden dat zelfs als een federatie reden heeft om bepaalde soorten transacties te censureren, het zeer moeilijk zou zijn om ze uit te kiezen om dit te doen.

Een peg-in-transactie op Liquid is een relatief eenvoudig proces in twee stappen. Een gebruiker die wil inpluggen, neemt het multisig-adres van de federatie en "tweakt" vervolgens elke openbare sleutel die erbij betrokken is met behulp van betalen-naar-contract met een Liquid-adres dat ze beheren, om nieuwe openbare sleutels te maken. De federatieleden kunnen de overeenkomende privésleutels afleiden zodra ze het gebruikte Liquid-adres leren. Totdat die informatie wordt onthuld, weet niemand, zelfs de federatie niet, dat een transactie naar dit aangepaste adres een Liquid-peg-in is. Vervolgens zendt de gebruiker de transactie uit op de hoofdketen en wacht op 100 bevestigingen. Zodra de bevestigingen zijn opgebouwd, kan de gebruiker een transactie op het Liquid-netwerk indienen om zijn munten naar zichzelf te verzenden. Deze transactie maakt gebruik van een speciale invoer die het Liquid-adres bevat waarmee ze de sleutels van de federatie hebben aangepast, een handtekening die bewijst dat ze deze controleren en een Merkle-bewijs dat aantoont dat de mainchain-peg-in-transactie ten minste 100 bevestigingen heeft.

Het peg-out proces is veel eenvoudiger. Een gebruiker construeert een transactie die bitcoin op Liquid verbrandt met behulp van OP_RETURN, een adres bevat om naar de hoofdketen te verzenden en een speciaal nulkennisbewijs van een van de federatieleden (welke is verborgen). Wanneer federatieleden een dergelijke transactie zien met een geldig lidbewijs, zullen ze een opname tekenen op de hoofdketen. Het bewijs wordt geïmplementeerd om frauduleuze of ongeldige opnames te voorkomen en stelt elk federatielid dat het bewijs levert in staat om whitelisting of beperkingen op peg-outs af te dwingen. Iedereen kan bitcoin vrijelijk in het Liquid-netwerk pinnen, maar een relatie met een federatielid is vereist om te peg-out.

Op het gebied van sleutelbeheer en beveiliging heeft Blockstream Hardware Security Modules (HSM's) ontwikkeld om de sleutels af te handelen en ondertekeningsbewerkingen uit te voeren. Deze apparaten beveiligen de sleutels die worden gebruikt voor het ondertekenen van blokken en peg-ins/outs, en beschermen ze tegen manipulatie of sleutelextractie. Om enige vorm van herstel te bieden in het geval dat defecte apparaten sleutels verliezen, maar ook om te beschermen tegen sleutelextractie voor kwaadwillende doeleinden, worden back-ups van elke lidsleutel versleuteld bewaard zodat zowel dat lid als Blockstream moeten samenwerken om decodeer de sleutel voor het laden in een nieuwe HSM. Geen van beide partijen kan de back-up alleen ontsleutelen. Een laatste verdedigingslinie tegen sleutelverlies zijn de sleutels voor noodopname. Elk adres waar de federatie penmunten naar ophaalt, heeft twee bestedingspaden: de vereiste drempel van de federatie en na ongeveer een maand timelock (hoewel de tijdsduur kan worden gewijzigd) de vereiste drempel van de noodsleutels. Dit is een tweede set sleutels die kan worden onderhouden door de federatie, een andere partij of een combinatie daarvan om ervoor te zorgen dat munten kunnen worden teruggevonden als er te veel federatiesleutels verloren gaan. De federatie verplaatst regelmatig de munten op de hoofdketen die ze in bewaring hebben voordat de tijdslot verloopt, dus zolang de federatie niet heeft gefaald, zal dit noodpad nooit besteed kunnen worden. Momenteel onderhoudt Blockstream de herstelsleutels die geografisch verspreid zijn.

Ten slotte is er een functionaliteit genaamd "Dynamic Federations". Hierdoor kan een grote meerderheid van de federatie het lidmaatschap bijwerken, leden toevoegen of verwijderen. Dit wordt gedaan door middel van een software-update van de ondertekeningssoftware nadat is besloten welke nieuwe leden moeten worden toegevoegd of bestaande leden moeten worden verwijderd en vervolgens een signaleringsperiode van een maand. Als gedurende een maand viervijfde van de blokken die zijn gesignaleerd voor de federatiewijziging, "forks" om de nieuwe federatie te herkennen als blokondertekenaars. Het netwerk begint dan nieuwe peg-in-adressen te gebruiken bij de nieuwe federatie, maar herkent de oude nog voor een extra maand om ervoor te zorgen dat er geen peg-ins ongeldig worden gemaakt tijdens de federatiewijziging. Het is ook niet toegestaan ​​om zoveel federatieleden te verwijderen dat er niet genoeg meer over is om te tekenen voor terugtrekking van oude adressen. Al deze aspecten van federatie-upgrades maken deel uit van de consensusregels en worden afgedwongen/gevalideerd door de HSM's.

Onderstam (RSK)

Onderstam is een federatieve zijketen met veel ontwerpverschillen ten opzichte van Liquid. Ten eerste is het in wezen een copy-paste-kloon van Ethereum in termen van functionaliteit. Het ondersteunt Solidity, de scripttaal die door Ethereum wordt gebruikt, volledig, zodat elk contract dat op Ethereum wordt geïmplementeerd, triviaal overdraagbaar is naar Rootstock. De reden hiervoor is uiteraard dat Ethereum veel vraag heeft en functionaliteit kan leveren waar Bitcoin niet toe in staat is. Het is duidelijk dat er veel nadelen en risico's zijn aan de architectuur van Ethereum, maar je kunt niet ontkennen dat er vraag naar is.

Een ander groot verschil op het gebied van architectuur is wat de federatie doet: ze beheren gezamenlijk een multisig die de fondsen op de hoofdketen beheert, maar de federatie neemt in normale omstandigheden niet deel aan het slaan van blokken. Dit wordt gedaan door Bitcoin-mijnwerkers door middel van samengevoegde mijnbouw, waardoor ze tegelijkertijd Bitcoin en Rootstock kunnen minen. Hoewel dit geen significant veiligheidsverschil oplevert voor Bitcoin die is gekoppeld aan de Rootstock-keten, biedt het wel wat voor andere activa die op de zijketen zijn uitgegeven. De federatie kan altijd de Bitcoin op de hoofdketen stelen als er genoeg samenspannen is, maar omdat mijnwerkers de zijketen daadwerkelijk ontginnen, kan het doorgaan en kunnen de andere activa worden verhandeld. Als die andere activa voldoende waarde hebben, zelfs zonder te worden ondersteund door echte bitcoin, zou het Rootstock BTC-token nog steeds voldoende marktvraag moeten hebben om vergoedingen te betalen om andere activa te gebruiken om mijnwerkers te stimuleren om te blijven minen.

De betrokkenheid van mijnwerkers is echter niet absoluut. Zolang een meerderheid van de Bitcoin-mijnwerkers ook Rootstock minen, hebben ze de volledige controle over het organiseren van transacties en het minen ervan in blokken, maar als dat percentage van de miners in het bereik van de helft (of iets lager) zakt, zijn er consensusregels die toestaan de federatie om checkpoints te ondertekenen die reorganisaties voor het checkpoint voorkomen. Als de hash-snelheid drastisch daalt, zijn ze zelfs in staat om het over te nemen als blocksigners, zoals de federatieleden van Liquid. Het is een zeer dynamisch systeem dat zowel zonder miners als zonder de federatie kan functioneren om de blockchain vooruit te helpen.

Het peg-in-proces is heel eenvoudig: stuur bitcoin naar het RSK-peg-in-adres en wacht vervolgens op voldoende bevestigingen. Nadat er voldoende bevestigingen zijn opgebouwd, herkent een Solidity smart-contract op de zijketen de transactie en wordt deze bijgeschreven op een rekening op de zijketen die wordt bestuurd door dezelfde sleutel waarop de UTXO waaraan u was gekoppeld, was vergrendeld. Pegging-out wordt ook beheerd door een slim contract, dat zal communiceren met de HSM's van de federatie, die een mainchain-terugtrekkingstransactie zullen ondertekenen wanneer dit door het contract wordt gevraagd.

Toen Roostock voor het eerst lanceerde, was alles wat nodig was om uit te pinnen een meerderheid van de HSM's van de federatie die de transactie ondertekenden nadat het slimme contract op de zijketen dit had opgedragen. In 2020 implementeerden ze een nieuw peg-mechanisme genaamd POWPeg. Met deze upgrade konden de HSM's SPV-bewijzen van mijnwerkers daadwerkelijk valideren. De HSM's weigeren nu om peg-out-transacties te ondertekenen, tenzij een meerderheid van de huidige groep RSK-mijnwerkers voortbouwt op de transactie vanaf de peg-out-initiatie. Het beveiligingsmodel komt er uiteindelijk op neer dat de HSM's veilig blijven, maar tenzij met een meerderheid van hen wordt geknoeid en de sleutels worden verwijderd, zullen ze niet ondertekenen zonder voldoende Proof-of-Work dat peg-outs bevestigt.

Sluiten

Mensen zijn al acht jaar bezig met het ontwerpen van zijketens, en terwijl we is gegaan tot en met vier verschillende ontwerpen (en er zijn er nog een paar: dit zijn alleen degenen die grip hebben gekregen op technische Bitcoiners), er is momenteel niets geïmplementeerd behalve federatieve ketens. Gefedereerde systemen zijn misschien niet de betrouwbare zijketen die veel mensen willen, maar het zijn nog steeds zeer nuttige systemen - vooral in elke context waar de enige manier om aan een marktvraag te voldoen, is om een ​​enkele bewaarder te vertrouwen om iets te arbitreren. Federaties worden onmiddellijk een standaardverbetering door het tegenpartijrisico over meerdere spelers te spreiden.

Nou, dat is in een notendop gefedereerde zijketens. Het laatste stuk dat hierna komt, gaat in op alle nadelen en minpunten van de belangrijkste huidige voorstellen, op zijn minst een paar gedachten op hoog niveau over wat mensen echt willen van een "perfecte" zijketen en hoe ze dat mogelijk kunnen bereiken.

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.