By Bitcoin Magazin - vor 4 Monaten - Lesezeit: 5 Minuten
Quecksilberschicht: Eine massive Verbesserung bei Statechains
CommerceBlock wird veröffentlicht Quecksilberschicht heute eine verbesserte Version ihrer Variante einer Statechain. Sie können eine ausführlichere Erklärung zur Funktionsweise ihrer Merkur-Zustandsketten lesen hier. Das Upgrade auf Mercury Layer stellt eine enorme Verbesserung gegenüber der ersten Statechain-Implementierung dar, ist jedoch im Gegensatz zur ersten Mercury Wallet-Version nicht als vollständig verbraucherbereite Wallet verpackt. Es wird als Bibliothek und CLI-Tool veröffentlicht, das andere Wallets integrieren können. Hier ist eine kurze Zusammenfassung ihrer Funktionsweise:
Statechains sind in vielerlei Hinsicht im Wesentlichen analog zu Zahlungskanälen, d. h. sie sind ein gemeinsam genutztes UTXO mit einer vorab unterzeichneten Transaktion als letzter Ausweg für Menschen, um ihr Eigentum durchzusetzen. Der Hauptunterschied zwischen einem Lightning-Kanal und einer Statechain besteht darin, welche Parteien an der gemeinsamen Nutzung des UTXO beteiligt sind und wie das Eigentum an einem durchsetzbaren Anspruch dagegen auf andere Parteien übertragen wird.
Im Gegensatz zu einem Lightning-Kanal, der zwischen zwei statischen Teilnehmern erstellt und gemeinsam genutzt wird, wird eine Statechain mit einem Moderator/Operator geöffnet und kann in ihrer Gesamtheit frei zwischen zwei beliebigen Teilnehmern übertragen werden, die bereit sind, dem Operator zu vertrauen, dass er ehrlich und völlig unabhängig ist -Kette. Jemand, der eine Statechain laden möchte, arbeitet mit dem Betreiber zusammen, um einen einzigen öffentlichen Schlüssel zu erstellen, von dem sowohl der Ersteller als auch der Betreiber einen Anteil am entsprechenden privaten Schlüssel besitzen, ohne dass einer von beiden über eine vollständige Kopie des Schlüssels verfügt. Von hier aus unterzeichnen sie vorab eine Transaktion, die es dem Ersteller ermöglicht, seine Münzen nach einer Zeitsperre einseitig zurückzufordern.
Um eine Statechain zu übertragen, arbeitet der aktuelle Eigentümer mit dem Empfänger und dem Betreiber zusammen, um mit seinem Schlüsselanteil einen kryptografischen Beweis dafür zu signieren, dass er die Münze überträgt, und dann generieren der Empfänger und der Betreiber ein neues Paar von Schlüsselanteilen, die zusammen denselben privaten Schlüssel und dasselbe Zeichen ergeben eine zeitlich begrenzte Transaktion für den neuen Eigentümer mit einer kürzeren Zeitsperre als die des Originals (um sicherzustellen, dass er seine Transaktion früher nutzen kann als frühere Eigentümer). Dieser Vorgang wird für jede Übertragung wiederholt, bis die Zeitsperre nicht mehr verkürzt werden kann. Zu diesem Zeitpunkt muss die Statechain in der Kette geschlossen werden.
Eigentümer übertragen bei jeder Übertragung die gesamte historische Kette vergangener Zustände, sodass Benutzer überprüfen können, ob Zeitsperren ordnungsgemäß dekrementiert wurden, und der Betreiber sie mit Zeitstempeln versehen kann Hauptstütze, eine Variante von Opentimestamps, bei der jedes Datenelement seinen eigenen eindeutigen „Slot“ im Merkle-Baum hat, um sicherzustellen, dass nur eine einzige Version der Daten mit einem Zeitstempel versehen wird. Dadurch kann jeder den Übertragungsverlauf einer Statechain prüfen.
Im Land der Blinden
Die große Änderung, die Mercury Layer an der ursprünglichen Version von Statechains vornimmt, ist verblüffend. Der Betreiber des Statechain-Dienstes wird nichts mehr darüber erfahren können, was übertragen wird: also die beteiligten TXIDs, die beteiligten öffentlichen Schlüssel, sogar die Signaturen, die er gemeinsam mit den Nutzern für die vorsignierten Transaktionen erstellt, die für die Rückforderung notwendig sind Ihr Geld einseitig.
Durch die Einführung einer Blindvariante von Schnorr MuSig2 kann Mercury den Prozess der Backout-Transaktionssignierung erleichtern, ohne die Details dessen zu erfahren, was sie signieren. Dies erfordert einige Designänderungen, um der Tatsache Rechnung zu tragen, dass der Betreiber nicht mehr den gesamten Übertragungsverlauf einer Statechain sehen und veröffentlichen kann. Sie sind nicht einmal in der Lage, die von ihnen unterzeichnete Transaktion überhaupt zu validieren.
In der vorherigen Iteration wurde die Einzigartigkeit eines aktuellen Statechain-Eigentümers/Transaktionssatzes vom Betreiber durch die Veröffentlichung des gesamten Übertragungsverlaufs der Statechain bei Mainstay bestätigt. Das ist hier nicht möglich, da der Betreiber in der Blindversion überhaupt keine Details über diese Transaktionen erfährt. Dies erfordert eine neue Art und Weise, wie der Betreiber den aktuellen Besitz der Statechain nachweist. Alle diese Daten werden vollständig an ein clientseitiges Validierungsmodell weitergeleitet. Der Operator verfolgt einfach, wie oft er etwas für eine einzelne Statechain signiert hat, und teilt einem Benutzer diese Nummer mit, wenn er dazu aufgefordert wird. Der Benutzer empfängt dann die Transaktionen früherer Statechain-Zustände von dem Benutzer, der sie an ihn sendet, und überprüft vollständig clientseitig, ob die Anzahl der Transaktionen mit den Angaben des Betreibers übereinstimmt. Anschließend überprüft er vollständig, ob alle Signaturen gültig sind und die Zeitsperren um den entsprechenden Betrag verringert wurden jedes Mal. Anstatt die vollständigen Statechain-Transaktionen und die Übertragungsreihenfolge an Mainstay zu veröffentlichen, veröffentlicht Mainstay seinen Anteil am öffentlichen Schlüssel (nicht den vollständigen aggregierten öffentlichen Schlüssel) für den aktuellen Benutzer für jede Statechain, da es so konzipiert ist, dass es nicht über alle diese Informationen informiert ist Benutzer. Dadurch kann jeder Benutzer, der eine Statechain empfängt, den Übertragungsverlauf und den aktuellen Status anhand der vom Absender gesendeten Transaktionsdaten auf Legitimität überprüfen.
Der Betreiberserver verfolgt eindeutige Statechains, um frühere Signaturen zu zählen, indem er jeder Statechain bei der Erstellung eine zufällige Kennung zuweist, die zusammen mit ihrem Nennwert und ihren privaten Schlüssel- und öffentlichen Schlüsselanteilen (nicht dem gesamten aggregierten öffentlichen Schlüssel) gespeichert wird. Das neue Koordinationsschema für das Sharding und Re-Sharding des Schlüssels erfolgt auf eine Weise, bei der der Server seinen Anteil am Schlüssel an den Benutzer weitergibt und die für ein Resharding erforderlichen Daten geblendet werden, sodass der Server nie in der Lage ist, den vollständigen Schlüssel des Benutzers zu erfahren Teilen des öffentlichen Schlüssels, wodurch der vollständige aggregierte öffentliche Schlüssel erstellt und die Münze in der Kette identifiziert werden kann.
Das Design ermöglicht es dem Betreiber nicht einmal zu wissen, wann er einen kooperativen Abschluss mit dem aktuellen Eigentümer unterzeichnet hat, und nicht eine vorab unterzeichnete Transaktion für einen neuen Off-Chain-Eigentümer; Es werden keine Details angezeigt, um die beiden Fälle voneinander zu unterscheiden. Dies ist jedoch sicher für Benutzer, die von jemandem angegriffen werden könnten, der versucht, eine Statechain außerhalb der Kette „doppelt auszugeben“ und eine gefälschte Transaktion vornimmt, die nicht abgewickelt werden konnte. Erstens würde dieser Benutzer in der Kette sehen, dass das UTXO, das diese Statechain unterstützt, ausgegeben wurde. Zweitens würde die Transaktionshistorie, da der Betreiber alle Zustandsaktualisierungen unterzeichnen muss, nur einen eindeutigen kooperativen Abschluss in der Kette vergangener Transaktionen ermöglichen. Beides würde es dem Benutzer ermöglichen, die Transaktion abzulehnen, obwohl er weiß, dass sie nicht legitim ist.
Statechains also allow Lightning channels to be “put on top” of the statechain by having the statechain pay out to a multisig address between two people, and the two of them negotiating a conventional set of Lightning commitment transactions on top of it. It would need to close the statechain on-chain before closing the Lightning channel so would need to use longer timelock lengths for Lightning payments, but otherwise would function perfectly normally.
Overall with the massive privacy improvements of the new iteration of statechains, and the composability with Lightning, this opens many doors for the economic viability and flexibility of second layer transactional mechanisms on Bitcoin. Especially in light of the recent radical changes in mempool dynamics and the resulting fee pressure.
Es bietet die gleichen Liquiditätsvorteile wie Ark, d. h. es ist frei übertragbar, ohne dass Liquidität benötigt wird, ist aber im Gegensatz zu Ark heute live und funktionsfähig. Es handelt sich zweifellos um ein anderes Vertrauensmodell als etwa Lightning allein, aber aufgrund der enormen Vorteile bei Flexibilität und Skalierbarkeit ist es definitiv eine Möglichkeit, die es zu erkunden gilt.
Originalquelle: Bitcoin Magazin