On-Chain-Wallets erreichen eine ungefähre 1:1-Zuordnung von Transaktionen zu Transaktionen: Für jede wirtschaftliche Transaktion, die ein Benutzer durchführt, wird ungefähr eine Blockchain-Transaktion benötigt. Aggregationen, Coinjoin, Cut-Through-Payments usw. ändern diese Aussage ein wenig. Aber es ist ungefähr richtig.

Lightning hat eine viele-zu-eine Zuordnung von Transaktionen zu Transaktionen erreicht: Das Besondere an Lightning ist, dass in einem einzigen Lightning-Kanal effektiv eine unendliche Anzahl wirtschaftlicher Transaktionen stattfinden kann, der selbst mit einem einzigen ungenutzten Transaktionsausgang (UTXO) verbunden ist. Im Wesentlichen haben wir die 'Zeit'-Dimension - Transaktionen - genommen und eine bedeutende Skalierung erreicht, indem wir diese Dimension zusammengebrochen haben.

Aber selbst die Erstellung eines einzigen UTXO pro Benutzer ist möglicherweise nicht ausreichend. Es gibt also viele Vorschläge, um noch größere Skalierung zu erreichen, indem mehrere Benutzer ein einziges UTXO auf eine selbstbestimmte Weise teilen können. Erneut wird eine weitere „Raum“-Dimension der Skalierung - Benutzer - in ein UTXO zusammengefasst.

Unser Ziel hier ist es, eine Übersicht über all diese Vorschläge zu geben, herauszufinden, welche technischen Muster sie teilen, herauszufinden, welche Arten von neuen Opcodes und anderen Softfork-Upgrades sie benötigen, um zu funktionieren, und eine Vergleichstabelle zu erstellen, wie alle Teile zusammenpassen. Auf dem Weg werden wir auch definieren, was ein Layer 2-Protokoll tatsächlich ist, wozu für die Skalierung Lightning bereits in der Lage ist, und ein Verständnis dafür zu bekommen, welche Verbesserungen wir an Mempools vornehmen müssen, um all dies zu erreichen.

Dank geht an Fulgur Venturesfür die Unterstützung dieser Forschung. Sie hatten keine redaktionelle Kontrolle über den Inhalt dieses Beitrags und haben ihn vor der Veröffentlichung nicht überprüft.

Danke geht auch anDaniela Brozzoni, Sarah Cox, und andere zur Vorabüberprüfung.

Definitionen

Was ist Layer 2?

Oft wird der Begriff "Layer 2" weit definiert, bis zu dem Punkt, an dem sogar eine bankähnliche Einrichtung (z.B. Liquid) als Layer 2 definiert werden könnte. Für die Zwecke dieses Artikels werden wir eine strenge Definition übernehmen: Ein Layer 2 (L2) ist ein auf Bitcoin denominiertes System, das dazu dient, BTC häufiger als die Anzahl der On-Chain-Transaktionen mit anderen Parteien zu übertragen. So dass entweder:

1. Niemand ist in der Lage, profitabel Gelder im System zu stehlen, unter Berücksichtigung von internen Bestrafungen und Kosten. Externe Kosten und Bestrafungen wie Reputationsschaden, rechtliche Konsequenzen usw. werden in unserer Definition nicht berücksichtigt.
2. (Bevorzugt) Die wahren Eigentümer der Mittel können einseitig ihre Mittel abheben, abzüglich der Transaktionsgebühren, ohne die Zusammenarbeit mit Dritten.

Die erste Option ist erforderlich, da wir möchten, dass unsere L2-Systeme Beträge und Transaktionen darstellen können, die so gering sind, dass sie nicht on-chain dargestellt werden können. Zum Beispiel können HTLCs in Lightning einen Wert haben, der zu gering ist, um on-chain dargestellt zu werden. In diesem Fall wird der HTLC-Wert zur Transaktionsgebühr der Verpflichtungstransaktion hinzugefügt. Während ein Lightning-Knoten einen Staub-HTLC durch Schließen eines Kanals zum richtigen Zeitpunkt "stehlen" kann, ist dies teurer.¹wodurch der Diebstahl unrentabel wird, da der HTLC weniger wert ist.

Das einseitige Zurückziehen ist jedoch immer unser primäres Designziel.²

Nach dieser Definition gelten Dinge wie Lightning als L2-Systeme. Systeme wie Liquid, Cashu und Fedimint sind jedoch keine L2-Systeme, weil eine andere Partei oder andere Parteien die Kontrolle über Ihre Gelder haben. Validierungsschemata auf der Client-Seite wie RGB sind ebenfalls keine L2-Systeme nach dieser Definition, da sie nicht in der Lage sind, BTC selbst vertrauenswürdig zu übertragen. @RubenSomsenStatechains schafft es nicht, weil die Statechain-Entität Gelder stehlen kann, wenn sie das Protokoll nicht befolgen.

Was sind Verbündete?

...und warum brauchen skalierbarere L2-Systeme sie?

In Bitcoin-Skripting sind Klauseln Mechanismen, durch die die Art und Weise, wie ein txout ausgegeben werden kann, im Voraus eingeschränkt ist, sodass die Form von Transaktionen, die zum Ausgeben dieses txout verwendet werden, vordefiniert oder anderweitig eingeschränkt ist, und zwar nicht rein auf Signaturen beschränkt. L2-Systeme, die UTXOs zwischen mehreren Parteien gemeinsam nutzen, benötigen Klauseln, weil sie Möglichkeiten benötigen, wie die UTXO ausgegeben werden kann, um die Regeln und Anreize des L2-Protokolls umzusetzen.

Rekursive Bündnisse

Ein rekursiver Pakt ist ein Pakt, bei dem die Regeln, die festlegen, wie ein UTXO ausgegeben werden kann, rekursiv auf untergeordnete UTXOs der Ausgabetransaktion angewendet werden können, und das unbegrenzt. Rekursive Pakte haben wurde von einigen schon lange als unerwünscht angesehenweil sie Münzen unbefristet belasten können. Oder zumindest unbefristet ohne die Erlaubnis einer dritten Partei wie einer Regierung.

Ziele

Lightning ist das derzeit beste Layer 2-System. Es hat jedoch Einschränkungen. Nämlich:

1. Skalierung - Lightning erfordert derzeit mindestens eine UTXO pro Endbenutzer.³
2. Liquidität - Lightning erfordert, dass Gelder in Kanälen gebunden sind.
3. Interaktivität - Lightning erfordert, dass die Empfänger von Zahlungen online sein müssen, um sie vertrauenswürdig zu empfangen.

Bei der Bewertung von Layer 2-Systemen wird unser Ziel sein, diese Hauptbeschränkungen idealerweise zu verbessern, ohne neue Beschränkungen hinzuzufügen.

Skalierungsgrenzen von Lightning

Was bedeutet "ein UTXO pro Endbenutzer" in der Praxis? Da Lightning-Kanäle unbegrenzt funktionieren können, kann man sich diesbezüglich fragen, wie viele neue Kanäle pro Jahr erstellt werden können.⁴. Das Erstellen einer Taproot-Ausgabe hat eine marginale Kosten von 43vB; Wenn die Kanalerstellung amortisiert wird und viele Kanäle in einer einzigen Transaktion erstellt werden, können die anderen Transaktionskosten vernachlässigbar gemacht werden und es können recht viele Kanäle pro Jahr geöffnet werden, um neue Benutzer einzubinden. Angenommen, dass beispielsweise 90% der Blockkapazität für das Öffnen neuer Taproot Lightning-Kanäle verwendet wurden:

Es wird geschätzt, dass Etwa die Hälfte der weltweiten Bevölkerung besitzt ein Smartphone, 4,3 Milliarden Menschen. Wir können tatsächlich einen bedeutenden Prozentsatz der gesamten Bevölkerung an Bord holen, der voraussichtlich in der Lage sein wird, pro Jahr einen Lightning-Kanal zu nutzen.

Allerdings halten Kanäle nicht ewig. Gelegentlich möchten Benutzer zu anderen Geldbörsen wechseln, die Kanalkapazität erhöhen oder verringern usw. Die effizienteste Methode, die Kapazität eines Kanals zu ändern, erfolgt über Verbindung, insbesondere umgesetzt in Phoenix Wallet.

Wie bei der Kanaleröffnung kann auch das Splicing amortisiert werden, um die Effizienz zu verbessern. Mehrere Splice-Operationen können eine einzige Transaktion gemeinsam nutzen, um die Anzahl der Ein- und Ausgänge, die zum Hinzufügen und Entfernen von Mitteln erforderlich sind, zu reduzieren.⁵. Daher der Delta-Blockplatz, der für den Zuschnitt der Benutzer erforderlich ist, unter der Annahme der Verwendung von musig, ist die 43vB Taproot-Ausgabe plus das

57,5 vB Taproot-Keypath-Ausgaben für insgesamt 100,5 vB. Wenn wir wieder von einer Blockspace-Nutzung von 90% ausgehen, erhalten wir:

Schließlich beachten Sie, wie das Umschalten von Lightning-Kanälen zwischen Brieftaschen in einer einzigen Transaktion erfolgen kann, indem entweder der nächsten Brieftasche vertraut wird, um eine Verpflichtungstransaktion nach dem Senden der Mittel an die Verpflichtungsadresse zu unterzeichnen, oder mit kooperativer Schließung-zu-Neuer-Kanal-Unterstützung in beiden Brieftaschenimplementierungen.

Natürlich gibt es Wettbewerbsfälle für Bitcoin jenseits von Lightning-Kanälen, und wie sich das in Gebührenraten übersetzen wird, ist schwer zu sagen. Aber diese Zahlen geben uns eine grobe Schätzung, die darauf hindeutet, dass es zumindest technisch möglich ist, mit der aktuellen Technologie Hunderte von Millionen selbstbestimmten Lightning-Benutzern zu unterstützen.

Layer 2 Übersicht

Unter unserer Definition von L2-Systemen werden in der Bitcoin-Entwicklungsgemeinschaft zwei Hauptdesignmuster diskutiert:

1. Kanäle
2. Virtuelle UTXOs

Im Kanalmuster, von dem Lightning das Hauptbeispiel ist, schreitet das Protokoll fort, indem vorab signierte Transaktionen zwischen den Parteien ausgetauscht werden, die abgebaut werden könnten, aber nicht im „glücklichen Pfad“ liegen. Diese vorab signierten Transaktionen teilen einen UTXO zwischen den Parteien auf; Transaktionen geschehen durch wiederholtes Ändern des Saldos dieser Aufteilung mit neuen vorab signierten Transaktionen. Da es viele verschiedene mögliche gültige Transaktionen gibt, die dasselbe UTXO ausgeben, ist ein Anreizmechanismus erforderlich, um sicherzustellen, dass die korrekte Transaktion tatsächlich abgebaut wird.

Im Designmuster Virtual UTXO (V-UTXO), von dem Ark das prominenteste Beispiel ist, werden V-UTXOs über Verträge oder Mehrparteienvereinbarungen erstellt, indem Transaktionen erstellt werden, die abgebaut werden können, um die V-UTXO-Fonds einseitig abzuheben, indem sie auf die Blockchain gesetzt werden, jedoch nicht im „glücklichen Pfad“ sind. In dieser Hinsicht ähneln V-UTXOs Kanälen. Aber im Gegensatz zu Kanälen führen V-UTXO-Schemata Transaktionen durch, indem sie die V-UTXOs selbst ausgeben, in (konzeptionell) einer einzigen⁶Vorab signierte Transaktion.

Das Designmuster des „glücklichen Pfads“ besteht darin, einen Skript-Pfad zu verwenden, bei dem alle Parteien zustimmen, wie z.B. eine N-aus-N-Multisig. Taproot ist speziell für dieses Konzept entwickelt worden und ermöglicht, dass der Schlüsselpfad über eine Musig-N-aus-N-Multisig verläuft. Unter der Annahme, dass alle Parteien zustimmen, ermöglicht der glückliche Pfad, dass die Münzen effizient (und privat) ausgegeben werden können.

Interessanterweise, da virtuelle UTXOs in vielerlei Hinsicht 'echt' sind, ist es recht einfach, Kanäle auf virtuellen UTXOs aufzubauen, indem man einfach virtuelle UTXOs erstellt, die bei ihrer Förderung zur Erstellung der für die Kanäle erforderlichen UTXOs führen würden. In diesem Sinne sind virtuelle UTXO-Schemata eine

etwas niedriger als Kanäle.

Blitz

Der Status quo, der in der Produktion als das Lightning-Netzwerk implementiert ist, basiert hauptsächlich auf der Layer 2-Technologie.BOLT-Standards. Lightning ist eine Kombination verschiedener Elemente, einschließlich Lightning-Kanäle und HTLCs, das P2P-Routing-Netzwerk, Onion-Routing, Rechnungsstandards usw. Bemerkenswert ist, dass Lightning kein Konsenssystem ist, sodass verschiedene Elemente des 'Lightning-Systems' nicht von allen Benutzern auf die genau gleiche Weise übernommen werden müssen. In diesem Artikel verwenden wir den Begriff 'Lightning' im weiteren Sinne, einschließlich leicht vorhersehbarer Upgrades des aktuellen (typischen) Lightning-Protokolls, die weit verbreitet sind.

Wie oben diskutiert, ist das wichtigste Merkmal von Lightning seine Endbenutzer-Skalierbarkeitsgrenze, die darauf zurückzuführen ist, dass mindestens eine UTXO pro Benutzer vorhanden sein muss. Nichtsdestotrotz sind diese Skalierbarkeitsgrenzen für das „Kern“-Routing-Element von Lightning - die öffentlichen Lightning-Nodes, die den Großteil der Transaktionen routen - nicht besonders besorgniserregend, da Lightning problemlos funktioniert, wenn es weit mehr Endbenutzer als Routing-Nodes gibt, da jeder öffentliche Kanal, der für die Zahlungsrouting verwendet wird, problemlos eine große Anzahl von Transaktionen pro Sekunde unterstützen kann. Deshalb ist es auch so, dass viele zukünftige L2-Systeme erwarten, am Lightning-Netzwerk teilzunehmen. Dies zeigt sich auch darin, wie bestehende, noch nicht ganz L2-Systeme wie Cashu stark auf das Lightning-Netzwerk angewiesen sind, um tatsächlich nützlich zu sein: Die Hauptnutzung von Cashu besteht wahrscheinlich darin, Lightning-Zahlungen zu senden und zu empfangen.

Nicht-interaktive Kanäle

Diese Konstruktion verbessert Lightning-Kanäle durch die Verwendung von OP_CTV zur Reduzierung der Interaktivitätsanforderungen. Da sie jedoch die Skalierungsgrenze von 1-UTXO pro Benutzer nicht verbessert, werden wir nicht weiter darauf eingehen.

Kanalfabriken

Hier verhandeln mehrere Parteien eine einzelne n-von-n-Multisig-Adresse, zusammen mit einer Transaktion, die diese Multisig-Adresse ausgibt, um n verschiedene UTXOs zu erstellen, die die Fonds aufteilen. Diese UTXOs werden wiederum für Zahlungskanäle verwendet. Die Kanäle können mit derselben Sicherheit wie bei einer direkten On-Chain-Eröffnung genutzt werden, da im Falle, dass der Kanalzustand auf die Kette gebracht werden muss, die Split-Transaktion gemined werden kann. Dies spart potenziell On-Chain-Platz, wenn die Kanäle geschlossen werden, da die n Parteien – theoretisch – alle nn Kanäle kooperativ gleichzeitig schließen können.

Da Kanalfabriken UTXOs verhandeln, die abgebaut werden könnten, aber im Idealfall nicht tatsächlich abgebaut werden sollen, sind sie ein sehr primitives Beispiel für V-UTXOs.

Channel-Fabriken an sich erfordern keine Soft-Forks, um möglich zu sein. Die einfachen Channel-Fabriken, die oben beschrieben wurden, sind jedoch wahrscheinlich jenseits kleiner Gruppen aufgrund der Koordination erforderlich, um tatsächlich einen Skalierungsvorteil zu erzielen, praktisch nicht umsetzbar. Daher schlagen wir Vertragsvorschläge wie OP_Evictoder CTV (über txout-Bäume) sollen feinere Ergebnisse ermöglichen, bei denen einzelne Parteien erzwungen werden können, ohne alle gleichzeitig auf die Kette zu zwingen.

Eltoo/LN-Symmetry

Da Eltoo ein schrecklich verwirrender Name ist, werden wir ab sofort nur noch den aktualisierten Namen LN-Symmetry verwenden.

Während Poon-Dryja-Kanäle die Veröffentlichung des korrekten Zustands auf der Chain fördern, indem sie falsche Zustände bestrafen, ermöglicht LN-Symmetry stattdessen, dass falsche Zustände mit einer zusätzlichen Transaktion aktualisiert werden. Dies hat den Vorteil, dass Lightning-Kanäle vereinfacht werden, da die Komplexität von Strafen beseitigt wird. Dies dürfte jedoch in nicht vertrauenswürdigen Szenarien ein Nachteil sein, da Strafen wohl erforderlich sind, um Betrug zu verhindern.

LN-Symmetrie benötigt eine Aufspaltung, um aktiviert zu werden.SIGHASH_ANYPREVOUT, das erforderlich ist, um es staatlichen Transaktionen zu ermöglichen, während Aktualisierungen andere staatliche Transaktionen erneut auszugeben.

Für sich genommen bietet LN-Symmetrie keine Skalierungsverbesserungen bei herkömmlichen Lightning-Kanälen. Aber Befürworter haben argumentiertdass es die Implementierung von Kanalfabriken einfacher macht.

ARK

Ark verfolgt einen neuen Ansatz zur Skalierung von Transaktionen: vollständig übertragbare virtuelle UTXOs (V-UTXOs), die atomar zusammengeführt und aufgeteilt werden können⁷ Off-Chain-Transaktionen. In Ark stellt ein zentraler Koordinator, der Ark Service Provider (ASP), V-UTXOs für Benutzer mit einer definierten Lebensdauer, z.B. 4 Wochen, zur Verfügung. Diese Perioden werden als Runden bezeichnet. Diese V-UTXOs werden über Pool-Txouts erstellt, eine pro Runde, über eine Art Mechanismus wie CTV, der es einem einzelnen On-Chain-Txout ermöglicht, sich auf einen Baum von V-UTXOs festzulegen. Durch den Rundenablauf erzielt Ark einen Skalierungsvorteil: Am Ende einer Runde wird der Pool txout entsperrt, so dass der ASP ihn einseitig mit einer einzigen Signatur in einer kleinen Transaktion ausgeben kann. Aufgrund der Round-Ablaufzeit verfallen die V-UTXOs selbst, wenn die Pool-Txouts, die sie erstellen, ablaufen: Benutzer, die einen V-UTXO besitzen, müssen diesen V-UTXO entweder vor Erreichen der Ablaufzeit des Pool-Txouts ausgeben oder ihn auf die Chain legen (einseitiger Rückzug).

Um V-UTXOs zwischen Parteien zu verrechnen, unterzeichnet der Ark-Koordinator Transaktionen, die ein oder mehrere V-UTXOs ausgeben, sodass die Transaktionen nur gültig sind, wenn ein oder mehrere andere V-UTXOs in einer anderen Runde erstellt werden. In Kombination mit einigen sorgfältigen Zeitüberschreitungen - siehe die Ark-Dokumentation für alle Details - ist diese Abhängigkeit das, was das Ausgeben von V-UTXOs vertrauenswürdig macht: Die V-UTXOs können nicht auf der Blockchain beansprucht werden, es sei denn, es werden neue V-UTXOs in einer anderen Pool-Transaktion erstellt. Es gibt einige potenzielle Möglichkeiten, diese Abhängigkeit tatsächlich umzusetzen. Aber die genauen Details sind für den Zweck dieses Artikels nicht relevant.

Beachten Sie, dass dies bedeutet, dass eine bestimmte ASP viele verschiedene aktive Runden gleichzeitig haben wird. Neue Runden werden häufig erstellt, um die Übertragung von Geldern in bestehenden Runden zu ermöglichen. Die bestehenden Runden überlappen jedoch die neuen Runden, da sie in der Regel irgendwann nach den neuen Runden ablaufen und neue Pool-Txouts erstellt werden.

Ark Wirtschaft

Wenn ein V-UTXO ausgegeben wird, muss der ASP entsprechende BTC in einem neuen Pool-Txout bereitstellen, der eine neue Runde repräsentiert. Aber sie können den Wert des ausgegebenen V-UTXO erst wiedererlangen, wenn die Runde abgelaufen ist. Daher hat die Ökonomie von V-UTXO-Ausgaben einen Zeitwertkosten, aufgrund der Liquidität, die der ASP bereitstellen muss.

Insbesondere entstehen Kosten, wenn die V-UTXO ausgegeben wird. Solange die V-UTXO nicht ausgegeben wird, stellt sie eine sehr reale potenzielle UTXO dar, die auf die Kette gesetzt werden könnte, um die Mittel einseitig abzuziehen. Der Benutzer besitzt diese Mittel. Um jedoch die V-UTXO auszugeben, muss die ASP eine neue Pool-Txout erstellen, wobei sie Mittel verwendet, die sie anderswo erhält, während die Mittel in der ausgegebenen V-UTXO für die ASP erst nach Ablauf der Zeit verfügbar sind.

Daher erfordert die Ausgabe einer V-UTXO einen kurzfristigen Kredit, um Gelder zu leihen, um den Zeitraum zwischen jetzt und dem Ablauf der Runde zu decken. Das bedeutet, dass die Liquiditätskosten für das Ausgeben einer V-UTXO tatsächlich sinken, wenn die V-UTXO älter wird und die Ablaufzeit näher rückt und schließlich - in der Theorie - null erreicht, wenn die Runde schließlich abläuft.

Schließlich ist zu beachten, dass die Kosten für die Ausgabe eines V-UTXO mit der Gesamtgröße des ausgegebenen V-UTXO zusammenhängen. Nicht mit dem Betrag, der dem Empfänger gezahlt wird. Dies bedeutet, dass Wallets, die für die direkte Transaktion von V-UTXOs vorgesehen sind (im Gegensatz zur Verwaltung eines V-UTXO beispielsweise für einen V-UTXO-basierten Lighting-Kanal), Abwägungen bei der Aufteilung von Mitteln in V-UTXOs treffen müssen. Ein einzelner V-UTXO minimiert die Kosten für einseitige Abhebungen und maximiert gleichzeitig die Liquiditätsbasierten Transaktionsgebühren; die Aufteilung der Mittel in viele V-UTXOs bewirkt das Gegenteil. Dies unterscheidet sich vollständig von der Ökonomie von On-Chain-Bitcoin- oder Lightning-Transaktionen.

Was ist diese Liquiditätskosten? Zum Zeitpunkt des Verfassens erhebt die Lightning-Brieftasche Phoenix eine Gebühr von 1 %, um die Kanalliquidität für 1 Jahr zu reservieren; im schlimmsten Fall müsste Phoenix ihre Gelder für 1 Jahr binden. Dies setzt jedoch voraus, dass die Liquidität nicht genutzt wird. Es ist durchaus möglich, dass die Kapitalkosten für Phoenix tatsächlich höher sind und sie davon ausgehen, dass der durchschnittliche Kunde ihre eingehende Liquidität in weniger als einem Jahr nutzt. Phoenix verdient auch Geld mit Transaktionsgebühren und subventioniert möglicherweise die Kanalliquidität. Schließlich ist es möglich, dass Phoenix nicht profitabel ist!

Der US-Schatzwechselkurs liefert uns eine weitere Schätzung. Zum Zeitpunkt der Abfassung beträgt der Schatzwechselkurs für 3 Monate etwa 5% pro Jahr. Da argumentiert wird, dass dieser Satz aufgrund der Inflation des US-Dollars aufgebläht ist, nehmen wir für unsere Analyse an, dass die Kosten der Liquidität für BTC-denominierte Fonds 3% pro Jahr betragen.

Wenn das Rundenintervall 4 Wochen beträgt, bedeutet dies, dass eine Transaktion mit einer Liquiditätskosten von beginnen würde

, schließlich auf Null abfallend. Unter der Annahme, dass der Benutzer versucht, seine Gelder zwei Wochen vor Ablauf der Runde auf eine neue Runde zu übertragen, zahlt der Benutzer etwa 1,5% pro Jahr an Liquiditätskosten, um die Selbstverwahrung seiner Gelder zu erreichen. Andererseits, wenn der Benutzer bis zum letzten Moment wartet⁸, die Kosten könnten fast null betragen, jedoch besteht das Risiko, dass die Verfallzeit verpasst wird.

Benutzer könnten dies nicht als eine banale Kosten sehen. Und diese Kosten gehen davon aus, dass die Fixkosten jeder Runde durch die Amortisierung von Transaktionsgebühren und anderen Kosten über eine große Anzahl von Teilnehmern vernachlässigbar gemacht wurden.

Was ist, wenn fixe Kosten nicht so unbedeutend sind? Angenommen, der ASP hat 1000 Benutzer und Pool-TXOUTs werden im Durchschnitt einmal pro Stunde erstellt. Über einen Zeitraum von 4 Wochen sind das 672 On-Chain-Transaktionen. Das bedeutet, dass die Benutzer des ASP nur um ihre Gelder zu halten, fast genauso viele Transaktionen wie Benutzer bezahlen müssen! Es wäre wahrscheinlich günstiger für sie, alle ihre eigenen Lightning-Kanäle zu öffnen, obwohl der ASP von ihnen verlangt, eine ganze Stunde auf eine Bestätigung zu warten.

Ark bootstrappen

Ein neues ASP mit wenigen Benutzern steht vor einem Dilemma: Entweder finden ASP-Runden selten statt und Benutzer müssen lange auf die vorgeschlagene Runde warten, um genügend V-UTXOs zu sammeln, um eine nützliche Skalierung und Transaktionsgebührenreduzierung zu erreichen. Oder ASP-Pool-Transaktionen finden häufig statt, mit hohen Transaktionsgebühren, die jeder Benutzer bezahlen muss. Wie wir im vorherigen Abschnitt gezeigt haben, kann es viele Benutzer benötigen, um häufige Runden zu amortisieren, sowie deren zugrunde liegende Pool-Txouts.

Weil Runden ablaufen, ist dieses Problem ein fortlaufendes Problem, noch schlimmer als das, mit dem Lightning-Kanäle konfrontiert sind: zumindest kann ein Lightning-Kanal unbegrenzt nützlich bleiben, sodass ein Kanal jetzt geöffnet und über viele Monate schrittweise amortisiert werden kann. Zweitens gibt es aufgrund des Ablaufs der Runden weniger Flexibilität, wann die neuen txouts erstellt werden sollen, die diese Runden unterstützen: Wenn die Gebühren für eine Woche oder zwei hoch sind, haben Benutzer, deren Pool txouts ablaufen, keine andere Wahl, als diese hohen Gebühren (gemeinsam) zu zahlen, um die Verwahrung ihrer Mittel aufrechtzuerhalten. Bei Lightning-Kanälen gibt es deutlich mehr Flexibilität, wann tatsächlich ein Kanal geöffnet wird.

Während die Autoren von Ark sich zunächst ein sehr optimistisches Szenario vorstellten, in dem neue Runden alle paar Sekunden stattfinden, wird die anfängliche Bootstrapping wahrscheinlich mit Anwendungsfällen stattfinden müssen, die es sich leisten können, mehrere Stunden auf eine Ark-Transaktion zu warten, wenn die Transaktionsgebühren nicht subventioniert werden.

Interaktivität

Nicht-hinterlegtes Ark ist ein äußerst interaktives Protokoll: Da Ihre V-UTXOs ablaufen, haben Sie harte Fristen, um mit Ihrem ASP zu interagieren, oder sonst könnte der ASP wählen, Ihre Gelder zu nehmen. Diese Interaktivität kann auch nicht ausgelagert werden: Während Lightning hat watchtowersDamit Gegenparteien davon abgehalten werden, Sie abzuzocken - selbst wenn Ihr Kanal nicht online ist - müssen Ark Coin-Besitzer ihre eigenen privaten Schlüssel verwenden, um Gelder ohne Vertrauen aufzufrischen. Das Ähnlichste zu Watchtowers in Ark wäre, Transaktionen zu signieren, die einem Watchtower erlauben, Ihre Gelder einseitig auf der Blockchain bis zum Ablauf der Zeit abzuheben, was erhebliche Transaktionsgebühren verursacht.

Betrachten Sie, was mit einem V-UTXO passiert, wenn der Eigentümer offline geht: Nach Ablauf der Runde muss der ASP die Mittel wiederherstellen, um ihre Liquidität für weitere Runden zurückzugewinnen. Wenn ein V-UTXO-Eigentümer offline geht, entstehen erhebliche Transaktionskosten, wenn dieser V-UTXO on-chain gesetzt wird, da der ASP jetzt Mittel auf mehreren Ebenen des V-UTXO-Baums wiederherstellen muss. Der ASP kann die ungenutzten V-UTXOs in einer neuen Runde wiederherstellen. Aber dies ist aus der Perspektive der V-UTXO-Eigentümer nicht vertrauenswürdig, da sie diese V-UTXOs ohne Daten nicht ausgeben können.⁹vom ASP. Der ASP könnte auch einfach ungenutzte V-UTXOs als treuhänderisches Guthaben erfassen. Oder vielleicht sogar die Politik haben, die Gelder zu beschlagnahmen!

Persönlich vermute ich, dass angesichts der nicht unerheblichen Kosten für die Selbstverwahrung von Ark viele Benutzer stattdessen ASPs mit einer Richtlinie wählen werden, die Gelder in eine neue Runde überführt und einfach das Potenzial für Betrug am Ende jeder Runde akzeptiert. Dies ist günstiger als das proaktive Bewegen ihrer Mittel früh genug, um im Falle dessen Sicherheit zu garantieren, dass sie z.B. ihr Telefon nicht rechtzeitig einschalten, damit ihre Brieftasche die Mittel in eine neue Runde überführen kann.

Arche für Fortgeschrittene

Es könnte machbar sein, die Liquiditätsanforderungen von Ark durch fortschrittlichere Verpflichtungen zu verringern, wenn es typisch ist, dass die Liquidität zumindest teilweise durchgeführt wird. Angenommen, 50% des gesamten V-UTXO-Werts in einem Pool txout wurden ausgegeben. Wenn der ASP nur diesen Teil des Pool txout der Runde einlösen könnte, könnte er die Liquidität schneller wiederherstellen und die Gesamtkosten für Liquidität verringern. Obwohl noch keine konkreten Vorschläge dazu veröffentlicht wurden, scheint es sicherlich möglich zu sein mit ausreichend fortgeschrittenen™ Verpflichtungen. Wahrscheinlich durch eine Art Skript-Revival-Soft-Fork, der gleichzeitig viele nützliche Opcodes hinzufügt.

Ebenso könnte durch ausreichend fortgeschrittene™ Verpflichtungen die gesamte txout-Baumstruktur durch eine Art rollendes Auszahlungssystem ersetzt werden, das möglicherweise Platzersparnisse bietet. Wir werden dies in einem weiteren Abschnitt behandeln, da diese Technik möglicherweise auch für andere Schemata nützlich ist.

Das Problem der Verwahrung am Ende einer Runde ist ein weiterer Fall, in dem die Sufficiently Advanced™-Verträge das Problem lösen könnten: Ein Vertrag, insbesondere ein ZK-Beweis-Vertrag, könnte den ASP zwingen, alle ungenutzten V-UTXOs in der nächsten Runde neu zu erstellen und das Problem der Verwahrung am Ende einer Runde zu beseitigen. Es ist wahrscheinlich nicht möglich, dies vertrauenswürdig zu gestalten, da der Benutzer wahrscheinlich einige Daten vom ASP benötigt, um seine V-UTXOs in der neuen Runde ausgeben zu können. Es könnte jedoch verhindern, dass der ASP finanziell von Betrug gegen Offline-Benutzer profitiert.

Zahlung von On-Chain-Gebühren bei einseitigem Rückzug

Ähnlich wie Lightning bestimmen die Ökonomie der On-Chain-Gebührenzahlung und der tatsächliche Wert eines V-UTXO nach Gebühren, ob die Ark-Nutzung unsere Definition eines L2 durch einseitigen Rückzug erfüllt oder ob ein Betrug zugunsten des ASP fehlschlägt. Wir werden die Details dazu weiter erörtern, wenn wir das txout-Baummuster besprechen.

Gültigkeits-Rollups

Eine große Klasse von sidechain-ähnlichen Konstrukten, die im Allgemeinen vorgeschlagen werden, verschiedene Formen der Zero-Knowledge (ZK)-Beweistechnologie zu verwenden, um die Regeln der Kette durchzusetzen. Die ZK-Beweistechnologie ist der entscheidende Unterschied zwischen der Validitäts-Rollup-Technologie und anderen Formen von Sidechains: Wenn das ZK-Beweisschema funktioniert, kann die Gültigkeit der Transaktionen durch Mathematik garantiert werden, anstatt einem Dritten zu vertrauen. Der „Zero-Knowledge“-Aspekt eines ZK-Beweises ist in diesem Anwendungsfall tatsächlich keine Voraussetzung: Es ist völlig in Ordnung, wenn der Beweis Informationen darüber „preisgibt“, was er beweist. Es kommt nur zufällig vor, dass die meisten mathematischen Schemata für diese Art von Beweis Nullwissensbeweise sind.

Aus Sicht von Bitcoin erfordert ein Validitäts-Rollup-Schema einen Vertrag, da wir UTXOs für das Schema erstellen möchten, die nur ausgegeben werden können, wenn die Regeln des Schemas befolgt werden. Dies ist nicht unbedingt ein dezentraler Prozess. Viele Validitäts-Rollup-Schemata sind tatsächlich vollständig zentralisiert; der Rollup-Beweis beweist, dass der zentralisierte Transaktionssequenzer die Regeln für eine bestimmte Sequenz von Transaktionen befolgt hat.

Was den Pakt betrifft... Die Zero-Knowledge-Proof-Technologie ist immer noch ein sehr neues Feld, in dem immer noch häufig Fortschritte gemacht werden. Daher ist es höchst unwahrscheinlich, dass wir irgendwelche Opcodes hinzugefügt sehen werden, die direkt bestimmte ZK-Beweisschemata validieren. Stattdessen wird im Allgemeinen akzeptiert, dass spezifische Schemata stattdessen allgemeinere Opcodes, insbesondere OP_CAT, verwenden, um ZK-Beweise über Skripte zu validieren. Zum Beispiel StarkWareistKampagnenOP_CAT angenommen zu haben.

Gültigkeits-Rollups sind ein so großes Potenzialthema, mit so vielen Projekten mit geringem Gehalt und hoher Hype, dass wir es nicht weiter diskutieren werden, außer darauf hinzuweisen, welche Opcodes dieses Design-Konzept möglicherweise lebensfähig machen.

BitVM

Großzügig ausgedrückt ist BitVM eine Möglichkeit, einen Lightning-Kanal zwischen zwei Parteien zu erstellen, bei dem die Regeln des Lightning-Kanals durch einen Zero-Knowledge-Beweis durchgesetzt werden. Da es heute tatsächlich keine Klauseln benötigt, die auf Bitcoin implementiert werden müssen, und weil es nicht direkt verwendet werden kann, um ein L2-System zu erstellen, das über das Limit von 1-UTXO pro Benutzer hinaus skaliert, werden wir nicht weiter darauf eingehen.

Hierarchische Kanäle

Hierarchische Kanäle¹⁰Ziel ist es, die Kanalgrößenänderung schnell und günstig zu gestalten: „Hierarchische Kanäle bewirken für die Kanalkapazität das, was das LN für Bitcoin bewirkt“. Sie überschreiten jedoch immer noch nicht grundlegend das 1-UTXO-pro-Benutzer-Limit. Außerdem erfordern sie ohnehin keine Änderungen am Bitcoin-Protokoll. Daher werden wir sie nicht weiter erörtern. Deren Befürworter sollten sie einfach umsetzen! Sie benötigen nicht unsere Erlaubnis.

CoinPool

CoinPool ermöglicht es mehreren Benutzern, eine einzelne UTXO zu teilen, Geld zwischen verschiedenen Benutzern zu überweisen und einseitig abzuheben. Der CoinPool-Papier-Vorschlag erfordert drei neue Softfork-Funktionen, SIGHASH_ANYPREVOUT, ein SIGHASH_GROUP, das eine Signatur nur auf bestimmte UTXOs anwendet, und ein OP_MerkleSub zur Validierung der Entfernung bestimmter Zweige aus einem Merkle-Baum; Letzteres könnte auch mit OP_CAT erreicht werden.

Derzeit scheint die Entwicklung von CoinPool zum Stillstand gekommen zu sein, der letzte Commit auf der Spezifikationswebsite liegt zwei Jahre zurück.

Enigma-Netzwerk

Während ich gebeten wurde, das Engima Network abzudecken, scheint es eine mangelnde Dokumentation darüber zu geben, was der Vorschlag wirklich ist. Bitfinex's Blogbeitragmacht viele Behauptungen; die MIT Seite ist leer. Da der Blogbeitrag nicht wirklich klar macht, was genau passieren soll, werden wir nicht weiter darauf eingehen.

Mempool-Betrachtungen

Die aktuelle Mempool-Richtlinie in Bitcoin Core ist für L2-Systeme nicht ideal. Hier werden wir einige der wichtigsten Herausforderungen erörtern, denen sie gegenüberstehen, und potenzielle Verbesserungen.

Anheften von Transaktionen

Letztlich handelt es sich um einen wirtschaftlichen Angriff, bei dem es um eine Vielzahl von Situationen geht, in denen jemand absichtlich ( oder unbeabsichtigt) erschweren das Mining einer gewünschten Transaktion aufgrund der vorherigen Übertragung einer widersprüchlichen Transaktion, die nicht gemined wird. Dies ist ein wirtschaftlicher Exploit, denn in einer echten Transaktions-Pinning-Situation gibt es eine wünschenswerte Transaktion, von der die Miner profitieren würden, wenn sie sie abbauen würden. Die in Konflikt stehende Pinning-Transaktion wird, wenn überhaupt, nicht in angemessener Zeit abgebaut.

Das einfachste Beispiel für das Anheften ergibt sich aus der Tatsache, dass die Transaktionsersetzung ohne vollständige RBF deaktiviert werden kann. Auf diese Weise können wir eine Transaktion mit niedrigem Gebührensatz durchführen, bei der der Ersatz ausgeschaltet ist, der nicht geschürft, aber auch nicht ersetzt werden kann. Im Wesentlichen haben 100 % der Hash-Power dieses Problem behoben, indem sie Full-RBF aktiviert haben, und zum Zeitpunkt des Schreibens sollte Full-RBF in der nächsten Version von Bitcoin Core standardmäßig aktiviert sein (nach 11 Jahre Arbeit!).

Das lässt BIP-125 Regel Nr. 3 Pinning zurück, das einzige verbleibende Pinning-Problem, das für Multiparty L2-Protokolle relevant ist und in Bitcoin Core nicht behoben wurde. Zur Referenz besagt BIP-125 Regel Nr. 3 folgendes:

Um die höhere absolute Gebühr zu zahlen, ist eine Ersatztransaktion erforderlich (nicht

als die Summe der Gebühren, die von allen ersetzen Transaktionen gezahlt werden.

Diese Regel kann ausgenutzt werden, indem eine große, mit niedriger Gebühr versehene Sperrtransaktion gesendet wird, die die relevanten Outputs des Multiparty-Protokolls (alternativ eine Gruppe von Transaktionen) ausgibt. Da die Transaktion eine niedrige Gebühr hat, wird sie möglicherweise gar nicht oder nicht rechtzeitig abgebaut. Da sie jedoch eine hohe Gesamtgebühr hat, ist es unwirtschaftlich, sie durch eine andere Transaktion zu ersetzen.

Regel Nr. 3 Das Anheften kann recht einfach behoben werden überErsatz durch Gebührenrate, und diese Lösung funktioniert in allen Situationen. Leider ist unklar, ob RBFR in naher Zukunft von Core übernommen wird, da sie eine beträchtliche Menge an Aufwand in eine minderwertige Teillösung gesteckt haben, TRUC/V3 Transaktionen.

Gebührenzahlung: RBF, CPFP, SIGHASH_ANYONECANPAY, Anker und Sponsoring

Da die Gebührensätze unvorhersehbar sind, ist es schwierig, in Situationen, in denen Transaktionen vorsigniert sind, zuverlässig und wirtschaftlich zu bezahlen. Der Goldstandard für die Gebührenzahlung besteht darin, RBF zu verwenden, beginnend mit einer anfänglichen "Low-Ball"-Schätzung und dem Ersetzen der Transaktion durch Versionen mit höheren Gebühren, bis sie abgebaut wird. Zum Beispiel verwendet die OpenTimestamps-Kalendersoftware RBF seit Jahren auf diese Weise, und LND hat Unterstützung für Deadline Aware RBF in v0.18.

RBF ist der Goldstandard für Gebührenzahlungen, da es in fast allen Fällen die blockspace-effizienteste Methode ist.¹¹Situationen: Die Ersatztransaktion(en) benötigen im Vergleich zu dem, was erforderlich gewesen wäre, wenn die richtige Gebühr beim ersten Versuch erraten worden wäre, keine zusätzlichen Eingänge oder Ausgänge.

Effizienz ist wichtig, denn Ineffizienzen bei der Gebührenzahlung Out-of-Band-GebührenzahlungEine profitable Einnahmequelle für große Miner; kleinere, dezentralisierte Miner können aufgrund der Unpraktikabilität und Nutzlosigkeit der Zahlung an einen kleinen Miner, um eine Transaktion bestätigen zu lassen, keinen Gewinn aus außerhalb des Bandes liegenden Gebührenzahlungen erzielen. Die außerhalb des Bandes liegende Gebührenzahlung scheint auch AML/KYC-Probleme zu verursachen: Derzeit erfordern die meisten tatsächlich verfügbaren außerhalb des Bandes liegenden Gebührenzahlungssysteme eine Art AML/KYC-Verfahren zur Durchführung einer Gebührenzahlung, mit der bemerkenswerten Ausnahme der mempool.space-Beschleuniger, die zum Zeitpunkt des Schreibens (Aug 2024) Lightning ohne Konto akzeptiert.

Um RBF direkt in Situationen mit vorab signierten Transaktionen zu nutzen, müssen Sie vorab signierte Gebührenvarianten mit dem gesamten Bereich möglicher Gebühren erstellen. Dies ist in vielen Fällen durchaus machbar, da die Anzahl der erforderlichen Varianten normalerweise gering ist.¹²Bisher haben das Lightning-Protokoll - und andere vorgeschlagene Protokolle - stattdessen darauf verzichtet, zu nutzen.Kind-zahlt-für-Elternteil (CPFP), normalerweise über Ankeroutputs.

Die Idee hinter einem Ankeroutput besteht darin, einen oder mehrere Outputs zu einer Transaktion mit einem minimalen oder null Wert hinzuzufügen, mit der Absicht, Gebühren über CPFP zu zahlen, indem man diese(n) Output(s) in sekundären Transaktionen ausgibt. Dies ist natürlich sehr ineffizient, wenn es auf Protokolle wie LN angewendet wird, die kleine On-Chain-Transaktionen haben, fast Verdopplung der Gesamtgröße einer kurzlebigen Ankerausgabe mit LN-Obligobuchung. Es wäre weniger besorgniserregend, wenn angewandte Protokolle verwendet würden, die größere Transaktionen verwenden, wie z.B. alles, was OP_CAT verwendet, um Verpflichtungen umzusetzen.

Ein weniger offensichtliches Problem bei Anker-Outputs besteht darin, dass zusätzliche UTXOs aufbewahrt werden müssen, um Gebühren zu bezahlen. In einer typischen "Client"-Anwendung kann dies insgesamt eine erhebliche Belastung darstellen, da ohne Anker-Outputs oft überhaupt keine Notwendigkeit besteht, mehr als einen UTXO zu verwalten. Tatsächlich ist es wahrscheinlich, dass einige bestehende verbraucherorientierte Lightning-Wallets in hochpreisigen Umgebungen aufgrund der Unfähigkeit, Gebühren zu bezahlen, durch die Remote-Seite des Kanals anfällig für Diebstahl sind.

SIGHASH_ANYONECANPAY kann in einigen Fällen für die Gebührenzahlung verwendet werden, indem zusätzliche Eingaben zu signierten Transaktionen hinzugefügt werden können. SIGHASH_SINGLE können auch Ausgänge hinzugefügt werden. Lightning verwendet dies für HTLC-Transaktionen. Im Moment kann diese Praxis anfällig für das Anheften von Transaktionen sein, wenn sie nicht sorgfältig gehandhabt wird¹³, da ein Angreifer einer Transaktion eine große Anzahl von Ein- und/oder Ausgängen hinzufügen kann, um eine PIN mit hoher Gebühr bzw. niedriger Gebühr zu erstellen. RBFR behebt dieses Problem. Der in TRUC/V3-Transaktionen verwendete Ansatz kann dieses Problem nicht beheben. Diese Art der Gebührenzahlung ist nicht so effizient wie RBF. Aber es kann effizienter sein als Ankerausgaben.

Schließlich gab es eine Vielzahl von Soft-Fork-Vorschlägen, um eine hinzuzufügen.Honorar-Sponsoring System auf das Bitcoin-Protokoll umgestellt. Dies würde es Transaktionen ermöglichen, Abhängigkeiten von anderen Transaktionen zu deklarieren, so dass die Sponsortransaktion nur dann gemined werden könnte, wenn die gesponserte Transaktion ebenfalls gemined wurde (höchstwahrscheinlich im selben Block). Dies könnte viel effizienter sein als ein herkömmliches CPFP, da die Sponsortransaktion diese Abhängigkeit mit deutlich weniger vByte als der Größe einer Transaktionseingabe deklarieren könnte.

Ersatz-Radfahren

Der Replacement Cycling Angriff¹⁴nutzt den Austausch von Transaktionen, um versuchen, eine gewünschte L2-Transaktion lange genug zu ersetzen, um stattdessen eine unerwünschte abzubauen. Im Wesentlichen sind Ersatzzyklus-Angriffe für den Angreifer eine Alternative zu Transaktionssperrtechniken, da sie verhindern sollen, dass eine gewünschte, ehrliche Transaktion lange genug abgebaut wird, um stattdessen eine unerwünschte, unehrliche Transaktion abzubauen. Im Gegensatz zu Transaktionssperrangriffen kann ein Ersatzzyklus-Angriff nicht versehentlich auftreten.

Das kanonische Beispiel bezieht sich auf einen Hashed-Time-Locked-Contract (HTLC). Es ist zwar einfach, sich einen HTLC als einen Vertrag vorzustellen, mit dem eine Transaktion entweder durch die Enthüllung eines Vorbilds oder durch eine Zeitüberschreitung getätigt werden kann. In der Realität ermöglicht ein HTLC aufgrund von Bitcoin-Skripting-Beschränkungen, dass eine Transaktion immer über die Enthüllung eines Vorbilds und dann nach einer Zeitüberschreitung zusätzlich über den Zeitüberschreitungsmechanismus ausgegeben wird.

Die Ersatzzyklisierung nutzt dies aus, indem sie das Preimage nach dem Timeout verwendet, um die Transaktion zu ersetzen, die versucht, die HLTC-Ausgabe über den Timeout-Mechanismus einzulösen, ohne dass das Opfer das Preimage erfährt. Ein erfolgreicher Ersatzzyklusangriff führt dies lange genug durch, damit die HTLC eines anderen Kanals abläuft.

Eine große Herausforderung bei der gewinnbringenden Nutzung des Ersatzrads besteht darin, dass jede Ersatzrunde Geld kostet. Eine fristbewusste Lightning-Implementierung wird immer höhere Gebühren für den Versuch ausgeben, die abgelaufene HTLC-Ausgabe auszugeben, bevor die nächste HTLC-Ausgabe abläuft. Zweitens kann jeder den Angriff vereiteln, indem er einfach die ersetzte Transaktion erneut ausstrahlt¹⁵Sobald der Austauschzyklus abgeschlossen ist.

Ähnlich wie beim Transaction Pinning ist auch das Replacement Cycling ein wirtschaftlicher Angriff auf Miner. Am Ende jedes Ersatzzyklus gibt es eine Transaktion, die aus den Mempools entfernt wurde, aber vollständig gültig ist und gemint werden könnte, wenn die Miner sie noch in ihren Mempools hätten.

Feature Patterns und Soft Forks

Nachdem wir Ihnen nun einen Überblick über die Vielfalt der covenant-abhängigen L2-Systeme und die Mempool-Herausforderungen gegeben haben, werden wir versuchen, diese Informationen auf eine Reihe bemerkenswerter Soft-Fork-Funktionen (hauptsächlich neue Opcodes) und Designmuster zu reduzieren, die diese L2-Systeme gemeinsam haben. Bei Soft-Fork-Vorschlägen besprechen wir auch die vorschlagsspezifischen technischen Risiken und Herausforderungen bei der Bereitstellung der einzelnen Vorschläge.

OP_Expire

Wir werden das zuerst erledigen. OP_Expire wurde vorgeschlagen¹⁶ als eine einfache Möglichkeit, den Ersatz-Cycling-Angriff zu eliminieren, indem das Problem an der Quelle behoben wird: die Tatsache, dass HTLCs auf zwei verschiedene Arten gleichzeitig ausgegeben werden können. Im Zusammenhang mit L2-Systemen ist dies für alles relevant, was einen HTLC-ähnlichen Mechanismus verwendet, und möglicherweise für andere Anwendungsfälle. OP_Expire würde es ermöglichen, dass eine Transaktionsausgabe nach einem bestimmten Zeitpunkt nicht mehr ausgegeben werden kann, so dass die HTLC-Ausgabebedingungen eher ein echtes exklusives ODER als ein "Programmierer-ODER" sein könnten.

Eine tatsächliche OP_Expire-Aufspaltung würde höchstwahrscheinlich aus zwei Funktionen bestehen, ähnlich wie beim OP_CheckLockTimeVerify und OP_CheckSequenceVerifyOpcodes kommen in zwei Teilen:

1. Ein Feld für die Ablaufhöhe für Transaktionen, das höchstwahrscheinlich im Taproot-Anhang implementiert ist.
2. Ein OP_Expire-Opcode, der überprüft, ob die Verfallszeit auf mindestens die gewünschte Höhe eingestellt ist.

Obwohl OP_Expire selbst kaum als ein Bündnis qualifiziert, scheint es für viele von Bündnissen abhängige L2-Systeme nützlich zu sein. Es könnte jedoch nicht ausreichend nützlich sein, da der Ersatzzyklus auch durch altruistisches Weiterleiten gemindert werden kann.¹⁵

Eine sehr bemerkenswerte Herausforderung bei der Bereitstellung und Verwendung von OP_Expire sind Reorgs: Die technische Gemeinschaft von Bitcoin, beginnend mit Satoshi,¹⁷hat versucht sicherzustellen, dass das Bitcoin-Konsensprotokoll so konzipiert ist, dass nach einem tiefen Reorg zuvor abgebaute Transaktionen in neue Blöcke abgebaut werden können. Dieses Design-Prinzip versucht, das Albtraumszenario zu vermeiden, dass eine große Anzahl von bestätigten Coins dauerhaft ungültig wird - und dass Menschen, die sich auf diese Coins verlassen, Geld verlieren - wenn ein Konsensfehler zu einem großen Reorg führt.

Im Falle einer großen Aufspaltung könnten Transaktionen mit Ablaufdatum aufgrund ihrer erreichten Ablaufhöhe nicht mehr abbaubar werden. Der Vorschlag OP_Expire sieht vor, dieses Problem zu lösen, indem die Ausgänge von Transaktionen mit Ablaufdatum ähnlich wie Coinbase-Transaktionen behandelt werden und sie für ~100 Blöcke unverwendbar macht.

Ein wesentliches Hindernis für den Einsatz des Transaktionsablaufs besteht darin, einen Konsens darüber zu erzielen, ob dieser Kompromiss akzeptabel oder sogar notwendig ist. Die Arten von Transaktionen, bei denen OP_Expire nützlich wären, beinhalten bereits lange Zeitüberschreitungen, bei denen Benutzergelder eingefroren werden. Es ist nicht wünschenswert, diese Zeitüberschreitungen noch länger zu verlängern. Außerdem waren Double-Spends schon immer eine weitere Möglichkeit, Coins nach einer Reorganisation für ungültig zu erklären: Würde der Transaktionsablauf angesichts der verstärkten Verwendung von RBF und der vorgeschlagenen Verwendung von schlüssellosen Ankerausgaben einen signifikanten Unterschied machen?

SIGHASH_ANYPREVOUT

BIP-118-KARTON schlägt zwei neue Signatur-Hashing-Modi vor, die sich beide nicht auf den spezifischen UTXO festlegen, der ausgegeben wird. SIGHASH_ANYPREVOUT, der (im Wesentlichen) stattdessen einen Commit für scriptPubKey ausführt, und SIGHASH_ANYPREVOUTANYSCRIPT, der jedes Skript zulässt. Wie oben erwähnt, wurde dies ursprünglich für die Verwendung durch LN-Symmetry vorgeschlagen, um zu vermeiden, dass jeder einzelne vorherige Kanalzustand, auf den reagiert werden muss, separat signiert werden muss.

SIGHASH_ANYPREVOUT ist auch potenziell nützlich in Fällen, in denen wir vorunterschriebene RBF-Gebührenvarianten in Verbindung mit vorunterschriebenen Transaktionen verwenden möchten, da die Tatsache, dass die Signatur nicht mehr von einer spezifischen Transaktions-ID abhängt, eine Aufspaltung vermeidet.kombinatorische Explosion der GebührenratenvariantenAllerdings adressiert der aktuelle BIP-118 Vorschlag diesen Anwendungsfall nicht und könnte aufgrund der Tatsache, dass auch SIGHASH_ANYPREVOUT vorgeschlagen wird, um den Wert des UTXO zu bestätigen, damit unvereinbar sein.

Ein anfänglicher Einwand gegen SIGHASH_ANYPREVOUT war die Idee, dass Wallets sich in Schwierigkeiten bringen könnten, indem sie es auf unangemessene Weise verwenden. Das Problem ist, dass sobald eine einzelne SIGHASH_ANYPREVOUT-Signatur veröffentlicht wurde, sie verwendet werden kann, um jede txout mit dem angegebenen Skript auszugeben. Wenn also aus Versehen ein zweiter Ausgang mit demselben Skript erstellt wird, ermöglicht SIGHASH_ANYPREVOUT einen banalen Wiederholungsangriff, um diese Münzen zu stehlen. Da es jedoch so viele andere potenzielle Gefahren inherent in Wallets und L2-Implementierungen gibt, scheint dieses Bedenken in den Hintergrund gerückt zu sein.

Zurzeit scheint die allgemeine technische Community recht positiv gegenüber der Implementierung von BIP-118 eingestellt zu sein. Allerdings gibt es, wie oben in unserer Diskussion über LN-Symmetrie erörtert, eine Debatte darüber, ob ihr Hauptanwendungsfall — LN-Symmetrie — tatsächlich eine gute Idee ist.

OP_CheckTemplateVerify

Unser erster opcodespezifischer Vorschlag, OP_CheckTemplateVerify - oder "CTV", wie er im Allgemeinen genannt wird - zielt darauf ab, einen sehr spezifischen, eingeschränkten Covenant-Opcode zu erstellen, indem genau eine Sache durchgeführt wird: das Hashen der Ausgabetransaktion auf eine bestimmte Weise, die sich nicht auf die Eingabe-UTXOs bezieht, und Überprüfen des resultierenden Digests gegen das oberste Element des Stacks. Dadurch kann die Ausgabetransaktion im Voraus eingeschränkt werden, ohne dass echte rekursive Covenant-Beschränkungen möglich sind.

Warum sind rekursive Bündnisse in CTV nicht möglich? Weil Hash-Funktionen: Das CTV überprüft die Ausgabentransaktion anhand eines Vorlagen-Hashs, und es gibt keine Möglichkeit¹⁸die Erstellung einer Vorlage, die einen CTV mit einem Hash von sich selbst enthält.

Das gesagt, das ist nicht unbedingt eine wirkliche Einschränkung: Sie können problemlos eine Kette von CTV-Vorlagen-Hashes auf eine Tiefe von zig Millionen Transaktionen in nur wenigen Sekunden auf einem modernen Computer hashen. Mit relativer nSequence-Zeitschlüssel Und die begrenzte Blockgröße, die tatsächlich das Ende einer solchen Kette erreicht, könnte leicht Tausende von Jahren dauern.

Der aktuelle CTV-Vorschlag in BIP-119hat nur einen Hash-Modus, bekannt als DefaultCheckTemplateVerifyHash, der sich im Wesentlichen zu jedem Aspekt der Ausgabentransaktion im Template-Hash verpflichtet. Aus praktischer Sicht bedeutet dies, dass in vielen Fällen der einzige verfügbare Mechanismus für die Gebührenzahlung CPFP sein wird. Wie oben erwähnt, ist dies ein potenzielles Problem, da es die außerbandgebundene Gebührenzahlung in Fällen, in denen die CTV-verwendenden Transaktionen klein sind, zu einer nicht unwesentlichen Kosteneinsparung macht.

Es ist fair zu sagen, dass CTV die breiteste Unterstützung innerhalb der technischen Community von jedem Covenant-Opcode-Vorschlag hat, aufgrund seiner relativen Einfachheit und des breiten Anwendungsbereichs.

LNHANCE

Ein Vorschlag zur Implementierung von CTV besteht darin, ihn mit zwei weiteren Opcodes, OP_CheckSigFromStack(Verify) und OP_InternalKey, zu kombinieren. Das Problem ist, dass die Dokumentation in diesem Pull-Req und den zugehörigen BIPs zum Zeitpunkt des Schreibens einfach nicht ausreichend ist, um für oder gegen diesen Vorschlag zu argumentieren. Die BIPs fehlen vollständig jede rationale Begründung dafür, was von den Opcodes tatsächlich in realen Beispielen erwartet wird, geschweige denn detaillierte Beispiel-Skripte.

Während die Autoren wahrscheinlich gute Gründe für ihren Vorschlag haben, liegt es an ihnen, diese Gründe tatsächlich zu erklären und angemessen zu rechtfertigen. Daher werden wir nicht weiter darüber diskutieren.

OP_TXHASH

Ähnlich wie CTV erreicht dieser Vorschlag eine nicht-rekursive Verpflichtungsfunktionalität durch Hashen von Daten aus der Ausgabentransaktion. Im Gegensatz zu CTV bietet der TXHASH-Vorschlag einen "Feldselektor"-Mechanismus, der Flexibilität bei der genauen Einschränkung der Ausgabentransaktion ermöglicht. Diese Flexibilität erreicht zwei Hauptziele:

1. Ermöglicht die Hinzufügung von Gebühren zu einer Transaktion, ohne ein Multi-TX-Protokoll zu brechen.
2. Mehrbenutzerprotokolle, bei denen Benutzer nur ihre eigenen Eingaben und Ausgaben einschränken.

Das Hauptproblem bei OP_TXHASH ist, dass der Feldauswahlmechanismus eine ziemliche Komplexität hinzufügt, was die Überprüfung und Prüfung im Vergleich zum viel einfacheren CTV-Vorschlag herausfordernd macht. Im Moment gab es einfach nicht viel Designanalyse darüber, wie vorteilhaft der Feldauswahlmechanismus tatsächlich sein würde oder wie genau er verwendet werden würde. Daher werden wir nicht weiter darauf eingehen.

OP_CAT

Der Verkettungsoperator, der die beiden obersten Elemente des Stapels verknüpft und das verknüpfte Ergebnis wieder auf den Stapel drückt. Bitcoin wurde ursprünglich mit aktiviertem OP_CAT ausgeliefert. Aber Satoshi wurde es 2010 stillschweigend entferntwahrscheinlich aufgrund der Tatsache, dass die ursprüngliche Implementierung aufgrund fehlender Beschränkungen für die Größe des resultierenden Skriptelements anfällig für DoS-Angriffe war. Betrachten Sie das folgende Skript:

DUP KATZE DUP KATZE…

Ohne eine Elementgrößenbeschränkung verdoppelt jede DUP CAT-Iteration die Größe des obersten Stapel Elements und verwendet letztendlich den gesamten verfügbaren Speicherplatz.

Die Verkettung reicht aus, um viele Arten von Verpflichtungen zu implementieren, einschließlich rekursiver Verpflichtungen, indem Sie Folgendes tun:

1. Eine teilweise Transaktion ohne Zeugendaten auf dem Stapel mit einer oder mehreren Aufrufen von OP_CAT (und der erforderlichen spezifischen Logik des Bundesvertrags) zusammenstellen.
2. Überprüfen Sie, ob die Transaktion auf dem Stapel mit der Ausgabetransaktion übereinstimmt.

Wie sich herausstellt, durchMissbrauch der Mathematik von Schnorr-Signaturen, es ist möglich, den zweiten Schritt mit OP_CheckSig über sorgfältig konstruierte Signaturen auszuführen. Es ist jedoch wahrscheinlicher, dass eine OP_CAT-Aufspaltung mit OP_CheckSigFromStack kombiniert wird, um den zweiten Schritt auszuführen, indem validiert wird, dass eine Signatur auf dem Stapel eine gültige Signatur für die Transaktion ist¹⁹, und dann dieselbe Signatur mit OP_CheckSig wiederverwenden, um zu überprüfen, ob die Ausgabetransaktion übereinstimmt.²⁰

Die Tatsache, dass wir nur die Transaktion ohne Zeugendaten zusammenbauen müssen, ist ein Schlüsselpunkt: Das Abkommen muss nur überprüfen, was die Transaktion tut - ihre Eingänge und Ausgänge - nicht die Zeugendaten (falls vorhanden), die sie tatsächlich gültig machen.

Abgesehen von den Größenbeschränkungen des Modulo-Skripts ist die Kombination aus OP_CAT und OP_CheckSigFromStack ausreichend, um viele Arten von Verträgen, einschließlich rekursiver Verträge, zu erstellen. Im Vergleich zu effizienteren Lösungen wie CTV ist dies teurer. Aber der Kostenunterschied ist geringer als erwartet!

Groß gesprochen erfordert die Verwendung von OP_CAT, dass der gesamte nicht-Zeuge-Teil der Ausgabentransaktion über den Zeugen auf den Stapel gelegt wird. Für typische CTV-Anwendungsfälle wie txout-Bäume wird die Ausgabentransaktion überhaupt keine Zeugen-Daten haben. Da der Zeugenplatz um 75% rabattiert wird, erhöht das unsere effektive Transaktionsgebühr für die Kindstransaktion nur um 25%. Nicht schlecht!

Ist OP_CAT zu mächtig?

Dies ist wahrscheinlich das größte politische und technische Hindernis für die Einführung von OP_CAT: Es ist sehr schwer vorherzusagen, welche Anwendungsfälle durch OP_CAT ermöglicht werden. Und wenn die "Katze" erst einmal aus dem Sack ist, ist es sehr schwer, sie wieder hinein zu stecken.

Ein großartiges Beispiel ist, wie behauptet wird, dass OP_CAT ausreicht, um relativ effizientes und sicheresSTARK-Verifizierung wird im Bitcoin-Skript implementiert. Da STARKs in der Lage sind, äußerst allgemeine Aussagen zu beweisen, hat die effiziente Implementierung von STARKs weitreichende Auswirkungen, die über den Rahmen von L2-Systemen hinausgehen, da dies viele verschiedene Systeme ermöglichen würde, die auf Bitcoin aufgebaut sind. Ein starkes Argument gegen OP_CAT ist, dass diese Anwendungsfälle möglicherweise nicht insgesamt gut für Bitcoin-Benutzer sind.

Die Schaffung von schädlich zentralisierendem Miner Extractable Value ist ein potenzielles Hauptproblem, bezeichnet als „MEV, das böse ist“ (MEVil)von Matt Corallo. Kurz gesagt, ist MEVil jede Situation, in der große Miner/Pools zusätzlichen Wert extrahieren können, indem sie ausgeklügelte Transaktions-Mining-Strategien anwenden - über die bloße Maximierung der Gesamtgebühren hinaus -, die für kleinere Miner/Pools praktisch unpraktisch sind. Die schiere Komplexität potenzieller Finanzinstrumente, die mit OP_CAT erstellt werden könnten, macht es sehr schwierig, MEVil auszuschließen. In Bitcoin ist bereits erhebliches MEVil von Token-Auktionsprotokollen aufgetreten; zum Glück wurde dieser spezielle Fall durch die Annahme von vollständigem RBF besiegt.

Neben dem Potenzial von MEVil gibt es viele andere konkrete OP_CAT-Anwendungsfälle, die potenziell schädlich sind. Zum Beispiel wurde der Drivechains-Vorschlag aufgespaltet.hier überprüft, und wird weitgehend als schädlich für Bitcoin angesehen. Es ist glaubte möglich zu seinum Drivechain mit OP_CAT umzusetzen. Ein weiteres Beispiel sind Token-Vorschläge wie Taproot Assets. Es ist zwar im Allgemeinen unmöglich, sie daran zu hindern, mit umgesetzt zu werdenClientseitige Validierung, es gibt Vorschläge, sie mit OP_CAT auf eine Art und Weise umzusetzen, die für Endbenutzer potenziell viel attraktiver ist, aber auch viel mehr Blockraum verwendet, was möglicherweise „legitime“ Bitcoin-Transaktionen überbieten könnte. Diese Anwendungsfälle können auch rechtliche Fragen aufwerfen, da Token-Protokolle häufig für Finanzbetrug verwendet werden.

Inkrementelles Hashing

Für Vereinbarungen wird OP_CAT hauptsächlich verwendet, um Daten zu verketten und dann zu hashen. Eine andere Möglichkeit, dieses Ziel zu erreichen, besteht darin, eine Art inkrementelle Hashing-Opcode zu verwenden, der einen SHA256-Zwischenzustand irgendeiner Art verwendet und weitere Daten darin hashiert. SHA256 selbst arbeitet mit 64-Byte-Blöcken. Es gibt viele mögliche Entwürfe für inkrementelle Hashing-Opcodes.

Eine wichtige Designentscheidung besteht darin, ob die tatsächlichen Zwischenzustandsbytes in irgendeiner Art von kanonischer Form auf dem Stapel offenbart werden sollen oder ob sie in einer neuen Art von opakem Stapelobjekttyp dargestellt werden sollen, dessen tatsächlicher Byte-Wert nicht direkt manipuliert werden kann. SHA256 ist für einen bestimmten, festen Initialisierungsvektor spezifiziert und es scheint unbekannt zu sein, ob die kryptografischen Eigenschaften von SHA256 zutreffen, wenn beliebige Zwischenzustände/Initialisierungsvektoren erlaubt sind.

Natürlich teilt es alle Bedenken hinsichtlich der zu großen Leistungsfähigkeit von OP_CAT, da das inkrementelle Hashing im Grunde genommen das Gleiche tun kann, nur effizienter.

Script Revival

OP_CAT war einer von 15 Opcodes, die Satoshi deaktiviert hat. Neben der Wiederherstellung von OP_CAT schlägt Rusty Russell vor,²¹um im Wesentlichen das Skript von Bitcoin auf „Satoshi's Original Vision“ wiederherzustellen, indem die meisten dieser Opcodes erneut aktiviert, DoS-Limits hinzugefügt und möglicherweise noch einige weitere im selben Soft-Fork hinzugefügt werden. Insbesondere ist ein OP_CheckSigFromStack wahrscheinlich.

Während OP_CAT allein (rekursive) Bündnisse möglich macht, würde eine vollständige „Skript-Wiederbelebung“ anspruchsvollere Bündnisse möglich machen - und viel einfacher zu implementieren -, da Teile der Ausgabetransaktion direkt manipuliert werden könnten. Sie könnten sich zum Beispiel ein Bündnisskript vorstellen, das arithmetische Opcodes verwendet, um sicherzustellen, dass der Gesamtwert der TxOuts in der Transaktion einer bestimmten Eigenschaft entspricht.

Erneut stellt die Wiederbelebung des Skripts alle dieselben Bedenken und mehr hinsichtlich einer möglichen Übermacht dar, die allein OP_CAT hat.

Einfachheit

Ähnlich wie Script Revival ist Simplicity im Zusammenhang mit L2 und Verträgen relevant, da es möglich ist, alles zu tun. Im Gegensatz zu Script Revival würde ein Simplicity Soft-Fork jedoch eine vollständig neue Programmiersprache zum Skriptsystem von Bitcoin hinzufügen, die auf neun primitiven Operatoren, bekannt als Kombinatoren, basiert.

In der Praxis ist Einfachheit sowohl zu einfach als auch überhaupt nicht einfach. Die primitiven Kombinatoren sind so lächerlich auf niedrigem Niveau, dass grundlegende Operationen wie Addition mühsam von Grund auf implementiert werden müssen. Das reine Simplicity wäre in der Praxis außergewöhnlich langatmig. Daher würde jede tatsächliche Verwendung von Einfachheit ein System von Code-Substitutionen verwenden, ähnlich wie Bibliotheksfunktionsaufrufe, die als bekannt sind.Jets. Dies stellt ein praktisches/politisches Problem dar: Wie entscheidet man, welche Jets implementiert werden sollen? Wahrscheinlich würden Jets in C++ implementiert werden, wie jeder andere Opcode auch, was eine Aufspaltung für jeden neuen Jet erfordert.

OP_FancyTreeManipulationStuff

Es gibt eine große Vielfalt an relativ spezialisierten Opcodes, die vorgeschlagen wurden, um Baummanipulationen auf effiziente Weise im Raum für Covenant-abhängige L2-Vorschläge durchzuführen. Zum Beispiel haben die Coinpools sowohl vorgeschlagen TAPLEAF_UPDATE_VERIFY und OP_MERKLESUBbeide manipulieren Taproot-Bäume auf die für den Coinpools-Vorschlag erforderliche Weise und die MATTDer Vorschlag hat eine OP_CheckContractVerify-Opscode vorgeschlagen, der im Wesentlichen Aussagen über Merkle-Bäume überprüft.

Für diesen Artikel müssen wir nicht im Detail auf jede dieser vielen Vorschläge eingehen. Stattdessen können wir über sie als Gruppe sprechen: Sie sind alle relativ anwendungsfallbezogene Vorschläge, die eine Klasse von L2 möglich machen, idealerweise ohne unbeabsichtigte Nebenwirkungen. Sie haben alle den Vorteil der Effizienz: Sie verwenden alle weniger Blockraum als die Erreichung des gleichen Ziels mit allgemeineren Operationencodes wie der OP_CAT-Manipulation. Aber sie alle haben den Nachteil, Komplexität in das Skriptsystem zu bringen, für einen potenziell spezialisierten Anwendungsfall.

Das Gleiche würde passieren, wenn Bitcoin das Simplicity-Skriptsystem übernehmen würde. Das Äquivalent zu Opcodes in Simplicity besteht darin, einen Jet für ein häufig verwendeten Muster hinzuzufügen. Die Implementierung von Jets für Use-Case-spezifische Operationen wie der Manipulation von Bäumen hat ähnliche Vor- und Nachteile wie die Implementierung komplexer Opcodes für Use-Case-spezifische Operationen.

Fonds Pools

Alle L2-Systeme, die versuchen, mehrere Benutzer dazu zu bringen, eine einzelne UTXO gemeinsam zu nutzen, können als eine Art Multi-User-Fondspool betrachtet werden, wobei die Benutzer im Besitz eines gewissen Rechts auf Abhebung sind. Möglicherweise gibt es auch einen Mechanismus, um Mittel in den Pool einzuzahlen (über die Schaffung des Pools mit vorab zugewiesenen Mitteln hinaus).

Damit ein Fonds-Pool nützlich ist, muss er mit irgendeiner Art von 'Share-Data-State' verbunden sein: Wie wird der TxOut-Wert aufgeteilt? Wenn der Fonds-Pool im Laufe der Zeit weiterentwickelt werden soll, muss sich dieser Zustand auch ändern, wenn Gelder dem Pool hinzugefügt oder daraus entfernt werden. Da wir auf Bitcoin aufbauen, wird das Hinzufügen oder Entfernen von Geldern aus dem Pool zwangsläufig das Ausgeben des von dem Pool kontrollierten UTXO beinhalten.

Beachten Sie, dass das Bitcoin-Konsenssystem selbst auf der Validierung von Zustandsänderungen basiert: Transaktionen beweisen über ihre Zeugen, dass Änderungen am UTXO-Set-Zustand gültig sind; Proof-of-Work ermöglicht es uns, uns darüber zu einigen, welcher Satz von Transaktionen korrekt ist. Dies bedeutet, dass Fondspools selbst auch auf der Validierung von Zustandsänderungen basieren: Wir beweisen jedem Bitcoin-Knoten, dass die Regeln für den Fondspool bei jeder Zustandsänderung befolgt werden.

Aber es gibt noch einen weiteren wichtigen Aspekt bei vertrauenslosen L2-Fonds-Pools: Wenn sich der Zustand des Fonds-Pools ändert, muss das System inhärent ausreichende Daten veröffentlichen, damit die Benutzer, die am Fonds-Pool teilnehmen, ihre Gelder wiederherstellen können. Wenn wir das nicht getan haben, dann versagt unser System, einseitige Abhebungen ohne die Zusammenarbeit Dritter zu ermöglichen. Viele auf Rollup-basierte Schemas scheitern hier: Sie leiden unter Datenverfügbarkeitsproblemen, bei denen der Benutzer seine Gelder nicht wiederherstellen kann, wenn Drittanbieter-Koordinatoren offline gehen, da sie keine Möglichkeit haben, die für sie erforderlichen Daten zu erhalten, um eine gültige Fonds-Wiederherstellungstransaktion zu erstellen.

Bei diesen Einschränkungen im Hinterkopf, auf welchen Datenstrukturen werden die Fondspools basieren? Unvermeidlich sind sie alle irgendeine Art von Baum. Genauer gesagt, eine Art von Merkle-Baum. Sie müssen ein Baum sein, weil das so ziemlich die einzige skalierbare Datenstruktur in der Informatik ist; sie müssen merkelisiert sein, weil das im Grunde die einzige vernünftige Möglichkeit ist, sich kryptografisch zum Zustand des Baums zu verpflichten. Schließlich werden Aktualisierungen am Baum zwangsläufig auf die Bitcoin-Blockchain veröffentlicht, weil das die eine istVeröffentlichungsmediumAlle L2-Benutzer teilen sich und ist der einzige Ort, an dem wir Benutzer zwingen können, ihre Münzen zu verschieben. Und da jede Covenant-Implementierung Teile des Baums benötigt, um zu überprüfen, ob die Regeln des Covenants befolgt werden.

Also, wenn die Hochstufentheorie aus dem Weg ist, wie übersetzt sich das tatsächlich in Bitcoin-Skripte und -Transaktionen?

Einzelne vorab signierte Transaktionen

Der degenerierte Fall eines Baumes, mit genau einem Blatt darin. Hier kann sich der Zustand unseres Fondpools grob gesagt einmal ändern. Zum Beispiel fällt ein standardmäßiger Lightning-Kanal in diese Kategorie und kann einmal geöffnet nur geschlossen werden. Die Daten, die veröffentlicht werden, wenn ein Kanal geschlossen wird, sind die Transaktion selbst, die ausreichende Informationen für die Gegenpartei im Kanal enthält, um die Txid aus den Blockchain-Daten zu erfahren und ihre Fonds durch Ausgeben wiederherzustellen.

Die einzige "Vereinbarung", die hier erforderlich ist, ist die grundlegendste Vereinbarung: die vorunterzeichnete Transaktion.

Txout Bäume

Das nächste, komplexere Entwurfsmuster, das wir in Fondspools sehen, ist der txout-Baum. Ark ist ein bemerkenswertes Beispiel. Hier kann der Fondspool aufgeteilt werden, indem der Root-UTXO in einem Baum von vordefinierten Transaktionen ausgegeben wird, die mit einfachen Covenants wie vorsignierten Transaktionen oder CTV durchgesetzt werden, wobei der Wert dieses UTXO in immer kleinere Beträge aufgeteilt wird, bis Blattknoten erreicht sind, die von den rechtmäßigen Eigentümern ausgegeben werden können.

Es ist wichtig zu erkennen, dass der Zweck des Txout-Baums darin besteht, den Benutzern Optionen zu geben, wie sie ihre Gelder wiederherstellen können, und diese Optionen haben ihren Preis: Ein Txout-Baum wird immer eine teurere Möglichkeit sein, einen Pool von Geldern aufzuteilen und sie an ihre Besitzer zurückzugeben, als einfach den UTXO in einer einzelnen Transaktion aufzuteilen. Jede Schicht im Baum verursacht Kosten aufgrund der Bytes, die für die Txouts und Txins verwendet werden, die erforderlich sind, um diese Schicht zu erstellen.

Welche Arten von Optionen könnte ein Txout-Baum bieten? Noch einmal, Ark ist ein großartiges Beispiel: Wir möchten nicht, dass die On-Chain-Einlösung eines einzigen V-UTXO erfordert, dass jeder einzelne V-UTXO in die Kette eingefügt wird. Durch die Verwendung eines Baums kann die Einlösung stattdessen den Baum in kleinere Teile aufteilen, bis das gewünschte V-UTXO in die Kette eingefügt wird.

Ähnlich wie bei der einzelnen vorsignierten Transaktion handelt es sich bei den veröffentlichten Informationen um die Transaktionen selbst, die die Brieftasche anderer Benutzer darüber informieren, wie sie ihr Geld bei Bedarf ausgeben können.

Die Skalierbarkeit von Txout-Bäumen hat interessante Skaleneffekte. Die Kosten für das erste V-UTXO, das in einem Fondspool mit n V-UTXOs auf die Kette gelegt wird, sind etwa log2(n) mal teurer als eine einzelne Transaktion, da log2(n) Ebenen von aufgespaltenen Transaktionen auf die Kette gelegt werden müssen. Sobald das erste V-UTXO jedoch auf die Kette gelegt wurde, werden nachfolgende V-UTXOs billiger, um auf der Kette eingelöst zu werden, da bereits jemand anderes die Kosten für das Schürfen der Zwischentransaktionen bezahlt hat.

Erinnern Sie sich daran, dass die Gesamtanzahl der Elemente in einem Binärbaum mit

Die Anzahl der Blätter beträgt 2n. Dies bedeutet, dass der Gesamtaufwand, alle V-UTXOs auf der Chain zu platzieren, über einen TxOut-Baum ein kleines Vielfaches des Gesamtaufwands beträgt, dies in einer einzigen Transaktion zu tun. Überraschend effizient!

Oder auch nicht... Wenn der Gesamtumfang der Rücknahmen des Fondspools ausreichend hoch ist, können sie eine nicht unerhebliche Nachfrage nach dem gesamten Blockspace darstellen. Blockspace ist ein Angebots- und Nachfragesystem, so dass die Gebühren aufgrund der hohen Nachfrage irgendwann steigen werden. Im Extremfall ist es durchaus möglich, so große und tiefe Bäume zu schaffen, dass man tatsächlich jeden

Es ist unmöglich, V-UTXO im Baum zu haben.

Eine offene Frage bei txout-Bäumen ist, wer die Gebühren bezahlt und wie? Eine offensichtliche Lösung besteht darin, schlüssellose Ankeroutputs für die Blatttransaktionen zu verwenden und es denjenigen zu erlauben, die die Blatttransaktionen schürfen möchten, die Gebühren über CPFP zu zahlen. In einigen Anwendungsfällen können die V-UTXOs selbst unmittelbar nach der Erstellung ausgegeben werden, ohne Verzögerung durch CSV, sodass die V-UTXOs selbst verwendet werden könnten, um Gebühren über CPFP hinzuzufügen.

RBF ist aufgrund der Berechtigung komplex zu implementieren: Der offensichtliche Ort, um Gebühren für RBF zu erheben, ist der V-UTXO-Wert. Aber wie stellen Sie sicher, dass nur der Eigentümer die Möglichkeit hat, eine Transaktion mit höheren Gebühren zu signieren? In vielen Fällen ist es nicht offensichtlich, wie dies effizienter als ein schlüsselloser Ankerausgang erfolgen kann. Das Versäumnis, dies zu tun, bringt jedoch ernsthafte Herausforderungen für die von Endbenutzer-Wallets verwendeten Schemata mit sich, die möglicherweise keine UTXO zum Durchführen einer CPFP haben, wenn die V-UTXOs selbst nicht sofort ausgegeben werden können.

Schließlich muss sorgfältig darüber nachgedacht werden, welche Anreize es in txout-Baumsystemen gibt und die Gebührenzahlung berücksichtigen. Zum Beispiel könnte in einem System wie Ark, wenn eine Gruppe von V-UTXOs einzeln zu teuer ist, um sie als on-chain-V-UTXOs zu verwenden, ein nicht kooperativer Koordinator ablehnen, diese V-UTXOs außerhalb der Kette einzulösen, und dann profitieren, indem er den Wert dieser V-UTXOs in einer einzigen UTXO-Ausgabe stiehlt, sobald ein Timeout erreicht ist.

Wenn dies der Fall ist, würde ein solches System unserer Meinung nach wahrscheinlich nicht den Kriterien entsprechen, um ein L2 für kleine V-UTXOs zu sein.

Guthabenbasierte Schemata

Der Zustandsautomat eines txout-Baums ist immer noch relativ einfach: Entweder der Fonds existiert oder er wird ausgegeben, um zwei oder mehr kleinere Fonds zu schaffen. Mit fortschrittlicheren Verträgen könnten wir stattdessen den Fonds als sich entwickelndes Guthaben behandeln, mit der Möglichkeit, Gelder von diesem Guthaben hinzuzufügen und abzuziehen.

Um dies zu tun, müssen wir einen nicht-trivialen Zustandsautomaten implementieren. Aber wir brauchen auch etwas, das im Wesentlichen eine gemeinsame Datenbank ist. Warum? Denn hier geht es darum, einen UTXO mit vielen verschiedenen Besitzern zu teilen. Wenn wir tatsächlich eine Verbesserung der Skalierbarkeit erreichen wollen, müssen wir dies auf eine Weise tun, die so wenig wie möglich von diesen Eigentumsdaten auf die Kette bringt.

Diese Anforderungen führen uns zwangsläufig zu einer baumartigen merkellisierten Datenstruktur, wie z.B. einem Merkle-Summenbaum. Die Manipulation dieser Datenstruktur erfordert zwangsläufig etwas wie OP_CAT, eine Art Zero-Knowledge-Beweis-Verifikations-Opcode oder einen speziell für die Baummanipulation bestimmten Opcode.

Interessanterweise können Sie wie bei TxOut-Bäumen keine bessere Skalierung als die Ordnung von log(n) beibehalten, während Sie ähnliche Sicherheitseigenschaften aufrechterhalten. Warum? Nehmen wir an, wir hätten ein hypothetisches OP_ZKP, das durch fortgeschrittene Mathematik nur 32 Bytes benötigt, um jede Aussage zu beweisen. Während dieser ZK-Beweis beweisen könnte, dass die merkelisierte Datenstruktur gemäß den Regeln des Layer 2-Systems manipuliert wurde, würde er nicht die Daten liefern, die der nächste Benutzer benötigt, um auch eine Zustandsänderung vorzunehmen. Dies erfüllt nicht unser bevorzugtes Kriterium, bedingungslose Auszahlungen zu ermöglichen: Im besten Fall könnte ein Benutzer eine bedingungslose Auszahlung erreichen. Aber keine weiteren Benutzer könnten dies tun.

Im Gegensatz dazu hat der nächste Benutzer genug Daten, um sein Verständnis des Systemzustands zu aktualisieren und selbst eine bedingungslose Auszahlung vorzunehmen, wenn die modifizierten Teile der merklisierten Datenstruktur über das Covenant Scriptsig veröffentlicht werden - z.B. die Geschwisterdigests in einem Merkle-Tree.

Ein möglicher Weg um dieses Problem herum besteht darin, dass der Vertrag den Nachweis der Veröffentlichung auf einem anderen Veröffentlichungsmedium als der Bitcoin-Kette erfordert. Allerdings werden die Sicherheitsgarantien schwächer sein als über Bitcoin möglich ist.

Beachten Sie schließlich, wie Txout-Bäume und ein auf Guthaben basierender Ansatz kombiniert werden können. Wenn die manipulierte Datenstruktur ein Txout-Baum ist, können Mittel durch Ausgeben der Ausgabe und Hinzufügen neuer Mittel mit einem Covenant-Skript, das validiert, dass die Mittel tatsächlich zum Txout-Baum hinzugefügt wurden, zum Txout-Baum hinzugefügt werden. Ebenso können Mittel durch alle für einen Txout-Baum normalerweise verfügbaren Mechanismen entfernt werden. Advanced Ark ist ein Beispiel für diese Art von Schema.

Verhältnis der Ausfalldaten

L2 erreicht Skalierung, indem es in adversen Situationen eine Interaktivitätsanforderung hinzufügt. In fast allen Fällen bedeutet dies, dass ehrliche Parteien im Protokoll Fristen haben, bis zu denen sie Transaktionen minen müssen; Wenn die Fristen nicht eingehalten werden, können Gelder gestohlen werden.

Die maximale Blockkapazität in allen dezentralen (und zentralen) Blockchains ist durch technische Einschränkungen begrenzt. Bei Bitcoin ist die maximale Blockgröße so, dass Bitcoin im Wesentlichen zu 100% der Zeit am Limit operiert. Da das Bitcoin-Mining ein Auktionssystem darstellt, bei dem der Blockraum an den Höchstbietenden versteigert wird, bedeutet dies in der Praxis, dass die Mindestgebühr für eine transaktionelle Mining steigt und fällt, je nachdem, wie die Nachfrage steigt und sinkt.

Die Gebührenrate spielt immer eine Rolle in den L2-Wirtschafts- und Fehlermodi. Zum Beispiel verwenden in Lightning „staubgroße“ HTLCs, die zu klein sind, um profitabel on-chain eingelöst zu werden, ein anderes Sicherheitsmodell als größere HTLCs. Obwohl das Lightning-Protokoll dies noch nicht ordnungsgemäß implementiert, sollte diese Schwelle theoretisch dynamisch sein, basierend auf den Gebührenraten, wenn sie steigen und fallen, idealerweise bis zu dem Punkt, an dem eine Partei basierend auf der Gebührenrate entscheiden könnte, ob ein HTLC überhaupt in einer bestimmten Commitment-Transaktion existiert oder nicht.

Es wurden verschiedene Angriffe vorgeschlagen, bei denen diese Situation absichtlich auf Lightning ausgelöst wird, wie z.B. Überflutung und Plünderung.²²und der Massenausstiegsangriff²³. Da die Kapazität der Bitcoin-Blockchain für alle Anwendungsfälle gemeinsam genutzt wird, sind auch Angriffe zwischen verschiedenen L2-Systemen möglich: zum Beispiel das Auslösen eines Massenausstiegs bei Ark, um von Lightning-Kanälen zu profitieren.

Layer 2-Netzwerke, die UTXOs unter mehreren Benutzern teilen, können diese Probleme potenziell noch verschlimmern, da der schlimmste Fall einer Blockplatznachfrage während eines Ausfalls proportional höher ist. Zum Zeitpunkt des Schreibens haben wir noch nie große Ausfälle bei Lightning gesehen, bei denen gleichzeitig viele Kanäle geschlossen werden mussten. Es gibt ein gutes Argument dafür, dass wir zusätzliche Betriebserfahrung mit Lightning und seiner skalierung von etwa 1 UTXO pro Benutzer sammeln sollten, bevor wir mit UTXO-Sharing-Systemen noch weiter gehen.

Zweitens sollte vor der weit verbreiteten Einführung neuer UTXO-Sharing-Schemata sorgfältige Forschung über die potenzielle Rentabilität von Angriffen während hoher Nachfrage nach Blockraum betrieben werden. Zum Beispiel in einem System wie Ark, in dem der ASP Mittel mit viel weniger Blockraum als andere Parteien einlösen kann, könnte es der Fall sein, dass absichtliches Auslösen hoher Gebührensätze und dann Ergreifen von Mitteln, die nicht profitabel einseitig abgehoben werden können, ein rentabler Betrug ist, der sowohl unsere Bedingungen für ein echtes L2-System verletzt.

Konsensbereinigung

Es gibt eine Reihe von Dingen, die Satoshi im ursprünglichen Bitcoin-Protokoll falsch gemacht hat, insbesondere Skript-DoS-Angriffe, den Timewarp-Angriff und Probleme mit dem Merkle-Baum. Zuvor wurden bereits eine Reihe anderer Konsensfehler mit Soft-Forks behoben, wie z.B. der Wechsel zur Auswertung von zeitbasierten nLockTime's gegen die vergangene Medianzeit, (der Versuch, das Problem mit der doppelten Transaktions-ID zu beheben), usw.

Der jüngste Soft-Fork, Taproot, hatte einen relativ umstrittenen Bereitstellungsprozess und dauerte ziemlich lange, um tatsächlich bereitgestellt zu werden. Ein Argument dafür, zuerst einen Konsensbereinigungs-Soft-Fork durchzuführen, bevor neue Opcodes oder andere Funktionen für neue Arten von L2's aktiviert werden, besteht darin, dass wir mehr darüber erfahren würden, wie bereitwillig die breitere Gemeinschaft ist, einen relativ unkontroversen Soft-Fork umzusetzen, der zweifellos allen zugute kommt.

Testing Soft-Fork abhängige Layer 2's

Entwickler müssen nicht darauf warten, dass eine Soft-Fork tatsächlich stattfindet, um ihre Ideen zu testen. Eine besonders ausgeklügelte Methode, die von den Ark-Entwicklern verwendet wird, in Bundeslose Archebesteht darin, die erforderlichen Verträge mit vorausgezeichneten Transaktionen zu simulieren. Dadurch können sie die Ideen von Ark mit echten BTC auf dem Mainnet testen und dabei dieselben Vertrauensmerkmale wie Ark mit Verträgen erreichen. Der Kompromiss besteht darin, dass Ark ohne Verträge erfordert, dass alle Parteien online sind, um die vorausgezeichneten Transaktionen zu unterzeichnen. Da clArk jedoch mit echten BTC funktioniert, könnte es sich sogar als nützlich genug erweisen, um in bestimmten Anwendungsfällen genutzt zu werden, die den Interaktivitätskompromiss tolerieren können.

Ein einfacherer Ansatz besteht darin, einfach so zu tun, als könnten bestimmte Parteien die Aktionen nicht ausführen, die Klauseln verhindern würden. Wenn zum Beispiel ein vorgeschlagenes Protokoll CTV verwenden möchte, um durchzusetzen, dass ein TXOUT-Baum in einem Transaktionsbaum ausgegeben wird, könnte jede Verwendung von CTV durch einen NOP oder CheckSig ersetzt werden. Obwohl der TXOUT-Baum in Wirklichkeit nicht durchgesetzt wird, kann jeder Code, der mit dem Baum interagiert, und jede Partei getestet werden, als ob er dies tun würde. Da NOP und CheckSig in Standard-Skripts erlaubt sind, kann das Protokoll mit echten Mitteln auf dem Hauptnetz getestet werden.

Potenzielle Soft-Forks

Wie geht es weiter? Hier werden wir alle wichtigen L2-Schemata auflisten, die wir analysiert haben, und welche Soft-Forks nützlich (U) oder erforderlich (R) sind, um diese L2-Schemata erfolgreich zu machen. Wie oben erwähnt, können OP_CAT (und damit auch Script Revival, das OP_CAT enthält) alle anderen Soft-Forks in dieser Liste emulieren – mit Ausnahme von OP_Expire und Fee Sponsorship – so dass wir dort, wo die Bedürfnisse eines Projekts am effizientesten von einer anderen Soft-Fork direkt erfüllt werden, OP_CAT nicht aufnehmen.

Wir werden auch alle vorgeschlagenen Merkle-Tree-Manipulations-Opcodes weglassen. Sie sind alle zu nischenhaft, zu anwendungsfallspezifisch, um zu diesem Zeitpunkt eine nennenswerte Chance zu haben, übernommen zu werden. In dem Maße, in dem diese Opcodes nützlich sind, ist die Implementierung ihrer Effekte über OP_CAT und/oder Script Revival ein viel wahrscheinlicherer Weg zur Akzeptanz.

CTV ist hier der klare Gewinner, gefolgt von SIGHASH_ANYPREVOUT (OP_Expire ist für viele Dinge nützlich, da es ein Ersatz für das Radfahren ist, aber nicht unbedingt erforderlich). CTV gewinnt, weil so viele Dinge in das Entwurfsmuster "Stellen Sie sicher, dass die Ausgabentransaktion mit dieser Vorlage übereinstimmt" passen; auch OP_CAT Konstruktionen CTV effizient nutzen können.

Im Gegensatz zu OP_CAT scheint CTV kein großes Risiko für unbeabsichtigte Folgen zu bergen, abgesehen von der Förderung von Out-of-Band-Gebührenzahlungen in bestimmten Fällen. Das ist nicht ideal. Aber niemand hat eine breit abgestützte Alternative gefunden.

Meine persönliche Empfehlung: Führen Sie eine Konsensbereinigung durch und führen Sie dann CTV durch.

Haftungsausschluss:

1. Dieser Artikel ist abgedruckt von [PeterTodd] Weiterleiten des Originaltitels 'Ist der Ethereum-Roadmap aus dem Takt geraten?', Alle Urheberrechte gehören dem Originalautor [petertodd]. Bei Einwänden gegen diesen Nachdruck wenden Sie sich bitte an denGate LearnTeam und sie werden es prompt bearbeiten.

2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.

3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.