Es gab viele Diskussionen und Artikel darüber, wie die Implementierung von AMP den Routing-Funktionen von Lightning Network zugute kommen wird. Was ist das genaue Problem in der aktuellen Implementierung von Lightning, das AMP löst? Wie funktioniert AMP wirklich? und wie wird es umgesetzt?
Die größte Herausforderung im aktuellen Routing-Mechanismus besteht darin, Kanäle mit ausreichendem Guthaben auf einer Seite eines Knotens zu finden, um eine eingehende Zahlung weiterzuleiten. Um es anschaulicher zu machen, die channel_announcementoder die channel_updategesendeten Nachrichten enthalten die, short_channel_iddurch die Lightning Nodes die Transaktion in der Bitcoin-Blockchain nachschlagen und herausfinden können, wie viele Bitcoins in diesem Kanal gesperrt sind. Man weiß jedoch nicht, wie viel jeder Knoten des Kanals enthält. Dies schafft ein Problem in Bezug auf das Weiterleiten einer Zahlung, da eine Seite des Kanals möglicherweise nicht über genügend Guthaben verfügt, um die Transaktion weiterzuleiten, was zu einem Routing-Fehler führt und der Ursprungsknoten die Zahlung unter Verwendung einer anderen Route erneut versuchen muss.
Das zweite Problem betrifft die Kanalbilanzen des Ursprungsknotens. Angenommen, ich kaufe eine Tasse Kaffee bei Starbucks, die mich 20.000 Satoshis kostet. Jetzt habe ich drei offene Kanäle im Lightning-Netzwerk mit einem Guthaben von 9.000 Satoshi in jedem Kanal. Wenn ich vorerst die Kanalreserve und die Transaktionsgebühren vernachlässige, kann ich in jedem Kanal nur Zahlungen von 9.000 Satoshis leisten, was mich unfähig macht, diese Tasse Kaffee in einer einzigen Zahlung zu kaufen. Die Lösung wäre, drei Zahlungen auf dieselbe Zahlungsrechnung zu leisten, die Starbucks mir anbietet, wenn ich diese Tasse Kaffee über alle drei Kanäle kaufe. Dies führt jedoch zu Sicherheitsproblemen durch die Wiederverwendung von Hash. Ein Knoten mit Kanälen über die Pfade kann das Vorabbild, das er von einem Pfad gelernt hat, verwenden, um eine Zahlung entlang des anderen Pfads auszuführen. Auch,
Das dritte Problem ist, dass wir derzeit (wenn auch vorübergehend) ein Limit von 2 32 Millisatoshi (~0,0429 BTC) für eine einzelne Zahlungsgröße haben. Zahlungen über diesem Limit müssen über mehrere Zahlungen erfolgen. Dies birgt jedoch wiederum das Risiko, dass eine Zahlung durchgeht und nachfolgende Zahlungen den Empfänger nicht erreichen. Sie müssen dann den Empfänger bitten, eine Rückerstattung an Sie zu bearbeiten.
Conner Fromknecht und Olaoluwa Osuntokun schlugen Atomic Multi Path (AMP)-Zahlungen vor, um die beiden oben genannten Probleme zu lösen, indem sie eine größere Zahlung in kleinere aufteilen und gleichzeitig keine Zahlungs-Hashes für alle kleineren Zahlungsströme wiederverwenden und hinzufügen eine starke Garantie, dass der Empfänger überhaupt nicht bezahlt wird, bis alle Teilzahlungsströme abgeschlossen sind (Atomizität).
Ihr Vorschlag erforderte, dass der Absender bei jeder kleineren Zahlung ein Geheimnis an den Empfänger sendete, s_ii. Wenn alle Zahlungen beim Empfänger eingegangen sind, erstellt er das Basiszahlungsgeheimnis (BP), indem er XOR aller vom Absender gesendeten Teilgeheimnisse nimmt, so dass BP = s_1 ^ s_2 ^ ... ^ s_n. Jetzt ist jedes Zahlungsvorbild SHA256(BP || i). Dies hatte den Vorteil, dass der Empfänger das Pre-Image nicht erstellen konnte, bis alle Teilzahlungen eingegangen sind, wodurch sowohl das Teilzahlungs- als auch das Hash-Wiederverwendungsproblem gelöst wurden.
Diese Form des Zahlungsvorschlags ist wirklich hilfreich, wenn sie unter Freunden gemacht wird, aber für den geschäftlichen Gebrauch hat dieser Vorschlag eine Schwäche. Wir betrachten den Erhalt eines Pre-Images als kryptographischen Nachweis, dass eine erfolgreiche Zahlung erfolgt ist. Wenn der Absender die Vorabbilder kennt und vorher berechnen kann, zerstört dies das ganze Prinzip einer kryptografischen Quittung, die Sie vom Empfänger der Zahlung erhalten. Da der Vorschlag verlangte, dass der Absender die gemeinsamen Geheimnisse und die erstellte payment_hash, kannte der Absender die Pre-Images im Voraus.
Um dieses Problem zu lösen, wurde Basic MPP (Multipath Payments) vorgeschlagen. Basis-MPPs verwenden dasselbe payment_hashfür alle Pfade, über die die Zahlung erfolgt. Der Empfänger gibt das Zahlungs-Pre-Image jedoch nicht frei, bis alle erfolgreichen Zahlungen eingegangen sind, um die Möglichkeit zu vereiteln, dass ein Zwischenknoten das Pre-Image von einem Zweig der Zahlung verwendet und den anderen Zweig befriedigt. Da Zahlungsnachweise wertvoll sind, wird kein vernünftiger Zahlungsempfänger Teilzahlungen akzeptieren, bis alle Teile der Zahlung eingetroffen sind, und wird daher kein Vorabbild freigeben. Wenn er jedoch das Vorabbild entlang eines Pfades freigibt, liegt es im wirtschaftlichen Interesse des Zahlungsempfängers, das Vorabbild entlang aller Pfade freizugeben.
Im Lightning Network-Protokoll wird jetzt im Vergleich zu einem Byte-Stream mit fester Länge in früheren Versionen ein neues TLV-Format (Type-Length-Value) verwendet . Die Verwendung von TLV ermöglicht eine Platzersparnis, wodurch möglicherweise mehr Platz für Anwendungsdaten über die Leitung oder in einer Onion-Nutzlast übrig bleibt. Knoten, die solche variablen Payload-Routing-Zwiebeln unterstützen, zeigen dies an, indem sie das Flag setzen global_features, Bits 8/9 ( var_onion_optin). Darüber hinaus muss die generierte Lightning-Rechnung die Funktion festlegen basic_mpp.
Base AMPs verwendet dasselbe payment_hashfür alle Pfade, über die die Zahlung erfolgt. Wenn der Endknoten ein Zwiebelpaket empfängt, das ein basic_mppFeld enthält, dann KANN die Zahlung ein "Basis"-AMP sein. Das Setzen des basic_mppFlags ist ein Versprechen des Absenders, dass der Rest der Zahlungen in nachfolgenden HTLCs folgen wird. Alle HTLCs, die empfangen werden, die die Zahlungen mit dem gleichen Zahlungsvorabbild erfüllen, werden als "htlcset" bezeichnet.
Nach Erhalt einer Zwiebel mit basic_mppmuss der Empfänger mindestens 60 Sekunden warten, bis alle anderen Zahlungen eingegangen sind. Wenn die Zahlungen nicht in einem ausreichenden Zeitraum empfangen werden, muss der letzte Knoten alle htlcs im htlcset durchfallen lassen. Wenn es jedoch irgendwelche HTLCs im htlset erfüllt, muss es ALLE erfüllen. Diese Teilmengenbeschränkung verhindert, dass das Pre-Image freigegeben wird, bevor alle Teilzahlungen eingetroffen sind: Dies würde es jedem Zwischenknoten ermöglichen, sofort alle ausstehenden Teilzahlungen zu fordern.
An High AMPs wird derzeit gearbeitet. Es kombiniert sowohl die ursprünglichen Vorschläge von AMP als auch das aktuelle Basis-MPP, behält den Zahlungsnachweis bei (der durch den ursprünglichen Vorschlag geopfert wurde) und gewährleistet ein kryptografisch sicheres Warten auf alle Teile (anstelle des bloßen wirtschaftlichen Anreizes von Basis-AMP). .
Dies erfordert jedoch, dass wir auf Punkte und Skalare statt auf Hashes und Pre-Images umsteigen. Eine Rechnung enthält nun einen Zahlungspunkt, der im Wesentlichen durch Multiplikation eines Skalars (entspricht privatem Schlüssel) mit dem Standardgeneratorpunkt auf generiert wird secp256k1. Der Zahlungsnachweis erfordert keine Offenlegung des Skalars, aber eine Signatur unter Verwendung des Skalars hinter dem öffentlichen Schlüssel reicht aus, um den Zahlungsnachweis zu erbringen. Dies ermöglicht auch die Unterstützung der Zahlungsdekorrelation (zusätzliche Skalare werden bei jedem Hop hinzugefügt, und der Gesamtskalar wird dem Zahlungsempfänger mitgeteilt), während weder ein Zahlungsnachweis noch spontane Zahlungen erforderlich sind (es kann mit beidem funktionieren). Dies ist im Grunde die skriptlose Skriptverwendung auf Lightning. Anstelle von HTLCs haben wir Scriptless Script Pointlocked Timelocked Contracts (PTLCs).
Die Implementierung davon würde jedoch eine Schnorr-Implementierung auf der Bitcoin-Mainchain erfordern, die möglicherweise einige Jahre zurückliegt.
René Pickhardt
Ugam Kamat
fiatjaf
Ugam Kamat