Рекомендации по маршрутизации

При расчете маршрута для HTLC необходимо учитывать как cltv_expiry_delta, так и плату: cltv_expiry_delta влияет на время, когда средства будут недоступны в случае сбоя в худшем случае. Связь между этими двумя атрибутами неясна, так как зависит от надежности задействованных узлов.

Если маршрут вычисляется путем простой маршрутизации к предполагаемому получателю и суммирования cltv_expiry_deltas, тогда промежуточные узлы могут угадать свою позицию в маршруте. Знание CLTV(CheckLockTimeVerify) HTLC, топологии окружающей сети и cltv_expiry_deltas дает злоумышленнику возможность угадать предполагаемого получателя. Поэтому крайне желательно добавить случайное смещение к CLTV, которое получит предполагаемый получатель, что влияет на все CLTV на маршруте.

Чтобы создать правдоподобное смещение, исходный узел МОЖЕТ начать ограниченную случайную прогулку по графику, начиная с предполагаемого получателя и суммируя cltv_expiry_deltas, и использовать полученную сумму в качестве смещения. Это эффективно создает расширение теневого маршрута к фактическому маршруту и ​​обеспечивает лучшую защиту от этого вектора атаки, чем просто выбор случайного смещения.

Другие более сложные соображения включают в себя диверсификацию выбора маршрута, чтобы избежать единичных точек отказа и обнаружения, а также для балансировки локальных каналов.


Пример маршрутизации

Рассмотрим четыре узла:

   В
  / \
 /   \
A     C
 \   /
  \ /
   D

Каждый рекламирует следующий cltv_expiry_delta в конце каждого канала:

    A: 10 блоков
    Б: 20 блоков
    C: 30 блоков
    D: 40 блоков

C также использует min_final_cltv_expiry 9 (по умолчанию) при запросе платежей.

Кроме того, у каждого узла есть установленная схема оплаты, которую он использует для каждого из своих каналов:

    A: 100 базовая + 1000 millionths (пропорционально сумме платежа)
    B: 200 базовая + 2000 millionths
    C: 300 базовая + 3000 millionths
    D: 400 базовая + 4000 millionths

Сеть увидит восемь сообщений channel_update:

    A-> B: cltv_expiry_delta = 10, fee_base_msat = 100, fee_proportional_millionths = 1000
    A-> D: cltv_expiry_delta = 10, fee_base_msat = 100, fee_proportional_millionths = 1000
    B-> A: cltv_expiry_delta = 20, fee_base_msat = 200, fee_proportional_millionths = 2000
    D-> A: cltv_expiry_delta = 40, fee_base_msat = 400, fee_proportional_millionths = 4000
    B-> C: cltv_expiry_delta = 20, fee_base_msat = 200, fee_proportional_millionths = 2000
    D-> C: cltv_expiry_delta = 40, fee_base_msat = 400, fee_proportional_millionths = 4000
    C-> B: cltv_expiry_delta = 30, fee_base_msat = 300, fee_proportional_millionths = 3000
    C-> D: cltv_expiry_delta = 30, fee_base_msat = 300, fee_proportional_millionths = 3000

В-> С. Если бы B должен был отправить 4 999 999 миллисатоши непосредственно в C, он бы не взимал с себя плату и не добавлял свой собственный cltv_expiry_delta, поэтому он использовал бы запрошенный у min_final_cltv_expiry из 9. Предположительно, он также добавил бы теневой маршрут, чтобы дать дополнительный CLTV из 42. Кроме того, он может добавить дополнительные дельты CLTV в других переходах, так как эти значения представляют минимум, но решаем не делать этого здесь для простоты:

    amount_msat: 4999999
    cltv_expiry: current-block-height + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

А-> В-> С. Если A должен был отправить 4 999 999 миллисатоши на C через B, ему необходимо заплатить B плату, указанную в B-> C channel_update, рассчитанную согласно платам HTLC:

    fee_base_msat + (amount_to_forward * fee_proportional_millionths / 1000000)

200 + (4999999 * 2000/1000000) = 10199

Точно так же необходимо добавить B_> C channel_update cltv_expiry (20), запрошенный C min_final_cltv_expiry (9) и стоимость теневого маршрута (42). Таким образом, сообщение update_add_htlc A-> B будет выглядеть так:

    amount_msat: 5010198
    cltv_expiry: current-block-height + 20 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

Update_add_htlc B-> C будет таким же, как и прямой платеж B-> C выше.

А-> D-> С. Наконец, если по какой-то причине A выберет более дорогой маршрут через D, сообщение update-add_htlc для A-> D будет выглядеть так:

    amount_msat: 5020398
    cltv_expiry: current-block-height + 40 + 9 + 42
    onion_routing_packet:
        amt_to_forward = 4999999
        outgoing_cltv_value = current-block-height + 9 + 42

И D-> C update_add_htlc снова будет таким же, как и прямой платеж B-> C выше.

Сообщение обновления информации о канале (сплетни).

После того, как канал был первоначально объявлен, каждая сторона независимо объявляет размер комиссии и минимальную дельту истечения срока действия , которая требуется для ретрансляции HTLC (врЕменных блокировок для прохождения платежей) через этот канал. Каждая из сторон использует 8-байтовый короткий идентификатор канала, который соответствует channel_announcement и 1-битному полю channel_flags, чтобы указать, на каком конце канала он находится (в начале или в конце канала). Узел может делать это многократно, чтобы изменять плату за использование канала.

Обратите внимание, что сообщение о "сплетне" channel_update полезно только в контексте ретрансляции платежей нодами, и не нужны для отправки платежей. При совершении платежа A -> B -> C -> D используются только channel_updates (сплетни), относящиеся к каналам B -> C (объявлен B) и C -> D (объявлен C). При построении маршрута, суммы и сроки действия для блокировок каналов (HTLC) должны быть рассчитаны в обратном направлении от пункта назначения к источнику. Точное начальное значение для amount_msat и минимальное значение для cltv_expiry, которое будет использоваться для последней HTLC (блокировке) в маршруте, указаны в запросе на оплату (см. БОЛТ № 11).

    тип: 258 (channel_update)
    данные:
        [64: signature]
        [32: chain_hash]
        [8: short_channel_id]
        [4: временная метка]
        [1: message_flags]
        [1: channel_flags]
        [2: cltv_expiry_delta]
        [8: htlc_minimum_msat]
        [4: fee_base_msat]
        [4: fee_proportional_millionths]
        [8: htlc_maximum_msat] (option_channel_htlc_max)

Битовое поле channel_flags используется для указания направления канала: оно идентифицирует узел, с которого произошло это обновление, и сигнализирует о различных параметрах, касающихся канала. В следующей таблице указано значение отдельных битов:

Позиция            Название          Значение
0                  direction         направление, к которому относится это обновление.
1                  disable           отключить канал.

Битовое поле message_flags используется для указания наличия дополнительных полей в сообщении channel_update:

Позиция бита    Имя                                  Поле
0               option_channel_htlc_max              htlc_maximum_msat

Обратите внимание, что поле htlc_maximum_msat является статическим в текущем протоколе на протяжении всего срока службы канала: оно не предназначено для указания пропускной способности канала в реальном времени в каждом направлении, что может быть как массовой утечкой данных, так и бесполезным спамом в сети ( для распространения каждой сплетни требуется в среднем 30 секунд на один переход)

Node_id для проверки подписи берется из соответствующего channel_announcement: node_id_1, если младший значащий бит флагов равен 0, или node_id_2 в противном случае.

Требования

Исходный узел:

    МОЖЕТ создать channel_update для передачи параметров канала равноправному каналу, даже если канал еще не был объявлен (то есть бит анонса_канала не был установлен).
        НЕ ДОЛЖЕН пересылать такой channel_update другим партнерам по причинам конфиденциальности.
        Примечание: такое channel_update, которому не предшествует channel_announcement, недопустимо для любого другого однорангового узла и будет отброшено.
    ДОЛЖЕН установить подпись для подписи двойного SHA256 всего оставшегося пакета после подписи, используя свой собственный идентификатор_узла.
    НЕОБХОДИМО установить chain_hash AND short_channel_id, чтобы соответствовать 32-байтовому хешу И 8-байтовому идентификатору канала, который однозначно идентифицирует канал, указанный в сообщении channel_announcement.
    если исходный узел является node_id_1 в сообщении:
        ДОЛЖЕН установить бит направления channel_flags в 0.
    иначе:
        ДОЛЖЕН установить бит направления channel_flags в 1.
    если присутствует поле htlc_maximum_msat:
        ДОЛЖЕН установить бит option_channel_htlc_max в message_flags равным 1.
        ДОЛЖЕН установить для htlc_maximum_msat максимальное значение, которое будет отправлено через этот канал для одного HTLC.
            ДОЛЖЕН установить это значение меньше или равно пропускной способности канала.
            ДОЛЖЕН установить это значение меньше или равным max_htlc_value_in_flight_msat, полученному от однорангового узла.
            для каналов с chain_hash, идентифицирующих цепочку биткойнов:
                ДОЛЖЕН установить это значение менее 2 ^ 32.
    иначе:
        ДОЛЖЕН установить бит option_channel_htlc_max в message_flags равным 0.
    ДОЛЖНЫ установить биты в channel_flags и message_flags, которым не присвоено значение 0.
    МОЖЕТ создать и отправить channel_update с битом отключения, установленным в 1, чтобы сигнализировать о временной недоступности канала (например, из-за потери соединения) ИЛИ постоянной недоступности (например, до расчета по цепочке).
        МОЖЕТ послать последующее channel_update с битом отключения, установленным в 0, чтобы повторно включить канал.
    ДОЛЖЕН установить временную метку больше 0, а больше, чем любая ранее отправленная channel_update для этого short_channel_id.
        СЛЕДУЕТ основывать метку времени на метке времени UNIX.
    ДОЛЖЕН установить для cltv_expiry_delta количество блоков, которое будет вычтено из входящего HTLC cltv_expiry.
    ДОЛЖЕН установить для htlc_minimum_msat минимальное значение HTLC (в миллисатосах), которое будет принимать одноранговый канал.
    ДОЛЖЕН установить в fee_base_msat базовую плату (в миллисатоши), которую он будет взимать за любой HTLC.
    ДОЛЖЕН установить fee_proportional_millionths на сумму (в миллионных долях сатоши), которую он будет взимать за каждую переведенную сатоши.
    НЕ ДОЛЖЕН создавать избыточные channel_updates

Принимающий узел:

    если short_channel_id НЕ соответствует предыдущему channel_announcement, ИЛИ, если канал был закрыт в это время:
        НЕОБХОДИМО игнорировать channel_updates, которые НЕ соответствуют одному из его собственных каналов.
    СЛЕДУЕТ принимать channel_updates для своих собственных каналов (даже если они не являются общедоступными), чтобы узнать параметры пересылки связанных исходных узлов.
    если подпись не является действительной подписью, используется node_id двойного SHA256 всего сообщения, следующего за полем подписи (включая неизвестные поля после fee_proportional_millionths):
        НЕ ДОЛЖЕН обрабатывать сообщение дальше.
        ДОЛЖЕН разорвать соединение.
    если указанное значение chain_hash неизвестно (то есть оно не активно в указанной цепочке):
        НЕОБХОДИМО игнорировать обновление канала.
    если отметка времени НЕ больше, чем отметка последнего полученного channel_update для этого short_channel_id И для node_id:
        ДОЛЖЕН игнорировать сообщение.
    иначе:
        если временная метка равна последнему полученному channel_update И поля (кроме подписи) отличаются:
            МОЖЕТ занести в черный список этот node_id.
            МОЖЕТ забыть все каналы, связанные с ним.
    если отметка времени необоснованно далека в будущем:
        МОЖЕТ отказаться от channel_update.
    иначе:
        СЛЕДУЕТ помещать в очередь сообщение для ретрансляции.
        МОЖЕТ выбрать НЕ для сообщений длиннее минимальной ожидаемой длины.
    если бит option_channel_htlc_max для message_flags равен 0:
        ДОЛЖЕН считать, что htlc_maximum_msat не присутствует.
    иначе:
        если htlc_maximum_msat отсутствует или превышает емкость канала:
            МОЖЕТ занести в черный список этот node_id
            СЛЕДУЕТ игнорировать этот канал при рассмотрении маршрута.
        иначе:
            СЛЕДУЕТ учитывать htlc_maximum_msat при маршрутизации.

Обоснование

Поле метки времени используется узлами для упрощения channel_updates, которые либо слишком далеки в будущем, либо не были обновлены в течение двух недель; поэтому имеет смысл, чтобы это была временная метка UNIX (т.е. секунды с UTC 1970-01-01). Это не может быть жестким требованием, учитывая возможный случай двух channel_updates в течение одной секунды.

Явный флаг option_channel_htlc_max, указывающий на наличие htlc_maximum_msat (вместо того, чтобы иметь htlc_maximum_msat, который подразумевает длину сообщения), позволяет нам расширять channel_update различными полями в будущем. Поскольку ширина каналов ограничена 2 ^ 32-1 миллисатосами, htlc_maximum_msat имеет такое же ограничение.

Рекомендация против избыточных channel_updates сводит к минимуму спам в сети, однако иногда это неизбежно. Например, канал с одноранговым узлом, который недоступен, в конечном счете заставит channel_update указать, что канал отключен, с другим обновлением, повторно включающим канал, когда одноранговый узел восстанавливает контакт. Поскольку сообщения о сплетнях группируются и заменяют предыдущие, результатом может быть одно, казалось бы, избыточное обновление.

  {
            "timestamp": "1552233536",
            "chan_id_in": "619577002455324672",
            "chan_id_out": "617503563405152257",
            "amt_in": "80001",
            "amt_out": "80000",
            "fee": "1",
            "fee_msat": "1080"
        }

lightning-cli getroute 028314f021602092779aedd4ef39f3b5809f9b6046f8bc28359b16e659ab1dcd7c 50000000000 1                                
{ "route" : 
        [ 
                { "id" : "028314f021602092779aedd4ef39f3b5809f9b6046f8bc28359b16e659ab1dcd7c", "channel" : "508082:728:1", "msatoshi" : 2755359744, "delay" : 9 } ] }