Jeremy Rubin hat vor zwei Wochen einen Vorschlag mit dem Titel Un'FE'd Covenants (FE = Functional Encryption) veröffentlicht. Angesichts der aktuellen Debatte über die Vertragsvorschläge von Bitcoin in den letzten zwei Jahren stellt Rubins Vorschlag eine praktischere Alternative dar. Der einzige bisher gemachte Vertragsvorschlag erfordert einen „Soft Fork“ (tatsächliche Opcodes), um eine unbewiesene Verschlüsselung (Functional Encryption) zu entwickeln und zu implementieren, sowie unverschämt hohe Nutzungskosten (ColliderScript).
Jeremys Vorschlag sieht keine Softforks vor. Es stellt auch keine schwere und unpraktische Belastung für die Benutzer dar. Im Gegenzug für diese Fähigkeit ist ein neues Sicherheitsmodell erforderlich. Bei Bitcoin sind nun Covenants möglich, indem BitVM-Anleihen verwendet werden, die gekürzt werden können.
Die Orakel
Orakel sind das erste Element dieses Schemas. Sie setzen die unterschiedlichen Vertragsanforderungen durch. Der erste Teil von Jeremys Plan basiert auf einem ziemlich einfachen Aufbau. Bei diesem System verwaltet das Orakel alle Gelder und ist für die Durchsetzung der Vertragsbedingungen verantwortlich. Orakel sollten in der Lage sein, die Bedingungen der Bündnisse für jede Münze, die sie besitzen, zu verfolgen. Es besteht ein Zustandsrisiko, bei dem die Oracle-Datenbank beschädigt werden und verloren gehen kann. Das Orakel wird nicht wissen, wie es ehrliche Gesetze für alle Münzen durchsetzen kann. Jeremy nutzt Taproot, um dieses Problem zu lösen.
Die Schlüssel, die auf dem Schnorr-System basieren, können auch „gezwickt“ werden. Das Hashing der Daten wird verwendet, um den öffentlichen Schlüssel zu ändern. Der optimierende private Schlüssel kann dann den neuen Schlüssel signieren und die für die Optimierung des öffentlichen Schlüssels verwendeten Daten nachweisen. Das Orakel kann den Schlüssel generieren und der Benutzer wird ihn mit dem Covenant-Programm optimieren. Dies ermöglicht es dem Benutzer, sich auf die Informationen festzulegen, die das Orakel erzwingen soll, während er sich dennoch der Last entledigt, diese Daten auf ihm zu speichern.
Es ist möglich, Orakel zusammenzuschließen, um das Vertrauen in eine einzelne Entität zu verringern, das zur Durchsetzung bestimmter Dinge erforderlich ist. Benutzer können dann diese Adresse laden und, wann immer sie die Bedingung der Vereinbarung durchsetzen möchten, die Oracles mit der ausgegebenen Transaktion, der Oracle-Software und den Zeugendaten kontaktieren. Das Orakel wird die Transaktion unterzeichnen, wenn sie den Regeln des Bundes entspricht.
Benutzer können Transaktionen zur Durchsetzung von Vereinbarungen für einfache Vereinbarungen vorab unterzeichnen, deren Ergebnisse bereits bekannt sind, wie z. B. CHECKTEMPLATEVERIFY.
Zustandsbasierte Vereinbarungen (z. B. Rollups), die regelmäßig aktualisiert werden und den aktuellen Gleichgewichtszustand für die Benutzer aufrechterhalten, sind ein erwägenswertes Szenario. Bei der Unterzeichnung solcher Vereinbarungen muss das Orakel OP_RETURN verwenden, um sich auf seinen aktuellen Zustand festzulegen. Das Orakel kann dann die Transaktion verifizieren, ohne Zeugendaten herunterladen zu müssen. Dies geschieht, um zu verhindern, dass das Oracle den Status lokal speichert, was riskant sein kann.
Oracle-Daten können durch den Einsatz von Zero-Knowledge-Proofs minimiert werden. Das Orakel muss nur den Beweis einer Transaktion prüfen, die den Regeln des Bundes entspricht, und nicht die Rohdaten von Zeugen für kompliziertere Verträge. Bei der Gestaltung von Systemen wie Rollups ist darauf zu achten, dass alle zum Verlassen des Systems notwendigen Daten den Benutzern zugänglich gemacht werden können.
BitVM-Anleihe
Das Vorhaben war bisher ein voller Erfolg. Im Wesentlichen geben Sie Ihr Geld jemand anderem und vertrauen darauf, dass dieser die Bedingungen willkürlich auferlegter Vereinbarungen durchsetzt. Dies kann erreicht werden, indem das obige Schema leicht modifiziert wird und anstelle von reinem Vertrauen ein kryptoökonomischer Anreiz verwendet wird.
In der obigen Beschreibung haben wir beschrieben, wie OP_RETURN verwendet werden kann, um zustandsbehaftete Vereinbarungen zu verfolgen. Mit OP_RETURN können Sie außerdem Zeugendaten verwenden, um zu überprüfen, ob die Vertragsbedingungen erfüllt wurden.
Mit BitVM kann überprüft werden, ob eine von einem Orakel signierte Transaktion mit den von ihm durchgesetzten Bedingungen übereinstimmt. Es ist wichtig zu bedenken, dass der generierte Schlüssel und alle gesendeten Gelder an alle möglicherweise durchsetzbaren Bedingungen gebunden sind. Daten sowie eine von der Adresse aus getätigte Zahlung können ebenfalls in BitVM eingegeben werden.
Oracles müssen möglicherweise eine Garantie bei BitVM stellen (der Betreiber muss eine zusätzliche Bürgschaft hinterlegen, um das Oracle abzusichern, falls sie zu Unrecht beschuldigt werden). Das System ist sicher, solange der Anleihebetrag den Vertragswert übersteigt. Orakel können nicht gegen Vertragsbedingungen verstoßen, ohne ihr Gesamtgeld zu verlieren.
Umtausch
Die Kompromisse sind hier weitaus schlimmer als die einfache Übernahme von Vereinbarungen in Konsensregeln. Durch Oracle erzwungene Vereinbarungen erfordern, dass das Oracle online verfügbar ist. Wenn das Orakel offline geht, können Benutzer keine Vereinbarungen durchsetzen, mit Ausnahme von Vereinbarungen, die vorab unterzeichnet wurden, wie z. B. CTV. Orakel müssen bei der Unterzeichnung anwesend sein.
Wenn das Oracle-System jemals weit verbreitet wird, könnte der Liquiditätsbedarf für diese Anleihen enorm werden. Das System ist im Vergleich zur nativen Implementierung bei Konsens über Covenant-Opcodes völlig ineffizient.
Die zusätzlichen Daten, die der Kette hinzugefügt werden müssen, damit das BitVM-Bond-Schema funktioniert, nutzen den Blockraum viel effizienter als die nativen Covenant-Implementierungen.
Der Vorschlag ist im Allgemeinen nicht so sicher und effizient wie native Vereinbarungen. Im schlimmsten Fall, wenn wir gezwungen sind, Bitcoin zu früh zu verknöchern, kann der Vorschlag eine praktikable Möglichkeit sein, Vereinbarungen zu integrieren, ohne sich auf unbewiesene Kryptografie zu verlassen oder Kosten zu verursachen, die sich Endbenutzer nicht leisten können.
Jeremy hat uns ein Worst-Case-Szenario vorgestellt, um die Auswahl an Designoptionen zu erweitern, die auf Bitcoin erstellt werden können.
„Dieser Artikel ist keine Finanzberatung.“
„Recherchieren Sie immer selbst, bevor Sie eine Investition tätigen.“
„Bitradar ist nicht verantwortlich für Aktivitäten, die Sie außerhalb von Bitradar durchführen.“
Quelle: bitcoinmagazine.com
