Mit eltoo stellt Blockstream eine Forschungsarbeit für einen verbesserten Update-Mechanismus für das Lightning-Netzwerk vor, sowie Verträge, welche abseits der Blockchain ausgehandelt werden.
Nach etwas über einem Jahr, nachdem verschiedene Teams ihre Arbeit an einem gemeinsamen Protokoll-Stapel begonnen haben, funktionieren sowohl Spezifikation, als auch die verschiedenen Implementationen stabil. Laut Christian Decker ist es an der Zeit voraus zu schauen, um das Protokoll weiter zu verbessern, neue Funktionen hinzuzufügen, Schwächen auszugleichen und es zu vereinfachen.
Do you want to know what the future of #Lightning looks like?
#eltoo is a huge step towards a more flexible, secure and robust protocol. https://t.co/nJz45GK9FQ— Christian Decker (@Snyke) April 30, 2018
Wie funktioniert eltoo?
Dazu müssen wir verstehen, wie man sich eine Verhandlung abseits der Blockchain, auch off-chain genannt, vorstellen kann.
Eine Off-Chain-Verhandlung ist eine vertragliche Vereinbarung zwischen mehreren Teilnehmern, die beglichen wird, indem der Fall einem Gremium bzw. Gericht vorgelegt wird. Dieses entscheiden über den finalen Zustand. Das Gremium bzw. Gericht ist in diesem Fall die Blockchain.
Da alle Aktualisierungen zu dem Vertrag jedoch außerhalb der Blockchain stattfinden, bedarf es einer Möglichkeit für das Gericht, alle Seiten anzuhören, bevor ein endgültiges Urteil gefällt werden kann. Sollte ein Teilnehmer die Abwicklung eines Vertrages anfordern, braucht es einen Mechanismus um die finale Entscheidung aufzuschieben, damit der Gegenpartei die Möglichkeit gegeben ist, einen aktuelleren Zustand als den bekannten zur Verfügung zu stellen. Das Gericht muss so lange auf einen neueren Zustand warten, bis es beschließt den letztbekannten Zustand als final anzusehen. Die Bitcoin-Blockchain erfüllt die meisten Vorrausetzungen dafür bereits.
Jeder Zustand in eltoo setzt sich aus zwei Transaktionen zusammen:
- Update-Transaktion: verbraucht den Output des Vertrages und erstellt einen neuen.
- Abwicklungs-Transaktion (settlement): verbraucht den neu erstellten Output der Update-Transaktion und teilt das Geld nach einer vorab abgestimmten Verteilung.
Die generierten Outputs besitzen ein Skript, welches das sofortige Anhängen einer Update-Transaktion erlaubt oder das Anhängen einer Abwicklungs-Transaktion nach einer konfigurierbaren Auszeit (TimeOut). Sollten die Teilnehmer sich vorher auf ein neueres Update einigen, erstellen sie eine neue Update-Transaktion, welche den vorherigen Output ausgibt und die Abwicklungs-Transaktion „double spended“ und sie damit effektiv invalidiert.
Durch das wiederholte invalidieren von vorhergehenden Zuständen und das einigen auf einen neuen Zustand entsteht eine lange Kette von Update-Transaktionen, welche schließlich durch die letzte Abwicklungstransaktion abgeschlossen wird. Dies birgt den Nachteil, dass man bei finaler Abwicklung alle Updates auf der Blockchain abspielen müsste, man hätte das Proktoll also auch direkt on-chain ausführen können.
[caption id="attachment_2329" align="alignnone" width="956"]
Hier kommt eltoos großer Vorteil zum tragen. Man kann die Zwischenschritte überspringen und somit die letzte Update-Transaktion direkt an die Transaktion anhängen, welche den Vertrag aufsetzt.
Um dieses verkürzen der Kette von Updates zu bewerkstelligen, schlagen sie ein neues Flag vor, SIGHASH und SIGHASH_NOINPUT. Die würde es einer Transaktion erlauben, an eine beliebige Transaktion gebunden zu werden, welche ein passendes Skript vorweisen kann. Dadurch, dass alle Output-Skripts von vorherigen Updates mit den Input-Skripts von folgenden übereinstimmen, kann man ein späteres Update mit einem früheren verknüpfen, was es erlaubt Zwischenschritte zu überspringen.
Wie kann Lightning davon profitieren?
Der vorgestellte Mechanismus ermöglicht es, Endpunkten von Zahlungs-Kanälen wiederholt ihr Guthaben anzupassen und komplexere Konstrukte dem Zustand hinzuzufügen, beispielsweise HTLCs (Hashed-TimeLock-Contracts). Ein HTLC ist eine Zahlung, welche mittels Hashes und Zeitsperren den Empfänger einer Zahlung dazu zwingt, den Empfang zu bestätigen oder die Zahlung aufzugeben.
Das Lightning-Netzwerk besteht mittlerweile nicht aus einem einzelnen Protokoll sondern setzt sich aus einem ganzen Stapel verschiedener Protokolle zusammen, wovon jedes seine eigene Funktion erfüllt. Blockstream verfolgt nicht die Absicht, diesen Stapel zu ersetzen, sondern lediglich dem Update-Stapel um ein weiteres Instrument zu erweitern, welches Kompatibilität mit den bereits Vorhandenen behält.
Eine Übersicht über die bisherigen Schichten des Lightning-Protokolls findet sich folgend:
[caption id="attachment_2335" align="alignnone" width="1000"]
Im Gegensatz zu dem ursprünglichen durch das Lightning-Netzwerk vorgestellten Update-Mechanismus, welches Blockstream LN-Penalty tauft, zeigt eltoo gewisse Unterschiede auf.
Anstatt Strafe (Verlust des Kapitals) als Anreiz dafür zu nutzen, dass Teilnehmer nicht unehrlich handeln, erzwingt eltoo lediglich die Ausführung des letzten ausgehandelten Zustands des Off-Chain-Vertrages. Das bringt in Bezug auf Anwendbarkeit und Sicherheit wichtige Folgen für darauf aufbauende Protokolle mit sich.
Einige entstehen durch die Notwendigkeit, dass in eltoo alle Teilnehmer ein gemeinsame Menge an Transaktionen teilen. Dies ist anders als in LN-Penalty, welches eine Asymmetrie voraussetzt. Nicht jeder darf Zugriff auf jede Transaktion haben, um eine Reaktion auf Verhalten abbilden zu können. Durch die Einführung und Nutzung von eltoo werden die sogenannten toxischen Information eliminiert.
Toxische Informationen stammen aus Transaktionen veralteter Zustände, die bei Durchsickern zum Verlust von Geldmitteln führen. Dies geschieht nicht nur, wenn sich eine Partei schlecht benimmt, sondern auch, wenn ein Knoten ein Update vergisst (z.B. beim Wiederherstellen aus einem Backup). Mit eltoo ist dies nicht mehr möglich, da nur vereinbarte Zustände abgerechnet werden können (d.h. eltoo ist straflos).
Auch die Datenverwaltung für die Teilnehmer wird unter eltoo vereinfacht: Sie müssen keine „Hash-Vorabbilder“ (H-preimages) für invalidierte Zustände mehr speichern und keine HTLCs, die invalidiert wurden, da die Abrechnungstransaktion, an die sie angehängt wurden, niemals in die Blockchain eingepflegt werden kann. Alles, was sie speichern müssen, ist die letzte Update-Transaktion, die dazugehörige Abwicklungs-Transaktion und möglicherweise die HTLCs, die aus dieser Abwicklung Geld verwenden. Außerdem wird die Abwicklung vereinfacht, indem nur die letzte Update-Transaktion an den Setup-Output gebunden wird und der Timeout abläuft, bevor die Abwicklungs-Transaktion gesendet wird.
Mittels SIGHASH_SINGLE lassen sich weitere In- sowie Outputs an die finale Abwicklungs-Transaktion anhängen, dies birgt Vorteile: So können nötige Transaktionsgebühren erst bei der finalen Abwicklung hinzugefügt werden und erspart dies im Vorfeld. In der momentanen Implementierung muss man zu Beginn eine Gebühr im Vorfeld aushandeln und bereit stellen, welches eine Voraussage zur Entwicklung der Gebühren notwendig macht und zu Überschätzung führt, um auf der sicheren Seite zu sein. Durch das Loslösen der Gebühren, muss diese nicht vorab ausgehandelt werden und kann angepasst werden, sollte diese zu gering geschätzt worden sein.
Dank der Verwendung von Feature-Flags, die es einem Knoten ermöglichen, die Unterstützung für ein neues Feature zu signalisieren, wenn er sich zum ersten Mal mit einem Peer verbindet, kann eltoo inkrementell auf dem heutigen Netzwerk eingesetzt werden. Es besteht keine Notwendigkeit, ein komplett neues Netzwerk aufzubauen.
Bedeutung über Lightning hinaus
Als generischer Layer 2 Update-Mechanismus kann eltoo für beliebig viele Systeme außerhalb von Lightning eingesetzt werden. So können z.B. Mehrparteienverträge mit bis zu sieben Teilnehmern und beliebig vielen Teilnehmern in Kombination mit Schnorr-Signaturen erstellt werden.
Ein solcher Multiparty-Off-Chain-Vertrag ist die von Burchert, Decker und Wattenhofer als skalierbar beschriebene Möglichkeit, eine beliebige Anzahl von Zahlungskanälen über eine einzelne On-Chain-Transaktion zu finanzieren und diese dynamisch neu auszugleichen oder umzuverteilen, ohne jemals die Blockchain zu berühren.
Aber noch ist es nicht soweit
Bevor eltoo implementiert werden kann, bedarf es einer kleinen Änderung bei Bitcoin: die Einführung des SIGHASH_NOINPUT-Flags für Signaturen. Dies wurde erstmals vor einigen Monaten im Rahmen von Wachtürmen zur Sicherung von Lightning-Kanälen diskutiert, jedoch nicht formell vorgeschlagen. Ein offizieller Vorschlag ist nun im eltoo-Papier zu finden.
Blockstream lädt die Gemeinschaft ein, die Vorschläge zu prüfen und sich an der Diskussion zu beteiligen. Sie hoffen einen Konsens für die Verwendung von SIGHASH_NOINPUT zu erreichen, so dass es akzeptiert und in einem zukünftigen Soft-Fork des Bitcoin Script aufgenommen werden kann.
Dieser Update-Mechanismus wäre ein Weg zu einem zuverlässigeren und einfacheren Lightning Network.
