lndKürzlich wurde auf Github ein WIP-Entwurf für einen „Sphinx-Zahlungsmodus“ für Lightning Network-Knoten veröffentlicht . Um Roasbeef aus dem Github PR zu zitieren :
[dies ermöglicht] die Möglichkeit, eine Zahlung an ein Ziel zu senden, ohne zuerst eine Rechnung zu benötigen
Obwohl dies ein WIP ist, kann es anscheinend bereits im Mainnet verwendet werden, solange alle beteiligten Knoten aktualisiert werden, um den neuen Code aufzunehmen.
Wie funktioniert das? Wie sieht die UX auf hoher Ebene aus? Welche Unterschiede gibt es auf niedriger Ebene in Bezug auf den Abschluss der Zahlung (Weitergabe von HTLCs) im Vergleich zu einer Standard-LN-Transaktion? Was geht unter der Haube vor?
Normalerweise generiert ein Händler einen (pseudo-)zufälligen 32-Byte-Wert und hasht ihn. Dieser wird zum Payment_Hash, der die Zahlung im Netzwerk identifiziert und in einer Rechnung an den Käufer übermittelt wird. Wenn der Benutzer die Zahlung vornimmt, sendet er diesen Payment_Hash mit einem Zwiebelpaket als bedingte Zahlung, die abgeschlossen wird, wenn das Preimage des Hashs bereitgestellt wird. Jeder Hop leitet diesen Zahlungs-Hash weiter, bis das Ziel dem vorletzten Hop sein Urbild offenlegen muss, um den Geldtransfer abzuschließen. Der Hopfen überträgt dann das Urbild rückwärts durch die Route, bis es den Käufer erreicht, und dient als Beweis dafür, dass die Zahlung erfolgreich war, unter der Annahme, dass niemand außer dem Händler das Urbild kennen könnte.
Die HTLCs sind bei spontanen Zahlungen genau gleich, der Unterschied besteht darin, dass der Käufer das Zahlungs-Preimage und den Zahlungshash erstellt. Der Payment_Hash wird wie gewohnt übertragen, aber das Preimage wird innerhalb des Onion-Routing-Pakets so verschlüsselt, dass nur der Händler es entschlüsseln kann.
Das Zwiebelpaket hat 12 Füllbytes bei jedem Hop, die verwendet werden können, um zusätzliche Daten zu senden, aber das Zwiebelpaket kann auch "virtuelle Hops" nach dem Zielhop der Zahlung haben, die der Händler entschlüsseln kann. Diese virtuellen Hops können 32 Byte an Daten enthalten, da die üblichen Felder für Betrag, SCID und cltv für zusätzliche Daten umfunktioniert werden können, da Sie keine Zahlung über das Ziel hinaus weiterleiten. Ein paar Bytes werden als Flags verwendet, um den Datentyp anzugeben, und die Aggregation der zusätzlichen Daten in den virtuellen Hops wird als Extra Onion Blob (EOB) bezeichnet.
Das gesamte Zwiebelpaket bleibt gleich groß, sodass die Menge an zusätzlichen Daten, die mit der Zahlung übertragen werden können, immer noch begrenzt ist, denn je mehr Sprünge für die tatsächliche Zahlung erforderlich sind, desto weniger virtuelle Sprünge. Eine spontane Zahlung erfordert mindestens 2 virtuelle Sprünge, da Flags und ein 32-Byte-Primage in das EOB zu codieren sind.