Für Bitcoin vorgeschlagene Gültigkeits-Rollups – Trustnodes

ZK-Tech-basierte Second-Layer-Lösungen könnten mit John Light vom ZK-Rollup-Forschungsstipendium der Human Rights Foundation zu Bitcoin kommen und einen Vorschlag unterbreiten, der die Aufmerksamkeit einiger Bitcoin-Entwickler auf sich gezogen hat.

In einem ausführlichen Überblick über Gültigkeits-Rollups und wie sie in Bitcoins sehr begrenzter Skriptsprache implementiert werden können, fasst Light zunächst hilfreich zusammen, was diese noch sehr neuen Erfindungen sind:

„Ein Rollup ist eine Blockchain, die den State Root und mindestens genügend Transaktionsdaten speichert, um den aktuellen Zustand von der Genese innerhalb des Blocks einer anderen ‚Eltern‘-Blockchain neu zu berechnen, während die Transaktionsausführung ‚offchain‘ auf ein separates Knotennetzwerk verlagert wird.“

Gültigkeits-Rollups enthalten genügend Daten in der Kette für „Gültigkeitsnachweise“, um sicherzustellen, dass neue Rollup-Blöcke den Regeln des Rollup-Protokolls folgen.

Diese Beweise werden durch ZK-tech erstellt, heutzutage hauptsächlich STARKs, und somit erhalten Sie praktisch eine Komprimierungsmethode, bei der Sie sagen wir 100x Transaktionen auf dieser zweiten Schicht abschließen können, mit der überwiegenden Mehrheit der Sicherheit der Basisschicht, und alles übersetzt sich in nur eine On-Chain-Transaktion.

Dies hat erhebliche Benutzerfreundlichkeitsvorteile gegenüber so etwas wie dem Lightning-Netzwerk, da Sie keine Dinge wie Sicherheiten, Router usw. benötigen, sondern nur auf das Rollup einzahlen.

Für einfache Übertragungen wurden sie größtenteils auf Ethereum implementiert, wo sie jetzt an einer ganzen zk-basierten virtuellen Ethereum-Maschine arbeiten, in der Hoffnung, dass die ZK-Lösung schließlich auf die Basisschicht selbst angewendet werden kann.

Bei Bitcoin wurde jedoch bis zu diesem Frühjahr nicht viel daran gearbeitet, als Trey Del Bonis, ein Bitcoin-Entwickler, veröffentlicht Codebeispiele, wie Gültigkeits-Rollups in Bitcoin implementiert werden können. Licht sagt:

„Es wäre möglich, mit Bitcoins nativer Turing-unvollständiger Programmiersprache Script ein Gültigkeits-Rollup für Bitcoin zu erstellen, mit relativ kleinen Änderungen (in Bezug auf den Code-Footprint) an den Opcodes, die Script unterstützt …

Laut Del Bonis sind die Änderungen, die zur Unterstützung von Gültigkeits-Rollups auf Bitcoin erforderlich sind, einige zusätzliche Opcodes, die die beiden Hauptprimitiven seines Rollup-Designs ermöglichen – Gültigkeitsnachweisverifizierung und rekursive Vereinbarungen…

Rekursive Covenants sind eine Art Smart Contract, der die Art des Skripts einschränkt, an das BTC gesendet werden kann, sobald es ausgegeben wurde.

Del Bonis verwendet rekursive Covenenants, um die Rollup-Konstruktion mit jeder Statusaktualisierung voranzutreiben und sicherzustellen, dass BTC, die in einem Rollup-Skript gesperrt sind und nicht von ihrem Eigentümer zurückgezogen wurden, von einer Rollup-Statusaktualisierung zur nächsten im Skript verbleiben.

Sobald der Besitzer von BTC auf dem Rollup eine gültige Auszahlungstransaktion auf dem Rollup bestätigt, kann er das rekursive Covenant-Skript mit seiner BTC an die von ihm angegebene L1-Auszahlungsadresse verlassen.

Rekursive Covenants sind eine Änderung an Script, die seit langem von der Bitcoin-Community in Betracht gezogen wird. Derzeit gibt es jedoch keine konkreten Vorschläge, die in der Bitcoin-Entwicklergemeinschaft einen breiten Konsens zur Implementierung rekursiver Vereinbarungen gefunden haben.“

Konzeptionell klingt das einfach. Rekursive Verträge befassen sich mit dem Sperrteil oder dem Transfer von Geldern in und aus dem Rollup, während einige andere Änderungen erforderlich sind, damit die Nachweise integriert werden können.

Bitcoin ändert sich jedoch notorisch langsam, aber Light sagt, dass der Vorschlag vollständig mit dem Ethos von Bitcoin kompatibel ist, und teilt der Mailingliste der Bitcoin-Entwickler mit:

„Gültigkeits-Rollups haben das Potenzial, die Skalierbarkeit, Privatsphäre und Programmierbarkeit von Bitcoin zu verbessern, ohne die Kernwerte oder Funktionalität von Bitcoin als elektronisches Peer-to-Peer-Cash-System zu opfern.

Angesichts der „vertrauenswürdigen“ Natur von Gültigkeits-Rollups als kryptografisch gesicherte Erweiterungen ihrer übergeordneten Kette und angesichts des Status von Bitcoin als sicherste Abwicklungsschicht könnte man sogar sagen, dass diese Protokolle „perfekt zusammenpassen“.

Sie benötigen keine zusätzliche Bandbreite oder Speicherplatz und bieten so Skalierbarkeit ohne nennenswerte Kompromisse.

Ihre Implementierung in Bitcoin wird jedoch wahrscheinlich sehr langsam sein, wobei Light stattdessen vorschlägt:

„Das Sidechain-Projekt Elements (und die auf Elements basierende Liquid-Blockchain) bietet noch keine Unterstützung für die Gültigkeitsnachweise, die zur Unterstützung eines Gültigkeits-Rollups erforderlich sind, aber es unterstützt rekursive Covenants.

Die Implementierung von Unterstützung für Gültigkeitsnachweise in Elements, zusammen mit einigen der anderen Änderungen, die Del Bonis als „nice to have“ identifiziert hat, könnte daher ein Weg sein, ein Gültigkeits-Rollup-Protokoll zu testen, das letztendlich auf Bitcoin eingesetzt werden soll.“

Liquid wird von Blockstream verwaltet, wobei Greg Sanders von diesem Blockstream in der Mailinglistendiskussion angibt:

„Gibt es einen einseitigen Spickzettel mit ‚Fragen‘ nach Transaktions-Introspektion/OP_ZKP(?) und deren Verwendung sowohl separat als auch zusammen für verschiedene Rollup-Architekturen?“

Das Op_ZKP existiert nicht ganz, weshalb er vielleicht das Fragezeichen gesetzt hat, aber die Frage könnte durchaus darauf hindeuten, dass es zwar konzeptionell einfach klingt, die tatsächliche Implementierung in der sehr begrenzten Bitcoin-Skriptsprache jedoch wahrscheinlich überhaupt nicht einfach sein wird.

Nicht zuletzt, weil es eine hochmoderne Entwicklung wäre, wenn auch nicht ganz originell, da Entwickler in Ethereum seit 2019 an diesen zk-Systemen arbeiten.

Der Transport hat nun den Punkt erreicht, an dem das Skelett für Bitcoin ausgelegt wurde. Die vollständige Implementierung kann jedoch noch einige Zeit dauern.