Warum enthalten Lightning-Pakete Kanal-IDs, wenn die Weiterleitung nicht strikt ist?

Die Onion-Pakete in Lightning, wie in BOLT 4 beschrieben , enthalten short_channel_id's der Kanäle entlang der vom Sender konstruierten Route. Aber gemäß der gleichen Spezifikation ist die Weiterleitung nicht strikt , was bedeutet, dass, wenn die Zahlung von einem Zwischenknoten X zu einem Zwischenknoten Y weitergeleitet werden soll, X frei ist, einen der Kanäle zwischen ihm und Y zu wählen (a Knotenpaar kann mehrere Kanäle haben).

short_channel_idIst das in Zwiebelpäckchen nicht übertrieben? Könnten wir einfach eine Liste von Knoten entlang der vorgeschlagenen Route angeben und jeden Knoten den besten Kanal zum nächsten auswählen lassen?

Antworten (1)

Ich denke, das hat historische Gründe. Die kurzen Kanal-IDs waren zuerst im Zwiebelformat vorhanden. C Lightning unterstützt auch heute noch nicht mehrere Kanäle zwischen 2 Knoten. Lnd hingegen schon. Aus diesem Grund begannen lnd-Entwickler, den Kanal zu wechseln, wenn ein zweiter Kanal mit ausreichender Balance zwischen den Knoten vorhanden war. Später wurde vereinbart, die Aussage über die nicht strikte Weiterleitung - auf die Sie sich bezogen haben - in die Spezifikation aufzunehmen.

Während das Arbeiten mit Knoten-IDs funktionieren würde, hat es einige Nachteile.

  1. Wir müssten eine abwärtskompatible Änderung des Zwiebelformats vornehmen
  2. Kurze Kanal-IDs verbrauchen weniger Speicherplatz, ich denke 8 Byte im Vergleich zu 33 Byte NodeIDs (denken Sie daran, dass die Zwiebeln nur 65 Byte pro Hop-Nutzlast haben).
  3. Bei privaten Kanälen können kurze Kanal-IDs verifiziert werden. Ich kann die Blockchain auf eine nicht ausgegebene Finanzierungstransaktion überprüfen.