В видео (28:25) с официального сайта Lightning описывается многоскачковая оплата. Я понимаю, что такое контракт с блокировкой по хешу, но я все еще не понимаю, зачем нам нужен аспект блокировки по времени. Как вы видите на слайде, в многошаговом платеже A -> B -> C -> D, (A -> B) имеет 3-дневный nLockTime, (B -> C) имеет 2-дневный nLockTime, и (C -> D) имеет 1-дневный nLockTime. nLockTime времени t означает, что транзакция не может быть включена в блок раньше, чем t. Итак, с течением времени сначала становится действительным (C -> D), затем становится действительным (B -> C), затем (A -> B) становится действительным.
Джозеф Пун говорит в 28:35 (выделено мной):
«Канал Дэйва и Кэрол [...] закрывается первым. И Кэрол довольна такой установкой, потому что она знает, что ее платеж закрывается [...] до того , как ее деньги будут сняты».
Разве не наоборот: сначала Дэйв берет деньги у Кэрол (между 1 и 2 днем), а затем Кэрол берет деньги у Боба?
В любом случае, что будет не так, если мы вообще избавимся от таймлоков? Скажем, Дейв генерирует случайный R, отправляет H(R) Алисе, Алиса создает транзакцию с блокировкой хеша и транслирует ее Дэйву через Боба и Кэрол. Если Дэйв раскроет R, все смогут вывести свои средства, если нет — никто. Зачем нам еще нужны таймлоки?
Я использую следующий сценарий для обоих вопросов: Алиса хочет заплатить 1 BTC Дейву по маршруту: Алиса -> Боб -> Кэрол -> Дэйв.
Предположим, что маршрут оплаты только что установлен. Значение: каждый переход на маршруте (A, B, C, D) имеет HTLC с соседними узлами. Однако у HTLC не будет временных замков. Теперь Дэйв отправляет секрет R Кэрол, которая, в свою очередь, отправляет R Бобу. Однако Боб не отвечает (например, из-за сбоя его узла). К сожалению, Алиса понятия не имеет, почему Боб не посылает ей R. Так что ей приходится ждать, пока Боб снова не станет отзывчивым. Это может занять час, несколько дней, несколько недель или, может быть, он больше никогда не ответит. Проблема Алисы в том, что HTLC между ней и Бобом действует бессрочно. Таким образом, без временной блокировки деньги, выделенные на этот HTLC, могут застрять на очень длительный срок, и Алиса ничего не может с этим поделать.
Уменьшающие временные блокировки полезны для промежуточных прыжков (всех прыжков, кроме первого и последнего). В нашем примере маршрут таков:
A -> B -> C -> D
Таким образом, B и C являются промежуточными прыжками. Теперь, согласно HTLC, промежуточный переход может потребовать деньги от предыдущего перехода и должен заплатить деньги следующему переходу. Например: Кэрол может потребовать деньги от Боба и должна заплатить деньги Дейву.
Вообще говоря, это означает: переход «HOP» должен убедиться, что после следующего перехода «NEXT» затребованы деньги от HOP, HOP сможет потребовать деньги от предыдущего перехода «PREV» до HTLC между PREV и HOP. недействителен (время истекло). И простой способ сделать это — убедиться, что временная блокировка HTLC между HOP и NEXT (значительно) ниже, чем между HOP и PREV.
Вот пример того, что может произойти, если все HTLC будут иметь одинаковую временную блокировку. Для этого примера мы предполагаем, что временная блокировка составляет «T + 10 блоков» (T = фиксированный номер блока). Таким образом, когда высота блока составляет T+10 блоков или позже, все HTLC «превышают время ожидания» и:
Теперь после того, как маршрут оплаты был установлен, происходит следующее:
После задержки (на T+8 блоков) Дэйв отправляет секрет R Кэрол. Сделав это, он доказал Кэрол, что может (законно) требовать деньги от их HTLC. Поскольку обе стороны пока не хотят закрывать свой канал, вместо этого они соответствующим образом обновляют состояние канала. Сделав это, Кэрол только что безвозвратно заплатила деньги Дэйву.
Однако Кэрол еще не получила денег от Боба. Поэтому она посылает R Бобу. Но Боб не отвечает! Это неудачно для Алисы, так как через 2 блока (~ 20 минут) Боб может вернуть свои деньги! Чтобы предотвратить это, Кэрол должна немедленно закрыть канал с Бобом, передав транзакцию-обязательство, содержащую HTLC. В то же время она также должна отправить еще одну «транзакцию доставки», которая (намеревается) фактически перевести деньги из HTLC (между ней и Бобом) себе. Однако, к сожалению, нет гарантии, что обе транзакции действительно попадут в следующий блок (T+9). Но если только HTLC включен в блок T+9, Боб может транслировать свою собственную «транзакцию доставки», которая (намеревается) перевести деньги из уже подтвержденного HTLC (через «путь тайм-аута» вывода) на себя. Итак, теперь в мемпуле есть две «транзакции доставки», которые используют один и тот же HTLC-выход. Как известно, двойные траты недопустимы. Таким образом, только одна из этих транзакций будет включена в последующий блок. И если транзакция Боба будет включена, Алиса потеряет свои деньги.
Сказав все это, я думаю, что технически также можно было бы выполнять многошаговые платежи без доверия без уменьшения временных блокировок. Но эту концепцию, вероятно, гораздо проще реализовать и поддерживать.
Сергей Тихомиров