Das nächste Jahrzehnt, Teil 2: Der Weg nach vorn

Wir fangen bereits an, die Keimzellen des Potenzials der zweiten Schicht zu sehen, die sich aus den Basis-Layer-Primitiven entwickeln, die im ersten Jahrzehnt hinzugefügt oder optimiert wurden. Lightning, obwohl immer noch einigen ziemlich großen Einschränkungen unterliegt, beginnt wirklich zu gedeihen. Und das ist nur die begrenzte erste Version, die derzeit festgelegt und implementiert ist. Es gibt jetzt Sidechains verschiedener Art: Liquid, RSK und sogar Tokenketten, die von Commerceblock an Bitcoin gebunden entwickelt wurden. Das ist erst der Anfang.

Schnorr und Taproot

Gleich hinter dem Horizont haben wir die Kombination aus Schnorr und Taproot. Auf der Schnorr-Seite ist dies ein viel billigeres, um das Signaturschema in Stapeln zu verifizieren, sowie der nächste große Sprung bei der Optimierung des Konstrukts von Multi-Signatur-Skripten in Bitcoin. Multisig begann damit, einfach alle öffentlichen Schlüssel und das Skript für die Multisig in eine Transaktionsausgabe zu stopfen, um sie an sie zu senden, und musste all dies in die Eingabe aufnehmen, um sie auszugeben. P2SH optimierte den Ausgabeaspekt, indem es einen Hash der öffentlichen Schlüssel und Skripte der Multisig mit konstanter Länge einfügte, was Gebühren für alle spart, die an eine Multisig-Adresse senden, und nur für den Absender erhöhte Kosten hinterließ. SegWit hat wohl weiter “optimiert”, indem es die Ausgaben für Multisig-UTXOs mit dem Zeugenrabatt billiger gemacht hat. Schnorr treibt all diese inkrementellen Optimierungen auf die Spitze. Sie kombinieren die einzelnen öffentlichen Schlüssel zu einem einzigen Schlüssel, für den alle zusammenarbeiten können, um eine einzige Signatur zu erstellen, und überprüfen Sie das einfach. Dies führt zu massiven Kosteneinsparungen für die gesamte Verwendung von Multisig, einschließlich zweiter Schichten wie Lightning und föderierter Sidechains, und schafft auch einen Vorteil für die Privatsphäre, da alle diese Multisig-UTXOs nicht mehr von denen mit einer einzigen Signatur zu unterscheiden sind.

Das macht nicht einfach alles magischerweise komplett privat. Lightning-Kanalzustände (Transaktionen) erfordern immer noch separate Schlüsselpfade für ihre Straftransaktionen, um auf die Einreichung alter Zustände zu reagieren. Das bedeutet, dass diese in den Ausgabeskripten sein müssen, was einen Fingerabdruck erzeugt. Taproot löst dies mit seiner Kryptomagie, die es Ihnen erlaubt, einen Merkle-Baum verschiedener Ausgabefunktionen zu verpflichten, die nur die verwendete Bedingung und den Merkle-Beweis zum Merkle-Root benötigen, um einen ganz normal aussehenden Schnorr-Öffentlichen Schlüssel auszugeben. Jetzt können Sie diesen Straf-Skriptpfad mit Taproot verbergen. Sie können jeden bedingten Skriptpfad mit Taproot verbergen, der unter einem vollkommen normal aussehenden Schnorr-Schlüssel vergraben ist, der es allen Beteiligten erlaubt, sich auf etwas zu einigen und eine vollkommen normal aussehende Transaktion zu tätigen.

SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (zuvor SIGHASH_NOINPUT)ist hoffentlich die nächste neue Primitiv, das auf dem Weg ist. Es handelt sich um ein neues öffentliches Schlüsselformat/eine Sighash-Flagge-Aktualisierung. Sighash-Flags geben an, zu welchen Teilen einer Transaktion eine Signatur sich verpflichtet. Diese Funktionalität ist vorhanden, damit Sie beispielsweise nur Ihre Eingabe und Ausgaben signieren können, anderen Personen jedoch gestatten können, ihre eigenen Eingaben und Ausgaben zu einer Transaktion hinzuzufügen, ohne diese zu invalidieren. Aktuell muss eine Signatur sich jedoch auf eine genaue UTXO aus einer genauen Transaktion verpflichten. SIGHASH_ANYPREVOUT würde unter anderem die Verpflichtung einer Signatur auf nur ein UTXO-Skript ermöglichen, nicht auf einen tatsächlichen spezifischen UTXO. Dies ermöglicht eine neue Methode (eltoo), um Lightning-Kanalzustände zu konstruieren, die keinen Strafschlüssel erfordern oder alte Zustände behandeln, indem sie der betrogenen Partei erlauben, das gesamte Geld zu konfiszieren. Stattdessen könnte der aktuelle Kanalzustand einfach den alten Kanalzustand erneut ausgeben, falls er das Wettrennen um den Doppelausgabefall verlieren sollte, wodurch garantiert wird, dass jeder seinen aktuellen Kanalsaldo auf der Chain erhält, im Gegensatz zu einem zuvor veralteten Saldo. Das erreichen Sie, indem Sie einfach dasselbe Skript am richtigen Ort wiederverwenden und SIGHASH_ANYPREVOUT verwenden.

Dies entfernt viele Risiken, die damit verbunden sind, dass Sie aktuelle Kanalzustände verlieren und eine Straftransaktion durchgeführt wird, die Ihre Gelder aufgrund eines ehrlichen Fehlers einnimmt. Es ermöglicht auch VIEL mehr. Jetzt können wir Lightning-Kanäle mit mehr als 2 Teilnehmern haben und sogar „Unterkanäle“ darauf stapeln. Außerdem ermöglichen SIGHASH_ANYPREVOUT und eltoo die Erstellung von Statechains, einer Art föderierten Kanalkonstruktion, die es neuen Teilnehmern ermöglicht, vollständig außerhalb der Kette einzusteigen und auszusteigen, unter der Vertrauensannahme, dass die Föderation nicht mit früheren Teilnehmern zusammenarbeiten wird, um jemanden zu betrügen. Dies eröffnet viel Potenzial für das, was ich mir selbst als „Multi-Party-Static-UTXO-Protokolle“ genannt habe.

OP_CHECKTEMPLATEVERIFY

OP_CTV ist ein Vorschlag von Jeremy Rubin, um einen sehr grundlegenden Typ eines “Bundes” auf Bitcoin zu ermöglichen. Ein Bund ist eine kompliziertere Beschränkung beim Ausgeben einer Münze über Signaturen von bestimmten Schlüsseln hinaus. Der Typ des Bundes, den Rubins Vorschlag umsetzen würde, ist eine “Vorlage”. Im Wesentlichen ermöglicht dies einem UTXO-Skript, spezifische genaue Ausgaben zu erfordern, die von der ausgebenden Transaktion erstellt werden müssen. Wenn also ein UTXO unter Verwendung von OP_CTV erstellt wird, wird durch Konsens durchgesetzt, dass der UTXO an spezifische Adressen in den spezifischen Beträgen ausgegeben werden muss, die in diesem UTXO-Skript definiert sind. Sie können diese sogar miteinander verketten, sodass einer dieser UTXOs gezwungen ist, ein paar weitere von ihnen zu erstellen, die dann gezwungen sind, ein paar weitere zu erstellen, und so weiter.

Dies hat eine enorme allgemeine Anwendbarkeit an allen Ecken und Enden. In Umgebungen mit hohen Gebühren kann ein einzelner UTXO von einer Depotbank erstellt werden, die 100% nach Konsensregeln garantiert, dass alle Gelder ihrer Kunden unter der Kontrolle ihrer Kunden landen, auch wenn sie im Moment keinen unmittelbaren Zugriff darauf haben. Dies hat eine Menge potenzieller Synergien mit Mehrparteienkanälen (channel factories), da ein solcher Massen-“Entzug” gleichzeitig auch eine Kanalfabrik schaffen und als solche genutzt werden kann. OP_CTV kann verwendet werden, um Zahlungskanäle zu erstellen, die zumindest unidirektional funktionieren, ohne dass das empfangende Ende teilnehmen oder einen Schlüssel online haben muss, um Zahlungen zu empfangen (and denken Sie daran, dass Sie Kanäle auf jedem other) stapeln können. Es kann sogar verwendet werden, um einem einzelnen Kanal zu ermöglichen, mehrere HTLCs gleichzeitig zu verarbeiten, indem sie mit dem gleichen Trick gebündelt werden, den das erste Beispiel mit Verwahrungsabhebungen verwendet. Und könnte sogar ein gewisses Potenzial für neue Arten von Coinjoins schaffen.

Alles zusammenfügen

Vorausgesetzt, alle oben genannten Vorschläge werden übernommen und in Bitcoin integriert, denke ich wirklich, dass abgesehen von den Entwicklern, die tatsächlich an der Spitze dieser Dinge arbeiten, die Leute nicht einmal die leiseste Ahnung haben, welche Arten von Protokollen und Diensten unter Verwendung dieser Primitiven erstellt werden. Oder die seltsamen Dinge, bei denen es keine klare Trennlinie zwischen Dienst oder Protokoll gibt.

Sie werden mehrparteienkanäle mit theoretisch unbegrenzter Teilnehmerzahl ermöglichen, die Subkanäle mit kleineren Untergruppen der Teilnehmer des Basiskanals stapeln können. Kanäle können auf diesen „Kanalfabriken“ gebaut werden, die es den Menschen ermöglichen, Geld zu erhalten, ohne dass Schlüssel online für eine Hot Wallet vorhanden sind. Diese Mehrparteienkanäle können selbst auf föderierten Kanälen stapeln, (statechains), die es den Teilnehmern ermöglichen, ohne jegliche On-Chain-Aktivität einzutreten oder auszutreten! Und die Konstruktion des Kanal „Splicings“ wird es ermöglichen, dass Liquidität relativ nahtlos zwischen verschiedenen Kanälen bewegt werden kann, auf Arten, die alle Arten von Dingen ermöglichen werden, über die die Menschen noch nicht einmal wirklich nachgedacht haben.

Mein letztes Wort in diesem Abschnitt lautet: Dies berücksichtigt nur, was mit Dingen gemacht werden kann, die ich als direkte Bestandteile des Bitcoin-Protokollstapels betrachte. Sie können viel mehr tun, wenn Sie sich zentrale Verwahrungsdienste ansehen und welche Teilmenge der Eigenschaften von Bitcoin diese bieten können, wenn Sie regulatorische oder rechtliche Barrieren ignorieren.

Dies ist nur Teil 2 von 4, lesen Sie den nächsten Teil morgen