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

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

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

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

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

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

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

Ваш пробег может отличаться

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

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

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

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

Решение о том, какие каналы открыть

У Алекса Босворта есть некоторые подробные рекомендации в этом документе.

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

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

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

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

Я использовал инструмент сопоставления узлов, чтобы выяснить, какие узлы больше всего увеличат мою связь. Тем не менее, я бы еще раз предостерег от слепого открытия каналов для тех, кто занимает самые высокие места. Прежде чем открыть канал с одним из рекомендуемых узлов, я проверяю его на терминале Lightning, чтобы убедиться, что он стабилен. Затем я проверяю это на 1ML, чтобы увидеть, устанавливают ли они разумную политику оплаты.

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

По моему опыту, большинство узлов с «высокой степенью связанности» с 500+ каналами, как правило, нестабильны и, следовательно, не маршрутизируют много платежей. Я подозреваю, что они слишком сильно нагружают свое оборудование. Однако другие сообщили о другом опыте — YMMV!

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

Если вы не можете позволить себе 10 млн спутниковых каналов, я бы все равно предложил минимум 1 млн спутников. Мой узел переслал 400 платежей за последние несколько месяцев, и средняя сумма пересылки составила 420 000 сатов — около 150 долларов. таким образом, вам понадобится почти идеально сбалансированный канал 1M SAT, чтобы иметь возможность пересылать один средний платеж. Надеемся, что динамика изменится, поскольку все больше и больше кошельков начнут использовать многоканальные платежи.

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

minchansize=1000000

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

$ lncli openchannel —node_key 03b428ba4b48b524f1fa929203ddc2f0971c2077c2b89bb5b22fd83ed82ac2f7e1 —local_amt 16000000 —sat_per_vbyte 1
[lncli] Ошибка RPC: code = Unknown desc = получена ошибка финансирования от 03b428ba4b48b524f1fa929203ddc2f0971c2077c2b89bb5b22fd83ed82ac2f7e1: err=channel rejected

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

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

Экономия комиссий за открытие канала в сети за счет пакетного открытия

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

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

  1. В Electrum Desktop перейдите в «Инструменты» > «Настройки», на вкладке «Транзакции» активируйте «Предварительный просмотр». Затем в разделе «Инструменты» откройте диалоговое окно «Платить многим».
  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 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 «плати многим».
  4. В Electrum вставьте этот список в диалоговое окно pay-to-many, сохраните транзакцию, нажмите «Оплатить», установите как можно более низкую фиксированную комиссию в зависимости от текущих условий мемпула. Убедитесь, что RBF НЕ отмечен. Затем нажмите «Завершить» и «Подписать» его с помощью своего аппаратного кошелька (или кошелька Electrum, если он не использует аппаратный кошелек), но НЕ транслируйте его! Этим займется balanceofsatoshi.
  5. После завершения и подписания скопируйте подписанную необработанную транзакцию, вставьте ее в интерфейс командной строки и нажмите «Enter». Через несколько секунд или минут bos отобразит идентификатор транзакции. Затем вы можете использовать собственный обозреватель блоков вашего узла, чтобы проверить статус пакетной транзакции.

Открытие каналов с двойным финансированием

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

(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

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

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

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

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

Сделка по ребалансировке имеет экономический смысл только в том случае, если потенциальная прибыль — альтернативные издержки — прямые затраты > 0.

Разочаровывающая вещь, которую я быстро обнаружил, была… Ребалансировка обычно того не стоит. Кажется, что < 5% моих попыток ребалансировки заканчиваются с помощью этого инструмента.

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

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

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

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

Совет от профессионала: После запуска ребалансировок каждые 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 ошибки и, вероятно, занесут ваши каналы или узел в черный список на несколько часов. Также желательно уменьшить трафик сплетен в сети.

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

min_fee_ppm = 2

max_fee_ppm = 200

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

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

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

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

Вы также можете использовать эти услуги, чтобы открыть канал и либо открыть взаимный канал обратно, либо вернуть средства в цепочке:

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

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

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

Если вы являетесь пользователем balanceofsatoshis, bos упрощает выход из петли с помощью

BOS увеличивает входящую ликвидность —сумма <сат> —с помощью <pubkey>

Имейте в виду, что один из этих обменов обычно занимает час.

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

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

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

Петля молнии

Я надеялся, что получить входящую ликвидность через сервис 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 также должен быть довольно прост в настройке, хотя я не уверен, действительно ли это необходимо для узла маршрутизации. Я не решаюсь настроить автоциклирование, потому что большинство ручных циклов, которые я пытаюсь, не завершаются.

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

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

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

Узел Lightning Loop

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

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

Затем узел LOOP закрыл мой канал на скорости 2,5 сат/б (244 сат) — предположительно потому, что он был настолько несбалансированным, что сервер петли был непригоден для получения большего количества средств. Из того, что я слышал, у них есть автоматическое закрытие, когда ваш локальный баланс составляет 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, установить на нем высокие комиссии за маршрутизацию, чтобы он не истощался, а затем использовать узел для дешевого зацикливания входящей ликвидности, потому что вам не придется платить комиссию за маршрутизацию.

Высвобождение застрявшего капитала

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

Нет особого смысла блокировать средства в каналах, если эти средства не используются. К счастью, 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 —Fee-days 60 —Sort fee_earnings

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

Результаты

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

$ БОС форварды —завершено —дней 90

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

$ БОС чарты-сборы-заработанные

Тем не менее, я потратил 31 897 сатоши на онлайн-сборы.

$ BOS Chart-Chain-Fees

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

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

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

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

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

Другие соображения / случайные мысли

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

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

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

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

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

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

Максимальный размер канала, не относящегося к вумбо, составляет 16,7 млн сат. По моему опыту, попытка маршрутизировать платежи на сумму более 4 млн спутников, как правило, проблематична. Помните, что максимальная сумма разового платежа по умолчанию составляет чуть более 4 млн сатов. Даже если этот предел стоимости платежа будет снят, и все каналы будут идеально сбалансированы и будут иметь максимальную пропускную способность, это сделает максимально возможную оплату 8,3 млн сат.

У доктора Карстена Отто есть масса полезных заметок на его веб-сайте в https://c-otto.de/

Движение вперед

Оснастка для узлов молнии продолжает развиваться; Хотя это руководство, вероятно, устарело по-разному, я поддерживаю обновленные списки инструментов управления узлами и инструментов ликвидности на своем веб-сайте.

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

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

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

bos send <key> —message=»Эй, что случилось?»

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

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

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

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

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

Источник