Руководство по управлению ликвидностью в сети Lightning
Cover

Руководство по управлению ликвидностью в сети Lightning

7 августа 2021 г.

Джейсон Лопп: уроки, полученные при управлении узлом маршрутизации в сети Lightning.

Перевод статьи Джемесона Лоппа подготовлен Тони⚡️. Поддержать проект.

С тех пор как люди начали запускать узлы Lightning в mainnet в начале 2018 года, некоторые задавались вопросом: какую реальную прибыль можно ожидать от размещения капитала в маршрутизационной ноде? Ник Бхатия подробно описал свою теорию возможных вариантов развития событий:

The Time Value of Bitcoin and LNRR

Но, как мы узнали за эти годы, ROI (возврат инвестиций/прибыль от инвестиций) включает в себя гораздо больше, чем просто вложение капитала в каналы Lightning.

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

Я следовал процессу, описанному в моем предыдущем блог посте, поясняющем как создать свой узел, функционирующий исключительно через Tor:

Tor-Only Bitcoin & Lightning Guide

Запустить программное обеспечение было проще простого. Далее мне нужно было понять, как наиболее эффективно разместить свой капитал.

Ваша прибыль может варьироваться #

К сожалению, невозможно написать руководство, которое предоставило бы простые инструкции в стиле: “Подключитесь к этим узлам и получайте комиссионные”. Необходимо рассматривать Lightning Network как конкурентный рынок, предлагающий эффективное передвижение капитала. Как и в случае с определенной торговой стратегией, если все начнут прибегать к одним и тем же техникам, все преимущества, присущие этой стратегии, исчезнут, и это создаст возможности для других участников торговать против нее. Если все будут строить одни и те же мосты для перемещения капитала, это превратится в гонку на износ в конкуренции за комиссионные, и для других операторов будет разумнее “противодействовать” этой стратегии, строя мосты в другом месте.

Множество переменных #

Вы, наверное, заметили, что эта статья получилась очень длинной. Причина тому — наличие множества различных вопросов, которые необходимо учитывать при эксплуатации узла Lightning Network с целью максимизации маршрутизации. К ним относятся:

  • Размещение капитала
  • Комиссии за маршрутизацию
  • Минимизация ончейн-комиссий
  • Ваша общая входящая/исходящая емкость
  • Поддержание пропускной способности маршрутизации (ребалансировка / Submarine Swaps)
  • Входящая / исходящая емкость пользователей
  • Безотказность / время работы / здоровье узлов
  • Безотказность / нагрузка / сетевое подключение вашего узла

Принятие решения по открытию каналов #

Алекс Босворт предоставляет подробное руководство в этом документе.

Открыть каналы Lightning очень просто — подавляющее большинство узлов в сети примут входящий канал практически любой емкости. Таким образом, есть опасность заблокировать капитал у плохо функционирующего узла, который не обрабатывает значительного количества платежей. А если ваш пир (держатель узла, с которым вы открыли канал) перестает отвечать, закрытие канала может привести к тому, что ваш капитал окажется в бездействии на несколько недель.

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

Что бы вы ни делали, избегайте использования автопилота lnd; он просто подключается к крупным популярным узлам. Аналогично, похоже, что многие просто заходят на Lightning Terminal или 1ML и подключаются к узлам с самым высоким рейтингом. Это может звучать нелогично, но такая стратегия не является выигрышной, если вы хотите, чтобы ваш узел направлял большое количество платежей. Скорее, вы должны стремиться к созданию новых мостов, связывая между собой узлы, которым в противном случае пришлось бы совершить много хопов (перенаправлений/прыжков) для маршрутизации друг к другу.

Еще одна проблема, с которой я сталкивался, — это использование оценки BOS для решения с какими узлами открывать каналы. Алекс Босворт, который написал алгоритм подсчета баллов, сказал мне, что он не был задуман как система подбора узлов маршрутизации/оценки качества.

Я использовал инструмент подбора узлов (node match tool), чтобы выяснить, какие узлы больше всего повысят мою центрированность. Однако я бы еще раз предостерег от слепого открытия каналов с узлами, получившими наивысший рейтинг. Прежде чем открыть канал с одним из рекомендованных узлов, я проверяю его на Lightning Terminal, чтобы убедиться в его стабильности. Затем я проверяю его на 1ML, чтобы убедиться, что они устанавливают разумную политику комиссионных сборов.

Чтобы получить альтернативный взгляд на то, как повысить центрированность узла, я использовал скрипт Gridflare “improve centrality” от lndpytools. Он, конечно, не так удобен в использовании, как другие веб-инструменты, так как требует получения полного дампа сетевого графа с вашего узла, переноса его на настольный компьютер / ноутбук, а затем запуска анализа на этом json-файле.

Мой опыт подсказывает, что большинство “высокосвязанных” узлов с 500+ каналами, как правило, нестабильны и поэтому не направляют много платежей. Я подозреваю, что они слишком сильно нагружают свое оборудование. Однако другие пользователи сообщают о другом опыте — ваша прибыль может варьироваться!

Если вы можете себе это позволить, не создавайте каналы размером менее 10M (миллионов) сат. Имейте в виду, что максимальный размер платежа по умолчанию составляет чуть более 4M сат. Поэтому, если вы хотите иметь возможность поддерживать каналы, которые могут маршрутизировать максимальный размер платежа в любом направлении, вам нужно, по крайней мере, удвоить этот объем, а лучше еще сильнее его увеличить, поскольку довольно сложно иметь достаточно входящей ликвидности и достаточно исходящей ликвидности на обеих сторонах канала. Если вы не пытаетесь управлять узлом маршрутизации, это не так важно. Также можно быть узлом маршрутизации больших объемов платежей с меньшими каналами — скорее всего, вам придется делать больше ребалансировок — но все же желательно, чтобы пропускная способность вашего канала была как можно выше.

Если вы не можете позволить себе каналы в 10М сат, я бы посоветовал минимум 1М сат. Моя нода переслала 400 платежей за последние несколько месяцев, и средняя сумма пересылки составила 420,000 сат — около $150. Таким образом, вам потребуется почти идеально сбалансированный канал в 1М сат, чтобы иметь возможность переслать один средний платеж. Надеюсь, динамика изменится, когда все больше и больше кошельков начнут использовать многоходовые (multi-path) платежи.

В lnd вы можете предотвратить входящие каналы меньше определенного размера, введя следующую строку в lnd.conf:

minchansize=1000000

Не все узлы позволят вам открыть с ними канал, и они не объяснят, почему отклоняют ваш запрос на открытие. Например, я попытался открыть канал с узлом Zap и получил отказ, даже когда я попробовал максимальный (по умолчанию) размер канала.

$ lncli openchannel --node_key 
03b428ba4b48b524f1fa929203ddc2f0971c2077c2b89bb5b22fd83ed82ac2f7e1 --local_amt 16000000 --sat_per_vbyte 1  
[lncli] rpc error: code = Unknown desc = received funding error from 03b428ba4b48b524f1fa929203ddc2f0971c2077c2b89bb5b22fd83ed82ac2f7e1: err=channel rejected

Перед открытием канала необходимо попытаться определить, какова будет политика маршрутизации контрагента. Например, LNBIG имеет довольно высокие комиссии 175ppm — какой смысл платить за входящую ликвидность на ваш узел, если люди будут избегать его использования из-за высоких комиссий?

Некоторые узлы имеют абсурдно высокие комиссии за маршрутизацию; например, я заметил, что на узлах OKEX и OKCoin базовая комиссия установлена на уровне 1М сатоши — $400! Я говорил об этом с генеральным директором OKCoin, и он сказал, что это сделано специально, чтобы препятствовать маршрутизации; я предложил им изменить конфигурацию, чтобы просто отклонять открытие входящих каналов.

Экономия на ончейн-комиссиях за открытие канала с помощью сгруппированных открытий (Batch Opens) #

Если вы запускаете новый узел, вам будет необходимо открыть много каналов. Рассмотрите вариант сгруппированных/пакетных открытий каналов с помощью командной строки:

Пакетное открытие транзакции с помощью balanceofsatoshi (bos) и Electrum Desktop. Ниже приведено краткое описание процесса, но этот шаг включает в себя ончейн-транзакцию и, следовательно, возможную потерю средств, если вы допустите ошибку. На сайте Джестофера есть подробное руководство: http://satbase.org/bos-open/.

  1. В Electrum Desktop перейдите в Tools > Settings, во вкладке “Transactions” активируйте “Advanced preview”. Затем в Tools откройте диалоговое окно “Pay to many”.

  2. На вашем узле, как пользователь bos, в интерфейсе командной строки введите следующую команду:

    bos open <node pubkey 1> --amount <channel size in sats 1> <pubkey 2> --amount <channel size 2> <pubkey 3> --amount <channel size 3> <pubkey 4> --amount <channel size 4> <pubkey 5> --amount <channel size 5> <pubkey 6> --amount <channel size 6>

    После нажатия Enter запустится счетчик на 10 минут, и вам нужно будет выполнить шаги с 3 по 5 в течение этих 10 минут. Следите за тем, чтобы не использовать Ctrl+C после запуска таймера! Если вы хотите отменить процесс и таймер, просто нажмите Enter в интерфейсе командной строки.

  3. Не вводите никаких других команд в CLI, а просто скопируйте вывод команды ‘bos open’, который будет представлять собой список ончейн-адресов и сумму в биткоинах через запятую. Этот формат совместим с опцией Electrum ‘pay to many’.

  4. В Electrum вставьте этот список в диалоговое окно pay-to-many, сохраните транзакцию, нажмите ‘Pay’, установите фиксированную комиссию как можно ниже, основываясь на текущих условиях мемпула. Убедитесь, что флажок RBF НЕ установлен. Затем нажмите ‘Finalize’ и ‘Sign’, используя ваш аппаратный кошелек (или кошелек Electrum, если не используете аппаратный кошелек), но НЕ транслируйте транзакцию! Это сделает balanceofsatoshi.

  5. После того, как транзакция будет финализирована и подписана, скопируйте подписанную необработанную транзакцию, вставьте ее в интерфейс командной строки и нажмите ‘Enter’. Через несколько секунд или минут bos отобразит идентификатор транзакции (transaction ID). Затем вы можете использовать собственный блокчейн-эксплорер узла для проверки статуса вашей пакетной транзакции.

Открытие каналов с взаимным финансированием #

Если у вас есть друг, который готов с вами сотрудничать, вы можете немного сэкономить на ребалансировке/циклировании, инициализировав уже сбалансированный канал. Ознакомьтесь с необходимыми шагами для Алисы и Боба, использующими bos CLI:

(NODE 1: Bob)

(0) Run: bos open-balanced-channel

(1) enter remote node public key

(2) enter full channel size

(3) enter fee rate

Open a new terminal window.

(4) Run: bos fund --fee-rate <fee> <address> <amount in sats>

Copy the signed_transaction and go back to 1st window and paste

(5) paste the signed_transaction to bos prompt in 1st window  
  

(NODE 2: Alice)

(0) Run: bos open-balanced-channel (it should see the request from node1 at this point)

(1) agree with funding rate (y/n)

Open a new terminal window.

(2) Run: bos fund --fee-rate <fee> <address> <amount>

Copy the signed_transaction and go back to 1st window and paste

(3) paste the signed_transaction to bos prompt in 1st window

(4) hit enter and this should work.  

check via: lncli pendingchannels

Ребалансировка каналов #

В некоторых случаях у меня не получалось ребалансировать канал из-за недостаточной ликвидности. Если вы заметили, что канал никогда не удается ребалансировать и он никогда не используется для маршрутизации средств, вы можете рассмотреть вариант его закрытия и распределения капитала в другом месте.

Перед ребалансировкой каналов вы должны убедиться, что в этом есть экономический смысл. В противном случае вы просто попадете в петлю постоянной ребалансировки каналов, поскольку они редко остаются идеально сбалансированными. Слепая ребалансировка в поисках идеального баланса почти наверняка в конечном итоге обойдется вам дороже из-за комиссионных, чем вы заработаете на маршрутизации платежей. К счастью, в ‘bos’ есть опция –dryrun, позволяющая узнать, какой будет комиссия.

Вы можете использовать bos для автоматической ребалансировки, но для того, чтобы убедиться, что вы не проводите неэкономичную ребалансировку, вам нужно установить вашу максимальную ставку комиссии на минимальную ставку комиссии / 2. Вы можете добиться этого, добавив следующую строку в /etc/crontab:

*/10 * * * *     jameson /path/to/bos rebalance --max-fee-rate 5

В конце концов я наткнулся на инструмент rebalance-lnd Карстена Отто. Мне нравится этот инструмент для ребалансировки, потому что он делает дополнительный шаг в определении того, имеет ли данный маршрут ребалансировки экономический смысл.

Вот как рассчитывается экономическая целесообразность ребалансировки:

Допустим, у вашего узла есть два канала, для которых необходимо оценить ребалансировку — один на Bitfinex с 10M сат на вашей стороне и ставкой комиссии 1,000 ppm. У вашего узла также открыт канал с LOOP и взимает 5,000 ppm за пересылку средств. К сожалению, ваша сторона канала практически пуста.

Возможно, хорошей идеей будет перебросить средства с канала Bitfinex на канал LOOP. Если вы сделаете это для ребалансировки 4M сат, это будет означать следующее:

  1. После ребалансировки останется 6M сат, которые можно будет в последующем протолкнуть на сторону Bitfinex. Вы не заработаете 4M * 1,000 ppm = 4,000 сат за перевод средств, которые вы вывели со своей стороны канала в рамках ребалансировки в LOOP. Это цена упущенной возможности, которую вы заплатили.
  2. Вы также должны оплатить все транзакционные издержки ребалансировки; это ваши прямые издержки.
  3. Если вам повезет, вы сможете отправить эти 4M sat в LOOP и заработать 4M * 5,000 ppm = 20,000 sat. Это ваш потенциальный будущий доход.

Транзакция ребалансировки имеет экономический смысл только в том случае, если потенциальный заработок превышает сумму альтернативных издержек и прямых затрат.

Но я быстро обнаружил следующий недостаток: ребалансировка обычно не стоит того. Похоже, что менее 5% моих попыток ребалансировки выполняются таким образом.

Я установил cronjob для запуска случайной ребалансировки каждые 5 минут, добавив следующую строку в /etc/crontab:

*/5 * * * *     jameson /path/to/rebalance.py --to -1

На моем узле открыто несколько десятков каналов, но в любой момент времени только около 25% из них нуждаются в ребалансировке, согласно инструменту rebalance-lnd, который по умолчанию пытается сохранить по крайней мере 1M сат на каждой стороне канала. Эти значения по умолчанию вряд ли будут оптимальными для вашей ситуации. Запуская случайную попытку ребалансировки каждые 5 минут, я ожидаю, что каждый канал, нуждающийся в ребалансировке, будет пытаться ребалансироваться дважды в час.

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

Pro Tip: После того, как я в течение недели запускал ребалансировку каждые 5 минут, я узнал, что она заполняет различные панели управления тоннами неоплаченных счетов с истекшим сроком действия. Чтобы снизить эффект этой проблемы, я предлагаю установить следующие две конфигурации lnd:

gc-canceled-invoices-on-startup=true  
gc-canceled-invoices-on-the-fly=true

Управление политикой канала #

В конце концов, я наткнулся на charge-lnd, который является инструментом для автоматического динамического изменения платы за маршрутизацию на моих каналах. Стоит отметить, что это далеко не идеальный инструмент, потому что, к сожалению, мы можем устанавливать только исходящие комиссии для каналов. Это ограничение протокола Lightning, а не инструмента; вы можете прочитать больше о дебатах по поводу поддержки платы за входящие каналы в этой теме на github.

Первоначально, в течение первых нескольких месяцев работы, я установил все тарифные политики для каналов:

base_fee_msat: 5000  
fee_ppm: 2000

Эти тарифы на порядок выше, чем по умолчанию; я просто хотел посмотреть, клюнут ли пользователи сети. Однако мой узел лишь изредка направлял средства с такими комиссиями. Предположительно, либо мои комиссии были слишком высокими, либо мой узел был плохо расположен на сетевом графике.

Позже я установил следующую конфигурацию для charge-lnd:

[proportional]  
chan.min_ratio = 0  
chan.max_ratio = 1  
strategy = proportional  
base_fee_msat = 1000  
min_fee_ppm = 10  
max_fee_ppm = 2000

И установил cronjob для ежечасного запуска charge-lnd, добавив следующую строку в /etc/crontab:

0 * * * *     jameson /path/to/charge-lnd -c /path/to/charge.config

В течение 48 часов после включения этого динамического управления политиками я увидел, что мой узел начал маршрутизировать больше платежей.

Вы не должны запускать этот скрипт чаще, чем раз в час, поскольку эти обновления распространяются относительно медленно (1 минута на хоп/прыжок), и если вы будете менять тарифы слишком часто, удаленные узлы, которые решат маршрутизировать через вас, будут часто получать ошибки FEE_INSUFFICIENT и, возможно, занесут ваши каналы или узел в черный список на несколько часов. Также желательно уменьшить трафик сплетен (gossip traffic) в сети.

Через пару месяцев я все еще наблюдал только спорадическую маршрутизацию, поэтому я изменил значения комиссий на:

min_fee_ppm = 2  
max_fee_ppm = 200

Стоит отметить, что использование динамического менеджера политики каналов несколько противоречит логике, используемой инструментом rebalance-lnd — он предполагает, что плата за канал останется неизменной в обозримом будущем, когда рассчитывает альтернативную стоимость, которую вы платите, перемещая ликвидность. Например, если rebalance-lnd использует текущую комиссионную ставку вашего канала, чтобы решить, когда проводить ребалансировку, а charge lnd меняет ставки комиссии, rebalance-lnd примет решение, которое имеет смысл для него при ставке комиссии A, но позже может появиться charge lnd и изменить ставку комиссии на B, что сделает логику rebalance-lnd для ставки комиссии A недействительной. Похоже, что rebalance-lnd должен знать конфигурацию charge lnd и исторический поток средств через канал, чтобы лучше предсказать будущий доход от комиссии.

Покупка входящей ликвидности #

Получение (и поддержание) входящей ликвидности — одна из самых больших проблем в работе узла маршрутизации.

По состоянию на 5 июля 2021 года стоимость покупки максимального количества входящей ликвидности (16,7 млн сат / $5,650) для канала через определенные сервисы составляет:

  • Bitrefill: 199,021 сат / $67
  • Y’alls: 150,000 сат / $50.44
  • LNBIG: 24,101 сат / $8.30
  • Loop: 26,165 сат / $8.81
  • Pool: неизвестно (аукционы проводятся вслепую)

Вы также можете использовать следующие сервисы для открытия канала и получения ответного канала или получения средств ончейн:

Эти методы требуют доверия к сервису в возврате средств. Решение, требующее меньшего доверия, заключается в использовании функции bos dual-funded channel open (двустороннее открытие канала), о которой говорилось ранее, хотя для этого необходимо найти контрагента, который достаточно подкован, чтобы использовать balanceofsatoshis CLI.

Если у вас есть аккаунт на бирже, которая поддерживает депозиты Lightning, вы можете отправить на биржу, а затем выполнить вывод средств ончейн, увеличив таким образом свою входящую ликвидность. Несколько лет назад я проводил презентацию о важности подключения бирж к Lightning Network для повышения ликвидности в сети.

Наконец, вы можете использовать различные каналы связи для координации обмена ликвидностью.

Если вы являетесь пользователем balanceofsatoshis, bos упрощает процесс обмена ликвидностью с помощью функции

bos increase-inbound-liquidity --amount <sats> --with <pubkey>

Имейте в виду, что каждый такой своп обычно занимает час.

Однако стоит отметить, что нет никаких гарантий, когда речь идет о входящей ликвидности. Контрагенты по каналу всегда могут закрыть канал, если решат, что их капитал распределен не лучшим образом!

Исключением является Lightning Pool, в котором вы заключаете контракт на покупку ликвидности на определенный срок, и эта продолжительность фактически обеспечивается на уровне блокчейна. Согласно их whitepaper:

Надеюсь, в ближайшем будущем мы также получим встроенные объявления о ликвидности, доступные на уровне протокола.

Lightning Loop #

Я надеялся, что получать входящую ликвидность через сервис Lightning Loop будет проще и безопаснее, чем доверять различным сторонним сервисам. Настроить loopd и использовать loop в командной строке оказалось невероятно просто.

$ ./loop quote out -v 16777215  
Send off-chain: 16777215 sat  
Receive on-chain: 16759995 sat  
Estimated on-chain fee: 338 sat  
Loop service fee: 16882 sat  
Estimated total fee: 17220 sat  
No show penalty (prepay): 30000 sat

Похоже, что Autoloop также должен быть довольно прост в настройке, хотя я не уверен, что он действительно необходим для узла маршрутизации. Я не решаюсь установить автолупинг (autolooping), потому что большинство лупов, производящихся вручную (manual loops), которые я пытаюсь сделать, не завершаются успехом.

Сложность в создании лупов для получения входящей ликвидности заключается в том, что:

  1. Это должно быть сделано для довольно большой суммы, чтобы ончейн-комиссия оправдала себя.
  2. Чем большую сумму вы пытаетесь вывести, тем сложнее найти путь для перенаправления средств оффчейн.

Подавляющее большинство моих попыток вывести большие объемы потерпели неудачу из-за проблем с lightning-маршрутизацией. Например, мой узел в течение 20 минут пытался найти способ направить 4М сат с узла Blockstream. Я подозреваю, что у них не так много исходящей ликвидности; поскольку это магазин, где большая часть ликвидности, вероятно, направлена в его сторону, как на получателя платежей.

Узел Lightning Loop #

В качестве теста я открыл канал с узлом LOOP, за что я заплатил 1 sat/b (154 sat) ончейн-комиссии.

В течение 5 часов по этому каналу было переслано 11 платежей, которые израсходовали 98% моей исходящей емкости на LOOP. Я заработал чуть более 3 000 сатоши в виде комиссии.

Затем узел LOOP закрыл мой канал с комиссией 2,5 сат/б (244 сат). Предположительно потому, что он был настолько несбалансированным, что у сервера loop не было возможности получить больше средств. Насколько я слышал, у них есть автоматическое закрытие, когда ваш локальный баланс составляет 20% или ниже. Я получил 2,600 сат; звучит довольно неплохо, да?

LOOP, похоже, перерабатывает тонну каналов; из 48 каналов, открытых на момент написания статьи, их средний возраст составляет 16 дней, и, похоже, он закрывает от 5 до 10% открытых каналов каждый день.

Далее я попробовал открыть большой канал с LOOP, для которого я установил очень высокую ставку комиссии в 1%, чтобы посмотреть, не клюнет ли кто-нибудь.  

lncli updatechanpolicy --base_fee_msat 5000 --fee_rate 0.01 --time_lock_delta 18 --chan_point <UTXO>

Мне также пришлось обновить конфигурацию “charge”, чтобы она игнорировала этот канал и не снижала плату автоматически.

[loop]  
node.id = 021c97a90a411ff2b10dc2a8e32de2f29d2fa49d41bfbb52bd416e460db0747d0d  
strategy = ignore

Через несколько дней, когда не было проведено ни одного платежа, я уменьшил комиссию в два раза и заметил, что платежи стали редко, но поступать. Возможно, позже я попробую повторить этот эксперимент с каналом wumbo.

Однако Алекс Босворт отметил, что это не будет простым циклом открытия каналов с большими объемами “под копирку” с узлом LOOP. Почему? Потому что каждый раз, когда вы это делаете, расходуется общая входящая ликвидность, поступающая в остальную часть сети по всем остальным вашим каналам. Итак, представьте, что у вашего узла в общей сложности 10М сат входящей ликвидности, а вы открываете каналы на 1М с узлом LOOP. Вы сможете повторить это только около 10 раз, прежде чем вы потеряете возможность направлять средства на узел LOOP.

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

Высвобождение незадействованного капитала #

Некоторые пиры никогда не маршрутизируют средства, потому что они нестабильны, поэтому я бы закрыл канал с ними — как мне казалось, что держать их открытыми — пустая трата капитала и бесполезное зондирование маршрутов. Но если пир не реагировал, когда я собирался закрыть канал, проводилось принудительное закрытие, в результате чего капитал оставался заблокированным более недели.

Нет особого смысла в блокировании средств в каналах, если эти средства не используются. К счастью, bos также позволяет довольно легко определить, от каких пиров стоит отказаться.

bos remove-peer --dryrun --idle-days 90 --fee-rate 5 --active

Также имеет место проблема пиров, которые слишком часто находятся оффлайн, что препятствует регулярному перенаправлению средств.

bos remove-peer --dryrun --idle-days 30 --fee-rate 5 --offline

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

Однако, если вы собираетесь закрыть канал, вы можете попытаться использовать этот капитал для ребалансировки некоторых других каналов.

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

bos peers --fee-days 60 --sort fee_earnings

Результаты этой команды также покажут вам, какие каналы, вероятно, стоит ребалансировать (те, которые приносят много комиссии за маршрутизацию).

Результаты #

После того, как я хорошо сбалансировал каналы, я подождал несколько недель, чтобы посмотреть, много ли я заработал на комиссиях.

$ bos forwards --complete --days 90

На дюжине каналов я заработал 17,025 сатоши в виде комиссии за маршрутизацию.

$ bos chart-fees-earned

Однако я потратил 31,897 сатоши на ончейн-транзакции.

$ bos chart-chain-fees

После еще одного месяца жонглирования моим узлом по выходным, переключения десятков каналов и добавления автоматики:

Стоит отметить, что почти половина из 60,000 сатоши, которые были выплачены в качестве ончейн-комиссий, пришлась на одно принудительное закрытие канала. Это принудительное закрытие стоило более 100 сатоши за виртуальный байт, в то время как его можно было быстро подтвердить, заплатив около 5 сатоши за виртуальный байт. Оглядываясь назад, я думаю, что этого можно было бы избежать, если бы я был терпелив и подождал, пока этот пир вернется в сеть, прежде чем закрывать канал. Если бы не эта невынужденная ошибка, я, вероятно, заработал бы больше на оффчейн-комиссиях, чем потратил на ончейн-транзакции на сегодняшний день. Похоже, это распространенная проблема.

С другой стороны, якорные каналы (anchor channels) должны решить эту проблему, чтобы вам не приходилось полагаться на старые и завышенные комиссионные ставки. Начиная с lnd 0.13.0 вновь созданные каналы используют якоря по умолчанию; вам просто нужно убедиться, что у вас есть ~100,000 сат в своем ончейн-кошельке для использования в качестве комиссионного резерва.

Что касается оффчейн-комиссий, я рад видеть, что, хотя мои комиссии в ppm теперь ниже, я провожу транзакции более постоянно. За последние 90 дней я собирал в среднем 500 сат в день, а за последние 10 дней — 1,000 сатоши.

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

Мысли вслух #

До обновления до lnd v0.13 мой (исключительно Tor) узел не мог подключаться к узлам IPV4, что значительно ограничивало мои возможности по развертыванию капитала. Если вы используете узел, работающий только через Tor, вы должны понимать, что вы будете в невыгодном положении, когда дело дойдет до получения входящей ликвидности от узлов, не работающих на Tor.

Как оператор, вы должны ориентироваться не только на балансы отдельных каналов, но и на общее соотношение входящей и исходящей ликвидности вашего узла. Например, если у вас 100М сат исходящей ликвидности, но только 10М сат входящей, большая часть этой исходящей ликвидности бесполезна. Получение входящей ликвидности — одна из самых больших проблем, с которой я столкнулся, даже после выполнения множества loop out’ов.

Код алгоритма Lightning Terminal Web закрыт; трудно сказать, сколько средств можно ему доверить. Кроме того, он будет считать ваш узел нестабильным, если время его безотказной работы будет ниже 99,9% — с этой точки зрения, запуск узла маршрутизации через домашнее интернет-подключение без регулярного резервного копирования вряд-ли является лучшей идеей. Забавно, но я заметил проблемы с надежностью у некоторых случайных пользователей, с которыми я переписывался в Telegram-группах, которые запускали свои узлы на Raspberry Pi дома. Исходя из моего личного опыта эксплуатации узлов Raspberry Pi дома в течение многих лет, я бы посоветовал купить мощный ИБП и подключить к нему модем, маршрутизатор и узел. И ничего больше. Поскольку все эти устройства потребляют довольно мало энергии, используя достойный ИБП, вы сможете поддерживать узел в режиме онлайн более часа, а то и дольше.

Если вы хотите попытаться улучшить свой показатель Lightning Terminal, ознакомьтесь с данным инструментом, который проводит обратную инженерию: https://lnrouter.app/scores/terminal.

Запуск других служб на вашем узле может быть проблематичным. Несмотря на то, что мой узел был мощным (16 ядер и 16 ГБ оперативной памяти), я заметил, что когда я запускал на нем сервер electrum и нагрузка на оборудование в среднем превышала 1,0, Lightning Terminal начинал сообщать, что мой узел “нестабилен”.

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

Максимальный размер не-wumbo канала составляет 16.7М сат. По моему опыту, попытки маршрутизации платежей размером более 4M сат обычно вызывают проблемы. Помните, что по умолчанию максимальное значение одиночного платежа составляет чуть более 4М сат. Даже если ограничение на величину платежа будет снято, и все каналы будут идеально сбалансированы и иметь максимальную емкость, это поднимет максимальный возможный платеж до 8.3М сат.

Доктор Карстен Отто имеет массу полезных заметок на своем веб-сайте https://c-otto.de/.

Что дальше? #

Существует еще много возможностей для совершенствования инструментов, которые помогают операторам узла Lightning лучше понять управление ликвидностью и маршрутизацию.

Хотелось бы видеть более наглядные визуализации каналов, по которым пересылаются платежи. Thunderhub, например, может создавать струнные диаграммы, чтобы визуализировать эту активность; я надеюсь, что больше программного обеспечения для панелей управления Lightning начнет делать это автоматически.

Было бы здорово, если бы вы могли легко отправлять сообщения операторам узлов-ровесников, чтобы спросить, как дела, или узнать их намерения. Теоретически вы можете использовать keysend для отправки им платежа в 1 сатоши со встроенным сообщением, но нет никакой гарантии, что оператор узла когда-либо увидит его. Для этого можно использовать “bos send”.

bos send <key> --message="hey what's up?"

С отправкой сообщений есть небольшая проблема. Операторы узлов могут не замечать их, потому что они не используют Thunderhub или не настроили канал Telegram для отправки сообщений bos, поэтому другие операторы узлов не утруждают себя отправкой сообщений, так как они могут быть пропущены.

Рене Пикардт и Стефан Рихтер опубликовали работу, в которой показали, что поиск оптимальных маршрутов значительно усложняется, если базовая плата не установлена на 0: https://arxiv.org/abs/2107.05322

Я видел множество операторов, устанавливающих базовую плату своей ноды на 0, но я подозреваю, что это ошибочное решение, которое практически ничего не улучшит на момент написания статьи — это теоретическая оптимизация, от которой ноды начнут получать выгоду, только если разработчики действительно реализуют алгоритм нахождения пути, предложенный Рене и Стефаном.

Кроме того, в статье не обсуждаются другие компромиссы, такие как введение векторов DoS. Подумайте, что когда ваш узел принимает HTLC для маршрутизации сат, узел должен сохранять данные, связанные с этим HTLC, в своей базе данных. Таким образом, если ваша базовая комиссия равна 0, то кто-то может направить миллионы миллисатоши через ваш узел, не заплатив за это высокую цену. Однако, в грандиозной схеме потенциальных атак это может быть мелочью по сравнению с другими известными проблемами, такими как griefing и вымогательство, которые позволяют злоумышленнику бесплатно заблокировать много средств.

Также было бы здорово, если бы кто-нибудь создал инструмент для визуализации входящей/исходящей ликвидности вашего узла и входящей/исходящей ликвидности всех узлов-аналогов. Это несколько сложно выяснить (в силу самого дизайна сети Lightning), но, возможно, есть способ приблизительно оценить эти показатели с помощью тщательно построенного зондирования маршрута.

Если вы дочитали это эссе до конца, поздравляем! Надеюсь, теперь вам ясно, что Lightning Network — это целый новый мир, который нам предстоит не только изучить, но и построить.

Спасибо Алексу Босворту, Эрин Мэлоун и доктору Карстену Отто за рецензии и отзывы.

Connect to our relay to leave a comment. Details.
Подключитесь к нашему релею, чтобы оставить комментарий. Подробнее.