Vor etwas weniger als einem Jahr traten die drei Lightning Netzwerk Implementations Teams zusammen, um an einer gemeinsamen Spezifikation für den Protokollstapel zu arbeiten. Nun da sowohl diese Spezifikation und unsere drei Implementationen stabil und nutzbar werden ist es Zeit nach vorne zu schauen: Das Protokoll weiter zu verbessern, neue Features hinzuzufügen, zu vereinfachen und Kehrseiten auszubessern.
Eine der Kerninnovationen, die Lightning erst möglich machte, war der Off-chain Update Mechanismus, welcher einen State neu verhandelt und sicherzustellt, dass der der alte State nicht on-chain beglichen werden kann.
Heute sind wir erfreut unser neuestes Forschungspapier zu einem neuen, vereinfachten Update Mechanismus für Protokolle zweiter Ebene zu veröffentlichen, genannt Eltoo.
Wie funktioniert Eltoo?
Wir können uns die Off-chain Verhandlungen als vertragliches Abkommen zwischen einer Anzahl von Vertragsparteien vorstellen, und das Begleichen als Gerichtsvorladung welche den finalen State entscheidet - mit der Blockchain in diesem Falle als Gericht. Da alle Updates Off-chain stattfinden brauchen wir eine Methode, bei der das Gericht beide Seiten des Arguments hört bevor es ein endgültiges Urteil trifft. Im Falle dass ein Teilnehmer das Begleichen initiiert, brauchen wir einen Mechanismus, der das letzte Urteil vertagt um der Gegenpartei die Chance zu gebenm, einen neueren State zu präsentieren.
Das Gericht muss auf den neuen State warten, bis es eventuell den zuletzt gehörten State begleicht. Überraschenderweise sind die meisten Voraussetzungen um solch eine Blockchain für Protokolle zweiter Ebene maßzuschneidern bereits von der Bitcoin Blockchain erfüllt.
Figur 1: Eine Beispiel Ausführung des Eltoo Protokolls das zeigt, wie Zwischen-States übersprungen werden können indem eine spätere Update-Transaktion an eine frühere - oder direkt die Aufbau-Transaktion - neu-gebunden werden können. Nur die letzte Erfüllungs Transaktion kann je auf der Blockchain bestätigt werden.
In Eltoo ist jeder State als zwei Transaktionen repräsentiert: eine Update-Transaktion, die den Output des Vertrages verschickt und einen neuen Output kreiert, und eine Erfüllungs-Transaktion, die den neu erstellten Update Output versendet und die Mittel entsprechend der vereinbarten Verteilung teilt. Die Outputs haben ein Skript das erlaubt, eine Update-Transaktion entweder unmittelbar oder nach einer definierbare Auszeit anzufügen. Sollten die Teilnehmer sich auf ein Update einigen bevor die Auszeit abläuft, so erstellen sie eine neue Update-Transaktion, versenden die vorherigen Outputs und machen die entsprechende Zahlung mit einem ‘Double-spend’ effektiv ungültig.
Die wiederholte Aufhebung der vorherigen States, um sich auf einen neuen State zu einigen, baut eine lange Kette von Update-Transaktionen auf, die eventuell von der letzten Erfüllungs-Transaktion aufgekündigt werden. Allerdings hat dies einen großen Nachteil: Wenn wir den Vertrag begleichen wollen müssten wir die gesamte Kette von Updates auf der Blockchain abspielen. An diesem Punkt hätten wir einfach das gesamte Protokoll auf der Blockchain durchführen können. Die Kerneinsicht von Eltoo ist, dass wir diese Zwischen-Updates überspringen können und einfach die endgültige Update-Transaktion mit der Vertragsschließung verbinden können. Um dieses Kurzschließen von Updates zu ermöglichen schlagen wir einen neuen SIGHASH Marker vor, SIGHASH_NOINPUT, welcher erlaubt, einen Transaktionsinput an jeden Output mit einem passenden Skript zu binden. Da alle Output Skripts vorheriger Update-Transaktionen mit späteren Input Skripts übereinstimmen, können wir ein jedes späteres Update an jedes vorherige Update binden, was uns erlaubt dazwischenliegende Updates zu überspringen. Unsere Veröffentlichung enthält die komplette Konstruktion des Protokolls, inklusive Details wie die Skripts aufgebaut sind.
Lightning verbessern
Was wir obig vorstellen ist ein Update Mechanismus der den Endpunkten eines Zahlungskanals erlaubt, ihr Saldo wiederholt anzugleichen und fortgeschrittenere Konstrukte als HTLCs anzufügen.
Der Hauptbeitrag zur original Lightning Arbeit war solch ein Update Mechanismus, also versuchen wir Lightning mit diesem Vorschlag zu ersetzen? Absolut nicht!
Figur 2: Ein Diagramm der verschiedenen Unterprotokolle die Teil des Lightning Protokollstapels sind.
Die Lightning Netzwerkspezifizierung ist nicht mehr länger nur die Spezifizierung eines einzelnen Protokolls, sondern eher ein voller Stapel an Protokollen, die alle ihre eigenen Verantwortungen erfüllen. Eltoo zielt nicht darauf ab, den gesamten Lightning Protokollstapel zu ersetzen, sondern ist eher als Einbau-Ersatz für den original Update Mechanismus gedacht, der Rückwärtskompatibilität mit anderen Teilen des Protokollstapels beibehält.
Eltoo hat fundamental verschiedene Zielkonflikte als der in der original Lightning Arbeit präsentierte Mechanismus, welchen wir LN-Penalty benennen. Während LN-Penalty von einem Sanktionssystem Gebrauch macht um eine sich fehlverhaltende Partei zu bestrafen, so erzwingt Eltoo einfach den letzten vereinbarten State des Off-chain Vertrages.
Dies hat wichtige Auswirkungen für die Anwendbarkeit und Sicherheit des Protokolls die auf dem Update Mechanismus aufgebaut sind.
Einiges davon kommt daher, dass in Eltoo alle Teilnehmer einen gemeinsamen Satz Transaktionen teilen, während LN-Penalty Asymmetrie voraussetzt, bezüglich welcher Teilnehmer Zugang zu welchen Transaktionen hat, um die Reaktion auf die sich fehlverhaltenden Partei abzustimmen. Diese Änderung eliminiert was wir ‘giftige Information’ in Lightning nennen. Giftige Information kommt von Transaktionen die zu abgelaufenen States gehört, welche - falls durchgesickert - zu Verlust der Gelder führen wird. Dies passiert nicht nur wenn eine Partei aus dem Rahmen fällt, sondern auch falls eine Node einen Update vergisst (beispielsweise weil es von einem Backup wiederhergestellt wurde). Mit Eltoo ist dies nicht länger möglich, da nur vereinbarte States erfüllt werden können (Eltoo ist ohne Sanktionen).
Im neuen Modell ist die Datenverwaltung also für die Teilnehmer vereinfacht. Sie müssen nicht länger Hash Urbilder für entwertete States speichern, und sie müssen nicht länger HTLCs speichern die entwertet wurden, da die Erfüllungs-Transaktion an die sie gekoppelt wurde, nie mehr an die Blockchain übergeben werden kann. Alles was sie speichern müssen ist die letzte Update-Transaktion, ihre entsprechende Erfüllungs-Transaktion und potentiell die HTLCs die von dieser Transaktion senden. Außerdem ist die Erfüllung dahin vereinfacht, die letzte Update-Transaktion an den Aufbau-Output zu koppeln und die Auszeit verstreichen zu lassen bevor die Erfüllungs-Transaktion versandt wird.
Wir können die Update-Outputs mit SIGHASH_SINGLE kombinieren um das Anfügen von zusätzlichen Inputs und Outputs an die Update-Transaktion zur Zeit der Erfüllung zu erlauben. Während dies wie eine geringe Veränderung aussehen mag, erlaubt es das Hinzufügen von Gebühren an die Update-Transaktion zur Zeit der Erfüllung, was uns davon befreit, uns auf eine fixierte Gebühr vorzeitig festzulegen. In der momentanen Implementation müssen wir uns darauf einigen, und festlegen, eine fixierte Gebühr potentiell Monate bevor wir versuchen, die Transaktion on-chain zu bestätigen, was uns zwingt vorauszusehen, wie sich der Markt für Gebühren entwickelt. Dies kann zu massiven Über-Verpflichtungen führen wenn wir auf der sicheren Seite sein wollen. Mit verschobener Gebührenauswahl müssen wir uns nicht auf eine Gebühr einigen, und wir können sogar Gebühren erhöhen sollten sich diese als unzulänglich herausstellen.
Dank dem Nutzen von Feature Markern, welche es einer Node bei Erstverbindung erlauben Unterstützung für neue Features zu signalisieren, kann Eltoo bereits heute stufenweise auf dem heutigen Netzwerk ausgerollt werden. Es gibt nicht die Notwendigkeit ein komplett neues Netzwerk aufzubauen.
Über Lightning hinweg
Als generischer Update Mechanismus für Protokolle zweiter Ebene kann Eltoo auch für Systeme über Lightning hinweg benutzt werden. Zum Beispiel erlaubt es die Erstellung von Mehrparteien Off-chain Verträgen die momentan bis zu sieben Teilnehmer haben können, und zusammen mit Schnorr Signaturen sogar jede beliebige Zahl von Teilnehmern haben.
Ein solcher Mehrparteien Off-chain Vertrag sind Kanalfabriken wie von Burchert und Co. präsentiert, als ein skalierbarer Weg um jede Zahl von Zahlungskanälen auf einzelnen On-chain Transaktionen zu finanzieren oder sie dynamisch zu rebalancieren oder neu bereitzustellen, ohne je die Blockchain zu berühren.
Der Weg zu Eltoo
Bevor wir Eltoo implementieren können, brauchen wir eine kleine Veränderung in Bitcoin: Die Einführung des SIGHASH_NOINPUT Markers für Signaturen. Dies wurde zuerst vor einigen Monaten diskutiert, im Kontext von Watchtowers um Lightning Channels zu sichern, wurde aber nicht formell vorgeschlagen. Ein formaler Vorschlag könnte nun in der Eltoo Arbeit gefunden sein.
Wir laden die Gemeinschaft ein, unseren Vorschlag anzuhören und an der Diskussion teilzunehmen. Wir hoffen auf eine Einigung über den Nutzen von SIGHASH_NOINPUT zu kommen, sodass es akzeptiert werden kann und in einen zukünftigen Softfork des Bitcoin Skripts einfliessen kann. Dies wird uns auf den Weg zu einem einfacheren und zuverlässigerem Lightning Netzwerk bringen und uns erlauben, einen neuen Update Mechanismus einzubauen der auch in vielen anderen Anwendungen verwendet werden kann.