Автор: получатель гранта BitMEX Рене Пикхардт
Аннотация. Клапаны являются важным инструментом контроля потока в жидкостных или газовых системах. В этой статье мы изучаем возможности настройки «клапанов» в сети Lightning Network для улучшения контроля потока и снижения ожидаемой частоты сбоев платежей. Мы показываем, что продуманное сочетание асимметричных значений параметра `htlc_maximum_msat` на канале может значительно снизить ожидаемую частоту сбоев платежей. Мы предполагаем, что потенциальные преимущества тщательного выбора `htlc_maximum_msat` как «клапана» недостаточно используются операторами узлов пересылки платежей и поставщиками услуг в сети Lightning для оптимизации контроля потока и повышения надежности своих каналов. Мы анализируем возможности этих «клапанов» в сети Lightning Network математически с помощью марковских цепей, которые можно использовать для моделирования неопределенности с точки зрения ликвидности канала, возникающей из-за оттока средств в истощенных каналах. Используя эти методы, мы теоретически показываем, что правильное использование «клапанов» может статистически привести к повышению баланса платежных каналов, а ожидаемая частота сбоев платежей опустится ниже 3% (сейчас она превышает 10%). Мы представляем две идеи экспериментальных алгоритмов и призываем операторов узлов Lightning Network изучить возможности использования этого инструмента, который уже заложен в протокол.
Введение и мотивация
Как мы знаем, платежи в сети Lightning Network математически соответствуют потокам (минимальной стоимости), а у поставщиков услуг в Lightning Network ликвидность является основным драйвером для достижения достаточно высокого уровня обслуживания. Кроме того, хорошо известно, что платежные каналы часто истощаются. Это происходит, если в одном направлении нужно отправить больше сатоши, чем в противоположном (это явление обычно называют истощением или оттоком). Как мы уже писали в этом блоге, истощение платежных каналов и даже небольшой отток являются основной причиной прогнозируемой двузначной частоты сбоев платежей и снижения надежности сети.
В настоящее время операторы узлов Lightning Network занимаются управлением ликвидностью и пытаются уменьшить проблемы, возникающие из-за истощения каналов, главным образом с помощью двух стратегий:
- Пополнение истощенного канала. Известно несколько способов пополнения ликвидности. Оператор узла может произвести круговой платеж или выполнить обмен за пределами блокчейна. Кроме того, канал можно закрыть и снова открыть, или создать негласный параллельный теневой канал. Будущие усовершенствования протокола могут предусматривать возможность вливания свежей ликвидности в канал. Особенность всех этих механизмов в том, что они требуют от оператора узла больших затрат. Более того, в глобальном масштабе возможности проведения таких транзакций в блокчейне ограничены, поскольку место для блоков ограничено, а скачки перегруженности мемпула могут не только повысить затраты на такие стратегии, но и замедлить их реализацию.
- Уменьшение оттока/поиск сбалансированных каналов. Такие инструменты, как CLBOSS, пытаются адаптировать плату за пересылку платежей, которую взимает узел на своем канале, с учетом оттока средств. Суть этого метода сводится к экономическому аргументу: если на канале, которым управляет узел, наблюдается отток средств, значит, его ликвидность пользуется спросом, поэтому увеличение платы за пересылку платежей, с одной стороны, увеличит доход канала, а с другой стороны, потенциально снизит спрос и уменьшит отток. Следуя этой логике, разработчики протокола предлагают ввести отрицательную комиссию и различные тарифные карты. Также операторы прибегают к другим стратегиям — тщательно отбирают пиров и прогнозируют, где их ликвидность может быть востребована или расходоваться сбалансированно. Чтобы помочь операторам узлов в принятии решений, существуют целые системы рейтинга и оценки узлов.
В этой статье мы демонстрируем, что существует третья (и очень перспективная!) стратегия улучшения контроля потока (т.е. управления ликвидностью), которая уже заложена в протокол, а именно поле `htlc_maximum_msat` в сообщении `channel_update`. Мы показываем, что параметр `htlc_maximum_msat` может (и должен!) работать как клапан контроля потока. Мы рассматриваем последние правила использования каналов протокола gossip и отмечаем, что в настоящее время почти во всех каналах в поле `htlc_maximum_mset` выставлена или максимальная пропускная способность канала, или одинаковое значение в обоих направлениях. Мы показываем, что обе настройки нежелательны, так как усиливают истощение каналов с известным оттоком. Учитывая эту статистику, мы предполагаем, что на момент написания статьи почти ни один узел активно не использует возможности, которые мы предлагаем и обсуждаем в этой статье.
Мы начнем с цитаты из открытой (CC-BY-SA 4.0) статьи Википедии о клапанах, которая задает нужный тон и содержит меткие метафоры:
Клапан — это механизм или природный объект, который регулирует, направляет или контролирует поток жидкости […] путем открытия, закрытия или частичного перекрытия различных проходов. […] При открытом клапане поток жидкости направлен от более высокого давления к более низкому. […] Современные регулирующие клапаны могут регулировать давление или скорость потока ниже своего расположения и использоваться в сложных системах автоматизации. […] Клапаны имеют множество применений, включая управление водой для орошения, промышленное использование для управления процессами, бытовое использование, например, включение/выключение и регулирование давления в посудомоечных и стиральных машинах и кранах в доме.
Как клапан, параметр `htlc_maximum_msat` теоретически может значительного снизить ожидаемую частоту сбоев платежей в сети и способствовать созданию сбалансированных каналов.
Прежде чем продолжить объяснение того, как `htlc_maximum_msat` выполняет функцию регулирующего клапана, следует сделать важное замечание о сбалансированных каналах: принято считать, что платежный канал является сбалансированным, если 50% его ликвидности принадлежит каждому из пиров. Это не так. Мы показали, что каналы с соотношением ликвидности 50/50 нежелательны, и их практически невозможно как получить, так и обслуживать. Невольно вспоминается миф о Сизифе: вы заметите, как только баланс канала восстановится до уровня 50/50, возникает отток, и канал снова истощается. Таким образом, правильнее называть канал сбалансированным тогда и только тогда, когда распределение ликвидности близко к равномерному. Как показано на рисунке, распределение каналов с оттоком соответствует экспоненциальной кривой, что, конечно, далеко от равномерного распределения.
Использование параметра `htlc_maximum_msat` как клапана для уменьшения истощения ликвидности на платежных каналах с (высоким) оттоком средств
Вспомним цитату из Википедии: «Современные регулирующие клапаны могут регулировать давление или скорость потока». Эквивалентом давления для платежного канала будет отток средств. Мы определяем отток со стороны Алисы на ее общем с Бобом канале как часть платежей, которые Алиса должна переслать Бобу, от общего количества платежных запросов на канале. Значение оттока 0,9 означает, что если на канале будет 10 запросов на пересылку платежей, то в 9 из них Алиса должна будет переслать сатоши Бобу. При этом только 1 платежный запрос адресован Бобу, т.е. требует от него отправки сатоши Алисе. Ненадолго предположим, что все платежи одинакового размера. Очевидно, что из-за давления оттока большая часть ликвидности очень быстро окажется на стороне Боба. Это также приведет к тому, что Алиса не сможет выполнить большинство запросов на пересылку платежей. Это явление можно измерить, оно проявляется как высокая частота сбоев платежей на канале.
Поскольку мы относимся к оттоку средств на канале как к давлению, и знаем из собственного опыта, что поток в сети можно регулировать с помощью регулирующего клапана, мы должны найти такой клапан в сети Lightning Network. Если ожидается, что 9 из 10 платежей будут направлены Алисы к Бобу, то очевидная мера, которую Алиса может предпринять для снижения частоты сбоев платежей на канале, — это уменьшить размер платежей, которые она готова пересылать, и таким образом ограничить ликвидность, которая уходит из канала при выполнении запросов на пересылку платежей. Это можно сделать, установив меньшее значение параметра `htlc_maximum_msat` в `channel_update` в протоколе gossip (ограничения, возникающие при реализации этой стратегии, см. в разделе обсуждения). Это эффективно снижает пропускную способность канала в направлении от Алисы к Бобу. Точное значение будет определено в процессе работы или, как мы покажем, теоретически выведено на основе ряда предположений о распределении размера платежей. Если все сделать правильно, отток сохранится, но `htlc_maximum_msat` может стать более стабильным, и контролировать поток может быть проще, чем возиться с комиссией за пересылку платежей.
Далее мы приводим первое (насколько нам известно) математически обоснованное описание и анализ, объясняющие влияние и эффективность регулирующих «клапанов» в сети Lightning Network. Похоже, подавляющее большинство узлов в настоящее время игнорируют потенциал использования `htlc_maximum_msat` как регулирующего клапана, но мы отмечаем, что идея использования `htlc_maximum_msat` не нова. Некоторые операторы рассматривали идею использования параметра `htlc_maximum_msat`, чтобы сигнализировать о том, сколько ликвидности доступно или осталось на канале. Например, в протоколе gossip можно заметить, что на zerofeerouting есть периоды, когда на некоторых каналах очень низкое значение `htlc_maximum_msat`. Это ведет к практическому прекращению пересылки платежей на канале в направлении оттока средств (т.е. клапан закрывается), что позволяет каналу восстановиться до того, как клапан снова откроется. Возможно, эта мера контроля потока кажется радикальной, но основы для использования этого поля в качестве регулирующего клапана уже заложены.
Теперь, когда у нас есть мотивация и интуитивное описание, углубимся в математику платежного канала и изучим потенциал использования «клапанов» для улучшения контроля потока:
Марковский процесс для описания неопределенности в отношении ликвидности на платежном канале с известным оттоком.
Предположим, у нас есть канал между Алисой и Бобом с пропускной способностью `c`. Это означает, что в любой момент времени Алиса может иметь на канале ликвидность в размере 0,1,…,c-1 или c сатоши. Как обычно, для упрощения мы игнорируем резервы канала и соображения о HTLC-контрактах (Hash Time Lock Contracts, старт-контракты «со сроком годности»). Мы представляем сатоши, принадлежащие Алисе, как состояния конечного марковского процесса. Этот марковский процесс имеет c+1 состояния, так как ликвидность Алисы может иметь любое из этих значений.
Для простоты ненадолго предположим, что платежи в этом канале могут быть равны только 1 сатоши.
Если Алиса имеет `a` сатоши ликвидности, марковский процесс будет находиться в состоянии `a`. При этом отток средств в канале представляет сбой часть платежей, которые Алиса должна направить Бобу, от общего количества платежей, запросы на пересылку которых поступают на канал.
Это означает, что у нас есть следующие две вероятности перехода для любого значения a между 1 и c-1.
P(X=a-1| X=a)=1-d
P(X=a+1|X=a = d
Мы можем представить это наглядно с помощью следующей схемы:
Если бы канал имел бесконечную пропускную способность, мы могли бы смоделировать это изменение как случайное блуждание. Но в Lightning Network пропускная способность платежных каналов ограничена, поэтому мы должны рассмотреть, что происходит с марковской цепью, как только мы достигаем пределов (истощенного) канала. В этом случае платеж невозможно переслать, и состояние не меняется. В математическом выражении это выглядит так:
P(X = 0 | X = 0)= 1 – d
P(X = c | X = c) = d
Визуально для канала с пропускной способностью 5 это можно представить в виде следующей схемы.
Обратите внимание: единственное различие заключается в состоянии 0, где у Алисы нет сатоши (вероятность остаться в этом состоянии равна `1-d`), и состоянии `c=5`, где у Алисы есть `5` сатоши (вероятность остаться в этом состоянии равна величине оттока `d`).
Стационарное состояние и стационарный вектор марковского процесса
Главный вопрос, связанный с марковскими процессами, в том, насколько вероятно, что процесс будет находиться в том или ином состоянии, если он продолжается достаточно долго. Применительно к сети Lightning Network это переводится так: «Учитывая фиксированную величину оттока и пропускную способность канала и тот факт, что размер платежей равен 1 сатоши, насколько вероятно, что у Алисы в конечном итоге останется x сатоши ликвидности?».
Из математики мы знаем, что это можно довольно легко вычислить. Итак, предположим, что у нас есть векторное пространство размерности `c+1`, и базовым вектором в нем является каждое состояние марковского процесса (потенциальное значение ликвидности Алисы), и стохастическое представление, которое обозначается в виде матрицы переходов так, как описано выше. В результате мы получим следующую матрицу переходов для платежного канала пропускной способностью 5 сатоши.
Отметим, что это трехдиагональная матрица. Позже мы опишем, как при увеличении размеров платежей матрица станет прямоугольной (ленточной). Без формальных доказательств мы видим, что при значениях оттока, отличных от 0,5, марковский процесс должен не колебаться, а стабилизироваться в устойчивом (стационарном) состоянии. Легко (но очень проблематично с точки зрения вычислений) создать небольшую программу, которая моделирует очень высокие значения матрицы и оценивает вектор начального состояния, умноженный с учетом высокой величины матрицы. В результате получаем стационарное состояние, которое воплощает неопределенность, заложенную в распределении ликвидности.
В частности, этот марковский процесс приводит к такому же распределению ликвидности, как и моделирование ограниченных случайных блужданий, которые мы ранее использовали для оценки распределения ликвидности канала, как видно на следующей схеме:
Конечно, на практике можно использовать что-нибудь получше, чем этот наивный метод вычисления большой величины матрицы. Поскольку устойчивое состояние не изменяет вектор состояния `v` (который обозначает распределение ликвидности для Алисы), мы можем просто решить систему линейных уравнений `v= vM` при ограничении, что сумма всех компонентов `v` должна быть `1`. Это эквивалентно решению (MT- I)vT = 0. Полученный вектор `v` описывает в каждом компоненте, насколько вероятно наступления состояния марковского процесса.
Варьирование параметров марковского процесса
Мы определили 3 основных параметра марковского процесса:
- Пропускная способность канала, которая на 1 меньше, чем размерность векторного пространства.
- Отток канала, который соответствует вероятностям перехода.
- `htlc_maximum_msat` (и распределение размера платежей), который в приведенном выше примере мы установили на уровне 1.
Основным ограничением в нашем случае было то, что мы установили параметр `htlc_maximum_msat` равным 1 и разрешили платежи только в размере 1 сатоши. Эту проблему можно решить по-разному. Мы предлагаем одно достаточно разумное обобщение. Чтобы понять его суть, рассмотрим платеж в размере 2 сатоши и предположим, что разный размер платежей (1 сатоши и 2 сатоши) распределяется равномерно и, следовательно, запрашиваемый платеж может с одинаковой вероятностью может иметь размер 1 или 2 сатоши. Это предположение можно отбросить, спроектировав марковскую цепь по-другому. Например, в нашем коде мы также учитывали распределение zipf, поскольку более вероятно, что платежи имеют небольшой размер. В любом случае, чтобы показать, как все работает, проще всего объяснить концепции на примере равномерного распределения размера платежей.
Для известного значения оттока `d` и состояния `a` у нас есть две вероятности перехода:
P(X=a+1 | X = a) = d/2
P(X = a+2 | X = a) = d/2.
Это происходит потому, что в случае 2 сатоши мы посылаем или 1 сатоши, или 2, и обе эти вероятности должны в сумме давать значение оттока `d`.
В обратном направлении мы получаем:
P(X=a-1 | X = a) = (1-d)/2
P(X = a-2 | X = a) = (1-d)/2
Как и в случае с 1 сатоши, мы должны учитывать истощение канала. Поскольку мы допускаем платежи размером до 2 сатоши, это может произойти, например, в состоянии 0 и 1. Таким образом, мы получаем:
P(X = 0 | X = 0) = 1-d # платеж в размере 1 или 2 сатоши был запрошен в состоянии 0
P(X = 0 | X = 1) = (1-d)/2 # платеж в размере 1 сатоши был запрошен в состоянии 1
P(X = 1 | X = 1) = (1-d)/ 2 # платеж в размере 2 сатоши был запрошен в состоянии 1, и этот запрос не может быть осуществлен.
В результате получаем следующую схему:
Зададим q = (1-d) и еще раз посмотрим на матричное представление процесса:
Аналогичным образом мы могли бы создать более крупные цепочки для каналов с большей пропускной способностью или матрицы диапазонов с большим количеством лент для более высоких значений `htlc_maximum_msat`. В репозитории lnresearch на github можно найти блокнот с кодом, который может это сделать и вычислить соответствующие стационарные распределения.
В частности, мы можем задать разные значение `htlc_maximum_msat` в направлении оттока и противоположном направлении. Помните, в нашем примере с более высоким значением оттока мы хотим ограничить допустимый размер платежа в направлении пересылки. Теперь посмотрите на схему марковского процесса, в котором Алиса установила параметр `htlc_maximum_msat` равным 1. При этом у Боба этот параметр имеет значение 2, поскольку и Алиса, и Боб ожидают больше запросов на пересылку платежей для Алисы, чем для Боба, но хотят поддержать баланс канала и предотвратить его истощение:
Соответствующая матрица переходов выглядит следующим образом.
Конечно, мы можем обобщить эту схему, используя произвольные значения параметра `htlc_maximum_msat` для Алисы и Боба. Значение `htlc_maximum_msat` для Алисы обозначает, сколько диапазонов (лент) используется выше диагонали, а значение `htlc_maximum_msat` для Боба обозначает, сколько диапазонов (лент) используется ниже диагонали.
Используя известный отток, мы ищем марковский процесс, при котором минимизируется ожидаемый процент сбоев платежей в векторе устойчивого состояния на канале.
Хотя распределение размера платежей и его изменение при выборе значения `htlc_maximum_msat` можно узнать только в процессе эксплуатации узла и на основе фактических данных, мы продолжаем наши теоретические наблюдения. В следующем разделе мы рассмотрим, как вычислить ожидаемую частоту сбоев платежей.
Вычисление ожидаемой частоты сбоев платежей в платежных каналах с неопределенностью в отношении ликвидности (потенциально возникающей в результате оттока)
Когда у нас есть вероятностное распределение — которое можно или нельзя получить на основе модели истощения канала в результате оттока — обозначающее неопределенность в отношении ликвидности, мы можем вычислить вероятность сбоя платежа в размере `a`, используя следующую формулу:
частота_сбоев(a) = отток*P(X>c-a) + (1-отток)*P(X<a)
Эту формулу легко понять, если осознать, что платеж в размере `a` не пройдет в двух случаях.
- Если он пересылается в направления, противоположном направлению оттока, и на канале осталось меньше `a` сатоши ликвидности. Вероятность этого можно вычислить по формуле: (1-отток)*P(X<a).
- Если платеж пересылается в направлении оттока и партнер по каналу имеет больше `c-a` сатоши ликвидности. Вероятность этого можно вычислить по формуле `отток*P(X>c-a)`.
Сумма обеих вероятностей и будет ожидаемой частотой сбоев платежей в размере `a`, как описано выше.
Средняя ожидаемая частота сбоев — это усредненное значение по всем возможным значениям `a`, которое может взвесить, если мы предполагаем, что суммы распределены неравномерно. В любом случае размер платежей ограничен значением параметра `htlc_maximum_msat`, поэтому мы можем вычислить ожидаемую частоту сбоев платежей с помощью формулы:
This assumes the same `htlc_maximum_msat` in both directions and we can see how tЭто предполагает одинаковое значение `htlc_maximum_msat` в обоих направлениях, и мы видим, как ожидаемая частота сбоев платежей немного меняется, если изменить этот параметр. В частности, мы видим, что для минимизации ожидаемой частоты сбоев платежей при более сильном оттоке нужны более высокие значения `htlc_maximum_msat`.
Мы видим, что при увеличении параметра `htlc_maximum_msat` при заданном оттоке ожидаемая частота сбоев падает, когда мы увеличиваем `htlc_maximum_msat` до максимума, а затем снова начинает расти. Но можно отметить, что изменение значения `htlc_maximum_msat` поможет значительно снизить частоту сбоев разве что почти при полном отсутствии оттока.
Однако если предположить, что параметр `htlc_maximum_msat` имеет асимметричные значения, т.е. что Алиса задает в параметре `htlc_maximum_msat_A` максимальный размер платежей, который она готова пересылать, а Боб делает то же самое в параметре `htlc_max_size_B`, мы получим следующую формулу для расчета ожидаемой частоты сбоев платежей и двумерную оптимизационную задачу, в решении которой заинтересованы и Боб, и Алиса.
The motivation for studying this is quite simple. Assume you have a channel with a drain of 0.75 from A to B. This means that statistically 3 out of 4 payments go from A to B wМотивация для изучения этого вопроса довольно проста. Предположим, что у вас есть платежный канал с оттоком 0,75 из пункта A в пункт B. Это означает, что статистически из пункта A в пункт B проходят 3 из 4 платежей, и только один платеж проходит из пункта B в пункт A. Если операторы узлов ограничат возможность пересылки платежей определенного размера в направлении из пункта A в пункт B, уменьшив ее до части допустимой пропускной способности того, что разрешено направлять из пункта B в пункт A, то статистически канал останется сбалансированным и ожидаемая частота сбоев платежей уменьшится. Мы вычислили оптимальные сочетания значений параметра `htlc_maximum_msat` при значениях оттока до 0,95 и изобразили ожидаемую частоту сбоев платежей на следующем графике:
Мы видим, что при значениях оттока до 0,90 (то есть если 9 из 10 платежей пересылаются в одном направлении) ожидаемая частота сбоев платежей опустится ниже 3%. Это довольно существенное улучшение. Если предположить, что все значения оттока наблюдаются одинаково часто, то медианная частота сбоев составляет 2,18%. Это радикальное улучшение, если учесть, что это значение составляло 40,88%, когда канал использовал одно и то же значение параметра `htlc_maximum_msat` в обоих направлениях. Как и ожидалось, частота сбоев платежей резко возрастает, когда значения оттока приближаются к 1, и улучшение на среднем уровне не так существенно. Средняя ожидаемая частота сбоев платежей при любых значениям оттока составляет 5,43% при выборе оптимальных значений `htlc_maximum_msat` в обоих направлениях. Это ощутимое улучшение по сравнению с 43,1%, при равном значении `htlc_maximum_msat` в обоих направлениях.
Мы также видим, как распределение ликвидности становится гораздо ближе к равномерному распределению:
Если зеленая кривая становится более вогнутой при увеличении оттока, синяя кривая всегда остается ближе к равномерному распределению ликвидности и, следовательно, сбалансированному каналу и более низкому уровню сбоев платежей.
Конечно, к полученным результатам нужно относиться с осторожностью. Мы не знаем точных распределений размера платежей и того, как они изменятся, если операторы узлов начнут контролировать поток с помощью этого параметра. Это изменит марковскую модель и весовые коэффициенты в задаче оптимизации. Но даже используя другие параметры, мы наблюдали аналогичный результат. В частности, мы не рассматривали эту динамику в масштабах всей сети и пока не проверяли наши заключения на практике, но приглашаем операторов узлов сделать это и поделиться своим опытом или связаться с нами и вместе проверить наши выводы.
Похоже, что многие операторы узлов не знают о важности осознанного выбора значения параметра `htlc_maximum_msat`. На момент написания этой статьи 73,1% всех каналов используют одинаковое значение `htlc_maximum_msat` в обоих направлениях. Как уже говорилось в этой статье, это ведет к повышению частоты сбоев платежей и показывает, что у операторов узлов есть неиспользованный потенциал для улучшения контроля потока, повышения надежности сети и снижения ожидаемой частоты сбоев платежей.
Важное примечание: я часто критиковал разработчиков, которые использовали параметр `htlc_maximum_msat` вместо пропускной способности во время пересылки платежа для вычисления многослойности кандидатов. Думаю, что с точки зрения потока минимальной стоимости параметр `htlc_maximum_msat` следует использовать как показатель способности дуг в задаче потока минимальной стоимости при планировании платежей. Мы можем использовать фактическую пропускную способность (одинаковые слова, но разное значение!) канала для оценки функции затрат. При этом использование параметра `htlc_maximum_msat` в качестве ограничителя ликвидности канала при пересылке платежей и вычисления многослонойсти кандидатов имеет некоторые преимущества. Поэтому я прошу прощения у разработчиков, которых в прошлом за это критиковал.
Обсуждение: ограничения и возможности нашей модели
Представленная модель, как и любая другая, имеет ряд серьезных ограничений и недостатков и не соответствует реальности. Чтобы создать марковскую цепь, мы предполагаем, что нам известна величина оттока канала и распределение размеров платежей между 1 сатоши и значением `htlc_maximum_msat`. Хотя и то, и другое потенциально можно оценить во время использования узла, эти предположения могут динамически меняться. В частности, изменение значения `htlc_maximum_msat` может также привести к изменению этих предположений в нашей модели. Так что вы можете спросить: насколько полезна эта модель? В контролируемых условиях она помогает понять и определить влияние «клапанов» и сделать выводы об их потенциале. В конце нашего блокнота мы приводим 2 экспериментальных алгоритма, которые операторы узлов могут использовать для поиска подходящих значений `htlc_maximum_msat`. В частности, в одном из наших алгоритмов оператору узла не нужно создавать марковскую цепь. Суть в том, чтобы смоделировать распределение ликвидности в канале на основе последних 10 тыс. платежей и измерить, насколько это распределение далеко от равномерного. Как мы уже объясняли выше, если распределение далеко от равномерного распределения, это может указывать на наличие оттока и потенциальное истощение платежного канала. В таких случаях продуманный выбор значения `htlc_maximum_msat` может уменьшить это явление (как показывает марковская модель). Это особенно полезно, так как оператор узла знает распределение ликвидности последних тыс. платежей. Оператору не нужно знать пропускную способность канала или распределение размера платежей, чтобы измерить сигнал к изменению `htlc_maximum_msat`. Таким образом, хотя эта модель имеет типичные ограничения, она подсказывает операторам узлов простые стратегии, которые можно использовать для принятия нужных настроек.
Конечно, операторы узлов должны протестировать в основной сети, насколько эффективно изменение `htlc_maximum_msat` и действительно ли оно повышает надежность за счет снижения ожидаемой частоты сбоев платежей на их каналах. Из марковской модели видно, что меньшие значения `htlc_maximum_msat` дают меньшую дисперсию и, следовательно, меньшую ожидаемую частоту сбоев платежей. Конечно, в реальности это значение не стоит выставлять слишком низко. Поэтому операторам узлов, вероятно, придется пойти на некоторый компромисс. Хотя мы подозреваем, что сочетание значений параметров `htlc_maximum_msat` для каждого канала может быть довольно стабильным, неясно, как часто его нужно будет обновлять/изменять. Протокол gossip разрешает в среднем не более 4 изменений в день. Кроме того, некоторые люди, с которыми мы обсуждали идеи этой статьи, отметили, что это чревато проблемами с конфиденциальностью. Конечно, если операторы узлов начнут использовать параметр `htlc_maximum_msat` как «клапан» для контроля потока платежей, они тем самым будут косвенно сигнализировать об оттоке на своих платежных каналах, что может представлять интерес для узлов-конкурентов, ведь в этом случае они увидят, где может потребоваться ликвидность. В целом это скорее хорошо для надежности сети, но операторы узлов могут не захотеть давать своим конкурентам эту информацию. Если предположить, что это не проблема, отметим, что операторы каналов обоюдно заинтересованы найти оптимальное сочетание значений параметра `htlc_maximum_msat` на своем канале и адаптировать его во время работы, если поток платежей на канале меняется. Мы отмечаем, что выбор в пользу использования «клапанов» делает каждый канал, эту стратегию необязательно вводить в масштабах всей сети.
Предупреждение. Следует отметить, что согласно BOLT 7 семантика `htlc_maximum_msat` в настоящее время немного расплывчата. Bolt7 гласит: узел «ДОЛЖЕН учитывать htlc_maximum_msat при пересылке платежей». Но во многих реализациях сумма платежа каким-то образом разделяется и пересылается по частям за счет решения проблемы поиска маршрута для пересылки платежей в сети, где все каналы имеют высокое значение `htlc_maximum_msat`. Это, конечно, может привести к исключению каналов со слишком низким значением этого параметра, что в свою очередь частично устранит отток. Если бы в реализациях использовались стандартные решения задачи потока минимальной стоимости, они, скорее всего, принимали бы предложенную ликвидность и не влияли бы на отток. В теоретической модели это может привести к некоторой неточности, но мы полагаем, что при использовании представленных алгоритмов на практике это не будет проблемой.
Заключение
Мы увидели, что при известной величине оттока выбор асимметричного сочетания значения параметров `htlc_maximum_msat` может значительно снизить ожидаемую частоту сбоя платежей на канале. Ожидается, что повсеместное внедрение этого метода повысит общую надежность сети. При этом платежные каналы, использующие `htlc_maximum_msat` в качестве «клапана», часто более сбалансированные. Мы убедились, что даже в каналах с высоким оттоком распределение ликвидности ближе к равномерному распределению, чем в каналах без этой меры контроля потока. В интернете управление потоком осуществляется с помощью механизма «скользящего окна» Transmission Control Protocol, который решает некоторые проблемы надежности интернет-протокола. Параметр `htlc_maximum_msat` может вызвать аналогии с размером окна в TCP, но это собственный параметр Lightning Network, который позволяет улучшить контроль потока. Возможно, в Lightning Network существуют и другие собственные параметры для улучшения управления потоком. Возможно, они будут определены в будущем. И хотя мы надеемся, что операторы узлов начнут уже сегодня просто эгоистично регулировать параметр `htlc_maximum_msat`, следуя нашим алгоритмам, мы не можем не отметить, что для автоматизации процесса контроля потока на уровне протокола может потребоваться интерактивный протокол связи для определения оптимального сочетания значений `htlc_maximum_msat`.
От себя добавлю: те, кто внимательно следит за моей работой, знают, что в 2022 году, после описания модели истощения платежных каналов, я довольно критично и скептически относился к способности Lightning Network когда-нибудь достичь желаемых целей по уровню обслуживания. Но эти результаты вернули мне надежду на то, что реальный потенциал сети гораздо выше и что Lightning Network действительно может достичь желаемого уровня обслуживания. В любом случае я по-прежнему уверен, что нам нужен механизм для избыточных переплат, а также другие инструменты и механизмы для повышения надежности протокола.
Благодарность
Я выражаю благодарность Стефану Рихтеру за его ценный критический разбор ранних идей и версий этого текста, а также Андреасу Антонопулосу за идею расширить раздел мотивации и помощь в выборе подходящих аналогий для объяснения принципа контроля потока с помощью параметра `htlc_maximum_msat`. Отдельное спасибо zerofeerouting за то, что во время обсуждения предварительных результатов он сообщил мне, что уже использует `htlc_maximum_msat` как «клапан». Кристиан Декер и Ануан Риар также предоставили очень ценные отзывы и критику, за что я им очень благодарен. Наконец, я благодарен Summer of Bitcoin за возможность проводить исследовательские проекты; дискуссии с моими подопечными вдохновили меня на использование марковских цепочек для вычисления распределения ликвидности платежных каналов с оттоком средств. В этом контексте я благодарю Себастьяна Альшера за стилистическую корректуру. И, конечно же, я благодарен всем, кто поддерживает мои открытые исследования!