Warum ist der Ablauf des letzten Kanals in Lightning Network Routes anders?

Sowohl in den Dokumenten Basic of Lightning Technology ( BOLT ) als auch in der Spezifikation von lnd gibt es eine unterschiedliche Behandlung für den letzten Kanal in einer Route. In BOLT#2 bezieht es sich auf eine Variable min_final_cltv_expiry:

min_final_cltv_expiryist die minimale Differenz zwischen dem HTLC-CLTV-Timeout und der aktuellen Blockhöhe für den Terminalfall (C).

Dieser Wert ist 9, im Gegensatz zu 144 für cltv_expiry_delta.

Dies hängt höchstwahrscheinlich mit der Ausgabe einer Route zusammen, wenn lnd abgefragt wird. Nehmen Sie beispielsweise an, die Route Alice -> Bob -> Carol -> Dave wird von Alice weitergeleitet: Die Ausgabe lautet:

$> lncli-alice queryroutes --dest=<Carol_pubkey> --amt=5 --num_max_routes=1
total_time_lock: 1443640
total_fees: 1
total_amt: 6
hops {
  chan_id: <id_chan_alice_bob>
  chan_capacity: <cap>
  amt_to_forward: 6
  expiry: 1443610
  amt_to_forward_msat: 6000
  fee_msat: 1
}
hops {
  chan_id: <id_chan_bob_carol>
  chan_capacity: <cap>
  amt_to_forward: 5
  fee: 1
  expiry: 1443466
  amt_to_forward_msat: 5000
  fee_msat: 1000
}
hops {
  chan_id: <id_chan_carol_dave>
  chan_capacity: <cap>
  amt_to_forward: 5
  expiry: 1443466
  amt_to_forward_msat: 5000
}
total_fees_msat: 1001
total_amt_msat: 6001

Beachten Sie, dass die letzten beiden Hops denselben expiryWert haben. Warum unterscheidet sich der letzte Hop in Bezug auf den Ablauf?

Antworten (1)

Nach einigem Durchsuchen der BOLT -Dokumente und Gesprächen mit der Lnd- Slack - Community fand ich eine Antwort:

B->C. Wenn B 4.999.999 Millisatoshi direkt an C senden würde, würde es weder sich selbst eine Gebühr berechnen noch sein eigenes cltv_expiry_delta hinzufügen, also würde es das von C angeforderte min_final_cltv_expiry von 9 verwenden. Vermutlich würde es auch eine Schattenroute hinzufügen, um einen zusätzlichen CLTV von 42 zu erhalten. Darüber hinaus könnte es zusätzliche CLTV-Deltas bei anderen Hops hinzufügen, da diese Werte ein Minimum darstellen, aber der Einfachheit halber hier darauf verzichtet:

Obwohl cltv_expiry_deltader Standardwert in BOLT auf 9 eingestellt ist, lndverwenden sie 144, aber ohne den letzten Hop zu prüfen. Das heißt, sie fügen das nicht hinzu, final_cltv_expiryweil sie schon einen großen haben cltv_expiry(nehme ich an). Olaoluwa sagte in der Lücke, dass sie planen, den Wert von zu reduzieren cltv_expiry_delta, um näher an den in BOLT aufgeführten Standardwert heranzukommen. Wenn sie dies jedoch tun, hoffe ich, dass sie sich um das Hinzufügen des zusätzlichen kümmern cltv_expiry_delta, da es in diesem Fall wichtig sein wird, es hinzuzufügen. Ein Beispiel dafür, was ich meine, finden Sie unter dem oben verlinkten Link für BOLT #007