Как в документах Basic of Lightning Technology ( BOLT ), так и в спецификации lnd последний канал в маршруте обрабатывается по-разному. В BOLT#2 это относится к переменной min_final_cltv_expiry:
min_final_cltv_expiry— минимальная разница между тайм-аутом HTLC CLTV и текущей высотой блока для терминального случая (C).
Это значение равно 9, а не 144 для cltv_expiry_delta.
Это, скорее всего, связано с выводом маршрута при запросе lnd, например, предположим, что маршрут Алиса -> Боб -> Кэрол -> Дэйв, маршрутизируется от Алисы: вывод:
$> 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
Обратите внимание, что последние два прыжка имеют одинаковое expiryзначение. Почему срок действия последнего прыжка отличается?
После некоторого поиска в документах BOLT и общения с сообществом lnd slack я нашел ответ:
Б->С. Если бы B отправил 4 999 999 миллисатоши непосредственно в C, он не взимал бы с себя комиссию и не добавлял бы свою собственную cltv_expiry_delta, поэтому он использовал бы запрошенный C min_final_cltv_expiry, равный 9. Предположительно, он также добавил бы теневой маршрут, чтобы получить дополнительный CLTV, равный 42. Кроме того, он может добавить дополнительные дельты CLTV на других прыжках, поскольку эти значения представляют минимум, но здесь он не делает этого для простоты:
Кроме того, хотя cltv_expiry_deltaв BOLT по умолчанию установлено значение 9, в lndних используется 144, но без проверки конечного прыжка. То есть они не добавляют, final_cltv_expiryпотому что они уже большие cltv_expiry(я полагаю). Олаолува сообщил, что они планируют уменьшить значение cltv_expiry_delta, чтобы приблизиться к значению по умолчанию, указанному в BOLT. Однако, если они это сделают, я надеюсь, что они позаботятся о добавлении дополнительных cltv_expiry_delta, так как это будет важно добавить в этом случае. Для примера того, что я имею в виду, проверьте приведенную выше ссылку для БОЛТА № 007.