В данном материале подробно описывается практический опыт касательно запуска, настройки и оптимизации узла маршрутизации в Lightning Network. Ещё с начала 2018 года, с тех пор, как энтузиасты начали запускать узлы в основной сети Lightning, у некоторых из них возник резонный вопрос: какой отдачи стоит ожидать от инвестиций в виде размещения капитала в узле маршрутизации?
Стоит отметить, что технический эксперт Ник Бхатия уже давал относительно данной темы подробные теоретические выкладки в отдельной статье:
The Time Value of Bitcoin and LNRR
Но, как показало время, рентабельность инвестиций – это гораздо больше, нежели просто вложение капитала в каналы Lightning.
Маршрутизация в Lightning – это многогранная конкурентная система. Здесь дело не только в капитале. Использование капитала как грубой силы приведёт лишь к снижению рентабельности инвестиций. Данная система сама моделирует распределённый предиктивный кэш. Да, доступный капитал – это немаловажный фактор, но, не менее важны разумное размещение этого капитала, а также надёжность и скорость.
— Алекс Босворт (@alexbosworth) 10 мая 2018 г.
В начале 2021 г. я решил попытаться определить, насколько эффективно можно управлять узлом с целью получения прибыли за счёт вложения средств в каналы маршрутизации.
Если вы спрашиваете о рентабельности инвестиций в узлы маршрутизации – вы, вероятно, имеете неверное представление о том, как функционирует Lightning.
На самом деле, по каналу стоимостью $5 может течь целый миллиард. А вот настройка и поддержание работы данного канала, по которому должен течь этот миллиард – действительно сложная часть дела
— Алекс Босворт (@alexbosworth) 8 февраля 2021 года
В данном случае, я следовал процессу, описанному ещё в моём предыдущем посте, где я рассказывал, как настроить свой узел Lightning для работы исключительно через сеть Tor.
Далее прилагается подробное руководство по улучшению конфиденциальности любого пользователя Lightning Network. Когда обычный человек слышит термин «криптовалюта» – он может предполагать, что каждый аспект протокола надёжно зашифрован, и, следовательно, полностью конфиденциален. Это, безусловно, не так, и пользователям, которых заботит конфиденциальность, необходимо предпринять дополнительные шаги для своей защиты. Одним из конкретных вариантов угрозы, который следует учитывать пользователям сети Bitcoin и Lightning, является т.н. «сетевые наблюдатели». Ведь, по дефолту, отправляя данные в открытом виде по сетям IPV4 и IPV6 – вы рискуете быть отслеженным опытными организациями, которые могут искать шаблоны для сопоставления вашей финансовой активности, а также использовать IP-адрес вашего компьютера, чтобы проверить устройство на определённые недостатки и попытаться узнать ваше местоположение и личность.
Как нам защитить себя?
1. Передавать третьим лицам как можно меньше данных о себе
2. Обеспечить передачу и получение сетевых данных нашими узлами с сохранением полной конфиденциальности
Полные узлы предлагают наилучшую модель конфиденциальности, когда дело доходит до предотвращения утечек данных. С полным узлом вы загружаете все данные блокчейна и запрашиваете адреса и транзакции только локально – в этом случае сетевые наблюдатели не могут отслеживать вашу деятельность.
Но, даже если мы запускаем собственный узел, то нам всё равно придётся обмениваться данными с другими пирами в сети, например, для отправки транзакций. Как, при этом, мы можем защитить себя? Используйте Tor. Мэйнтейнеры проекта Tor предлагают думать о работе технологии, как «использовании извилистого труднопроходимого маршрута, чтобы сбить с толку тех, кто следит за вами и последующем периодическом затирании ваших следов в сети». В общем, ваш трафик смешивается с трафиком других пользователей Tor. И по мере роста глобальной базы пользователей Tor – этот путь становится всё более извилистым.
Для того чтобы вы могли использовать сетевые сервисы (что угодно, от веб-сервера до однорангового узла) в Tor, вам необходимо создать скрытую службу, которая действует как мост от сети Tor к определённому программному обеспечению, запущенному на вашем компьютере.
Bitcoin Core
Начиная с версии Bitcoin Core 0.12, узел автоматически запускает скрытую службу, если он может подключиться к локальному демону Tor. Однако мы должны убедиться, что некоторые вещи настроены правильно, чтобы узел и демон могли общаться друг с другом. Таким образом, еще в 2016 году я впервые изучил, как заставить свои биткойн-узлы работать в сети Tor, и написал данное руководство:
Как запустить биткойн-узел в сети Tor на Ubuntu [eng]
Приведённое выше руководство поможет вам пройти основную часть пути, хотя для отключения связи через IPV4 и IPV6 потребуется выполнить дополнительную настройку.
Таким образом, при настройке Bitcoin Core для работы узла Lightning, вам понадобятся следующие строки в вашем файле bitcoin.conf:
# [core] # Maintain a full transaction index (improves lnd performance) txindex=1 daemon=1 disablewallet=1 maxuploadtarget=1000 # [rpc] # Accept command line and JSON-RPC commands. server=1 rpcauth=[redacted]:[redacted] # [zeromq] # Enable publishing of transactions to [address] zmqpubrawtx=tcp://127.0.0.1:28333 # Enable publishing of raw block hex to [address]. zmqpubrawblock=tcp://127.0.0.1:28332 # Privacy bind=127.0.0.1:8333 # Allow DNS lookups for -addnode, -seednode and -connect values. dns=0 # Query for peer addresses via DNS lookup, if low on addresses. dnsseed=0 # Specify your own public IP address. externalip=[redacted].onion # Use separate SOCKS5 proxy to reach peers via Tor onion=127.0.0.1:9050 proxy=127.0.0.1:9050 proxyrandomize=1 # Only connect to peers via Tor. onlynet=onion listenonion=1 listen=0 # helps bootstrap peers for initial sync addnode=gyn2vguc35viks2b.onion addnode=kvd44sw7skb5folw.onion addnode=nkf5e6b7pl4jfd4a.onion addnode=yu7sezmixhmyljn4.onion addnode=3ffk7iumtx3cegbi.onion addnode=3nmbbakinewlgdln.onion addnode=4j77gihpokxu2kj4.onion addnode=546esc6botbjfbxb.onion addnode=5at7sq5nm76xijkd.onion addnode=77mx2jsxaoyesz2p.onion addnode=7g7j54btiaxhtsiy.onion addnode=a6obdgzn67l7exu3.onion addnode=ab64h7olpl7qpxci.onion addnode=am2a4rahltfuxz6l.onion addnode=azuxls4ihrr2mep7.onion addnode=bitcoin7bi4op7wb.onion addnode=bitcoinostk4e4re.onion addnode=bk7yp6epnmcllq72.onion addnode=bmutjfrj5btseddb.onion addnode=ceeji4qpfs3ms3zc.onion addnode=clexmzqio7yhdao4.onion addnode=gb5ypqt63du3wfhn.onion addnode=h2vlpudzphzqxutd.onion
Обратите внимание, что две строчки в этом коде динамические:
rpcauth=[redacted]:[redacted]
Значение rpcauth должно быть установлено путём запуска этого скрипта Python.
externalip=[redacted].onion
Чтобы найти вашу скрытую службу для переадресации, которую вы устанавливаете в качестве внешнего IP-адреса – вам потребуется выполнить следующую команду во время работы вашего узла:
bitcoin-cli getnetworkinfo | grep »address
Теперь вам просто нужно подождать, пока биткойн завершит синхронизацию. Это займет, по крайней мере, несколько дней, в зависимости от множества факторов.
LND
LND так же умён, как и Bitcoin Core, в том смысле, что он может общаться с демоном Tor – вам просто нужно сообщить ему об этом.
Я предлагаю следующие параметры для lnd.conf:
[Application Options] minchansize=100000 listen=localhost accept-keysend=1 allow-circular-route=1 watchtower.active=1 # Mark unpayable, unpaid invoices as deleted gc-canceled-invoices-on-startup=1 gc-canceled-invoices-on-the-fly=1 # Avoid historical graph data sync ignore-historical-gossip-filters=1 # gRPC socket binding rpclisten=0.0.0.0:10009 restlisten=0.0.0.0:8080 # Avoid slow startup time sync-freelist=1 # Avoid high startup overhead stagger-initial-reconnect=1 # Auto regenerate RPC TLS certificate tlsautorefresh=1 # Do not include IPs in the RPC TLS certificate tlsdisableautofill=1 [Bitcoin] bitcoin.active=true bitcoin.mainnet=true bitcoin.node=bitcoind bitcoin.minhtlc=1000 bitcoin.basefee=1000 bitcoin.feerate=100 [Bitcoind] bitcoind.rpcuser=[redacted] bitcoind.rpcpass=[redacted] bitcoind.zmqpubrawblock=tcp://127.0.0.1:28332 bitcoind.zmqpubrawtx=tcp://127.0.0.1:28333 bitcoind.estimatemode=ECONOMICAL [routerrpc] # Set default chance of a hop success routerrpc.apriorihopprob=0.5 # Start to ignore nodes if they return many failures routerrpc.aprioriweight=0.75 # Set minimum desired savings of trying a cheaper path routerrpc.attemptcost=10 routerrpc.attemptcostppm=10 # Set the number of historical routing records routerrpc.maxmchistory=10000 # Set the min confidence in a path worth trying routerrpc.minrtprob=0.005 # Set the time to forget past routing failures routerrpc.penaltyhalflife=6h0m0s [tor] tor.active=true tor.v3=true tor.streamisolation=true
Обратите внимание, что значения bitcoin.rpcuser и bitcoind.rpcpass должны быть входными, т.е. заполнены автоматически ещё при настройке Bitcoin Core, посредством выложенного выше скрипта rpcauth, а не заполняться самостоятельно как выходные данные.
В принципе, у LND есть множество вариантов конфигурации, поэтому, возможно, вы захотите просмотреть образец int.conf здесь. У Алекса Босворта также есть несколько довольно подробных рекомендаций по настройке вашего компьютера.
И обязательно установите автоматическое резервное копирование внешних каналов для аварийного восстановления! Поверьте мне, вы захотите избежать необходимости восстанавливать повреждённые данные кошелька. Я много писал о некоторых крайних случаях, с которыми мне приходилось сталкиваться.
Вот простой служебный скрипт, который вы можете настроить для отправки резервных копий каналов на другой компьютер с помощью любой команды bash, которую вы можете придумать (например, scp.) В качестве альтернативы вы можете использовать этот скрипт, который я нашел и изменил, для автоматического резервного копирования ваших каналов в Dropbox.
Мобильное управление узлом через Zeus
Настройка ваших узлов – это здорово, но, что, если вы действительно хотите использовать их для оплаты, когда вы находитесь в городе налегке, а не таскаете с собой ноутбук?
На момент написания статьи оказалось, что Zeus – единственное мобильное приложение, доступное как на iOS, так и на Android, которое поддерживает прямую связь с удаленными узлами LND, Eclair и c-lightning.
И хотя Zeus может общаться с вашим узлом через IPV6, вы также можете использовать Tor. Для начала вам стоит создать отдельный скрытый сервис Tor для интерфейса REST land.
sudo vim /etc/tor/torrc
Добавьте две следующие строки:
HiddenServiceDir /var/lib/tor/lnd_rest/ HiddenServicePort 8080 127.0.0.1:8080
Перезагрузитесь и найдите ваше новое имя хоста службы onion, которое нужно вставить в Zeus
sudo service tor restart sudo cat /var/lib/tor/lnd_rest/hostname
Далее, создайте macaroon для аутентификации:
/path/to/lncli bakemacaroon address:read address:write info:read info:write invoices:read invoices:write message:read message:write offchain:read offchain:write onchain:read onchain:write peers:read peers:write signer:generate signer:read
Эта команда выведет hex, который вам нужно будет вставить в Zeus. Также, убедитесь, что в конфигурации Zeus установлен флажок «Использовать Tor».
Но, есть ещё кое-что.
Управление ликвидностью в LN
Мы всё ещё находимся на заре понимания лучших практик управления ликвидностью в Lightning Network. Я ожидаю, что на эту тему будут написаны целые книги. Однако, вам уже сейчас следует изучить основы. На данный момент, существует несколько доступных инструментов, помогающих управлять ликвидностью по вашим каналам.
Инструмент Balance of Satoshis предлагает множество функций для управления ликвидностью. И если вы прочтёте документацию, то вы найдете несколько примеров автоматизации в разделе Linux Fu.
Просто помните, что полезный канал – это сбалансированный канал!
***
В общем, сам запуск программного обеспечения был довольно лёгкой частью. Но, затем мне нужно было выяснить, как наиболее эффективно разместить свой капитал.
Ваш опыт может быть иным
К сожалению, невозможно написать руководство по принципу: «Подключитесь к этим узлам и начинайте зарабатывать». Вам стоит думать о сети Lightning как о конкурентном рынке, где протекает приличный поток капитала. Как и в случае с какой-либо эффективной торговой стратегией, если все начнут использовать её, то любые преимущества, которыми она обладала, исчезнут, и, к тому же, это создаст возможность для других торговать против неё.
Если бы все строили одни и те же мосты для потока капитала – это была бы гонка на выживание с конкуренцией за комиссионные. Да, и для других операторов было бы разумнее избегать данной стратегии, создавая мосты в другом месте.
Множество переменных
Возможно, вы заметили, что это чрезвычайно длинная статья. Это связано с тем, что существует множество различных проблем, которые необходимо учитывать при работе с сетевым узлом Lightning с целью максимальной оптимизации маршрутизации.
Это включает в себя:
[Прим. переводчика. Submarine Swaps – это технология обмена цифровыми активами внутри и вне сети (то есть между биткойнами, хранящимися в блокчейне, и биткойнами в сети Lightning). Submarine Swaps – это особый вид т.н. «атомарных свопов», которые могут выполняться без депозитарного или контрагентного риска]
Касательно открытия каналов
В этом документе от Алекса Босворта есть некоторые подробные рекомендации.
Открыть канал в Lightning Network очень просто – подавляющее большинство узлов в сети примут практически любое предложение от входящего канала. Правда, таким образом, капитал может быть легко заблокирован на стороне плохо работающего партнёра, который не направляет много платежей. Т.е. если ваш партнёр перестанет отвечать, то закрытие канала за отказ сотрудничать, может привести к тому, что ваш капитал окажется в подвешенном состоянии на несколько недель.
В своем изначальном эксперименте я обнаружил, что некоторые пиры были просто недоступны, возможно, потому, что у них не было достаточной ликвидности для других одноранговых узлов. В общем, довольно сложно определить заранее, каков будет статус однорангового узла, не исследуя различные маршруты в сети, для чего сначала требуется открыть канал. Я действительно ожидаю, что появятся онлайн-сервисы, которые помогут решить эту проблему и дадут больше информации о состоянии ликвидности конкретного узла.
Но, что бы вы ни решили делать, избегайте использования автопилота от клиента lnd – он просто подключается к крупным популярным узлам. Похоже, что по такому же принципу многие люди просто обращаются к Lightning Terminal или 1ML и подключаются к узлам с самым высоким рейтингом. Это не является выигрышной стратегией, если вы хотите, чтобы ваш узел перенаправлял много платежей, что может показаться нелогичным. Наоборот, вам следует стремиться создавать новые мосты, связывая одноранговые узлы, которым в противном случае пришлось бы совершать много переходов, чтобы добраться друг до друга.
Ещё одна проблема, с которой я столкнулся, заключается в том, что люди используют оценку BOS, чтобы решить, с какими узлами открывать каналы. Алекс Босворт, написавший этот алгоритм оценки, сказал мне, что, по сути, он не был разработан как система оценки качества узлов, в частности, их способности к маршрутизации.
Но, я всё же использовал инструмент Node Match Tool, чтобы выяснить, какие узлы лучше укрепят мои связи в сети. Тем не менее, ещё раз предостерегаю от слепого открытия каналов с теми, кто занимает самое высокое место. Прежде чем открыть канал с одним из рекомендуемых узлов, я проверяю его через Lightning Terminal, чтобы убедиться в его стабильности. Затем я проверяю его на 1ML, чтобы проверить, устанавливают ли они разумные правила взимания платы.
Также, чтобы понять, как улучшить связь моей ноды с другими узлами, я использовал скрипт от Gridflare – «Improve Centrality» из набора lndpytools. В отличие от других веб-инструментов, это, безусловно, не так удобно с точки зрения простого пользователя, поскольку в этом случае требуется получить полный дамп сетевого графика с вашего узла, перенести его на ваш компьютер или ноутбук, а затем запустить анализ специального файла json.
По моему опыту, большинство «высокосвязанных» узлов с более чем 500 каналами, как правило, нестабильны и, следовательно, не могут маршрутизировать достаточно много платежей. Я подозреваю, что их оборудование слишком нагружено. Однако, некоторые люди сообщают об ином – YMMV! [Прим. переводчика. Дословно (Your mileage may vary) – «ваш пробег может отличаться»]
Если вы можете себе это позволить, не создавайте каналы с резервом менее чем 10M sats. Имейте в виду, что максимальный размер платежа по умолчанию составляет чуть более 4M sats. Поэтому, если вы хотите иметь возможность поддерживать каналы, которые могут направлять максимальный размер платежа в любом направлении, вам нужно, по крайней мере, увеличить это значение как минимум вдвое (желательно больше), поскольку довольно сложно обеспечить достаточную входящую и исходящую ликвидность с обе стороны канала.
Хотя, если вы не пытаетесь стать узлом маршрутизации – это не так важно. А вот чтобы ваш узел маршрутизировал большой объём небольших платежей от меньших каналов, то вам, вероятно, потребуется более серьёзная ребалансировка. В общем, желательно, чтобы пропускная способность вашего канала была как можно выше.
Если вы не можете позволить себе канал с 10M sats – я всё равно предлагаю использовать как минимум 1M sats. Например, мой узел отправил 400 платежей за последние несколько месяцев, и средняя сумма пересылки составила 420 000 sats (около $150). Таким образом, вам понадобится почти идеально сбалансированный канал с 1M sats, чтобы иметь возможность пересылать один средний платеж. Надеюсь, данная динамика изменится по мере того, как все больше и больше кошельков начнут использовать «многопутевые платежи».
Кстати, в клиенте Ind вы можете запретить подключение входящих каналов ниже определённого размера, установив это значение в int.conf:
В свою очередь, не все узлы позволят вам открыть канал с ними, и они даже не объяснят, почему они отклоняют ваш запрос. Например, я попытался открыть канал с узлом Zap и получил отказ, даже когда попробовал установить максимальный (по умолчанию) размер канала.
Да, и прежде чем открывать канал с посредником, вы должны попытаться определить, какова будет его политика маршрутизации. Например, узел LNBIG имеет довольно высокие сборы в размере 175 ppm – какой смысл платить за входящую ликвидность на ваш узел, если люди будут избегать её использования из-за высоких сборов?
А некоторые узлы вообще имеют абсурдно высокую плату за маршрутизацию, например, я заметил, что у OKEX и OKCoin’s базовая плата установлена в 1M sats ($400)! Я, правда, поговорил об этом с генеральным директором OKCoin, и он сказал, что это было сделано специально, чтобы препятствовать маршрутизации. От себя я предложил им просто изменить конфигурацию, чтобы отклонить открытие входящего канала.
Пакетное открытие платёжных каналов посредством открытой ончейн транзакции
Если вы запускаете новый узел, для которого необходимо открыть много каналов, и вам комфортно работать в командной строке, то рассмотрите возможность пакетного открытия канала следующим способом.
Речь идёт о пакетной открытой транзакции с использованием таких инструментов как balanceofsatoshi и Electrum Desktop. Ниже приведено краткое описание процесса, но, этот шаг включает в себя ончейн транзакцию и, следовательно, возможную потерю средств, если вы совершите ошибку.
ИНСТРУКЦИЯ:
В Electrum Desktop перейдите в раздел Tools > Preferences, где на вкладке Transactions активируйте пункт Advance Preview. Затем в разделе Tools откройте диалоговое окно Pay to many.
Далее, на вашем узле, в интерфейсе командной строки, от имени пользователя 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 минут, и вам нужно будет выполнить следующие шаги в течение этого времени. Убедитесь, что вы не используете сочетание клавиш Ctrl+C после запуска таймера! Если вы хотите отменить процесс и таймер, просто нажмите Enter в интерфейсе командной строки.
Не вводите никаких других команд в командной строке, а просто скопируйте вывод команды bos open, которая будет представлять собой список ончейн-адресов и сумму в биткойнах, разделённых запятой. Это формат, совместимый с опцией Electrum Pay to many.
В Electrum вставьте данный список в диалоговое окно Pay to many, сохраните транзакцию, нажмите Pay, установите фиксированную плату как можно ниже в зависимости от текущей загрузки мемпула. Кстати, убедитесь, что пункт RBF не отмечен. Затем нажмите на Finalize и Sign (Завершить и подписать), используя свой аппаратный кошелёк или сам клиент Electrum (если не используете хардваллет), но, не транслируйте транзакцию! Это будет сделано посредством balanceofsatoshi. [Прим. переводчика. Требуется установка Node v12.20 +]
Для этого, после завершения и подписания скопируйте подписанную необработанную транзакцию, вставьте ее в интерфейс командной строки и нажмите Enter. Через несколько секунд или минут bos отобразит идентификатор транзакции. Затем вы можете использовать собственный блок-эксплоурер в вашем узле, чтобы проверить состояние отправленной пакетной транзакции.
Открытие каналов с двойным финансированием
Если у вас есть друг, который захочет сотрудничать с вами, то вы можете немного сэкономить на перебалансировке/лупинге [см. прим] – просто инициализировав канал, который уже сбалансирован.
Вот шаги для Алисы и Боба, использующие интерфейс командной строки с bos:
Перебалансировка каналов
Правда, в некоторых случаях, я так и не смог сбалансировать канал из-за недостаточной ликвидности. Если вы заметили, что канал никогда не сбалансирован и никогда не используется для направления средств, то, возможно, вам стоит рассмотреть возможность его закрытия и распределения капитала в другом месте.
Но, вы должны убедиться, что это имеет экономический смысл, прежде чем заниматься перебалансировкой каналов. В противном случае вы просто попадёте в петлю постоянно балансирующих каналов, так как они редко будут оставаться идеально сбалансированными. Слепое восстановление баланса в погоне за поддержанием идеального баланса почти наверняка приведет к тому, что сборы обойдутся вам дороже, чем вы зарабатываете на маршрутизации платежей. К счастью, у bos есть опция – пробный запуск, чтобы узнать, какой будет плата.
В общем, вы можете использовать bos для автоматической перебалансировки, но, для того, чтобы не проводить расточительную перебалансировку – вам нужно изменить максимальную ставку комиссии на минимальную со значением /2.
Вы можете добиться этого, просто добавив эту строку в /etc/crontab:
*/10 * * * * jameson /path/to/bos rebalance —max-fee-rate 5
Но, в итоге, я наткнулся на инструмент для восстановления баланса (rebalance-lnd tool) от Карстена Отто. Мне нравится этот инструмент для перебалансировки, потому что он делает дополнительный шаг в определении того, имеет ли данный маршрут перебалансировки экономический смысл. Как рассчитывается экономическая целесообразность перебалансировки?
Допустим, у вашего узла есть два канала, по которым можно оценить перебалансировку: один для Bitfinex с 10 млн на вашей стороне, и ставкой 1000 ppm. При этом, ваш узел дополнительно имеет loop-канал и взимает 5000 ppm за пересылку средств.
[Прим.переводчика. Lightning Loop – это услуга, предлагаемая Lightning Labs, которая упрощает трансферинг биткойнов при работе с Lightning Network. Основные функции: автоматическая балансировка каналов, выполнение и мониторинг своп-операций, а также пакетная обработка транзакций для экономии на комиссии]
Но, к сожалению, ваша сторона канала в основном пуста. Возможно, будет хорошей идеей перевести средства с канала Bitfinex на loop-канал .
В случае перебалансировки 4M sats – это будет означать, что:
- После перебалансировки у вас останется 6M sats, которые можно будет перенести обратно на Bitfinex. При этом, вы не сможете получить 4M sats ( 4M * 1,000 ppm), которые вывели из канала в рамках перебалансировки loop-канала.
- При перебалансировке вы также должны оплатить любые транзакционные издержки – это ваши прямые затраты.
- Если вам повезет, вы сможете отправить эти 4M sat в loop-канал и заработать 20 000 sat (4M * 5,000 ppm). Это ваш потенциальный будущий заработок.
В общем, перебалансировка имеет экономический смысл только в том случае, если потенциальная прибыль больше нуля и выше всех издержек.
Но, оказалось, что, как правило, игра не стоит свеч. Похоже, что из моих попыток перебалансировки с помощью rebalance-lnd tool только 5% оказываются удачными.
Поэтому я настроил cronjob на выполнение случайной перебалансировки каждые 5 минут, добавив эту строку в /etc/crontab:
*/5 * * * * jameson /path/to/rebalance.py —to -1
На моем узле есть пара десятков каналов, но, в любой момент времени только около 25% из них нуждаются в перебалансировке в соответствии с rebalance-lnd tool, который по умолчанию пытается поддерживать по крайней мере 1M sats с каждой стороны канала. Эти значения по умолчанию вряд ли будут оптимальными для вашей собственной ситуации. Выполняя случайную попытку перебалансировки каждые 5 минут, я ожидаю, что каждый канал, нуждающийся в перебалансировке, будет пытаться делать это где-то дважды в час.
Внимание: это может дорого обойтись, если ваши комиссии за канал сейчас нереально высоки, и вы собираетесь снизить их в будущем! Убедитесь, что вы понимаете последствия автоматизации действий, связанных с деньгами.
Профессиональный совет: после выполнения перебалансировок каждые 5 минут в течение недели я узнал, что он заполнял различные панели мониторинга тоннами неоплаченных счетов с истёкшим сроком действия.
Чтобы устранить эту проблему, я предлагаю установить следующие две конфигурации lnd:
Управление политикой канала
Далее, я нашёл инструмент charge-lnd, который используется для автоматического динамического изменения платы за маршрутизацию на моих каналах. Стоит отметить, что это далеко не идеальный инструмент, потому что, к сожалению, мы можем устанавливать плату только за исходящие каналы. Правда, это ограничение протокола Lightning, а не самого инструмента. Вы можете прочитать больше по поводу вопроса поддержки входящих сборов на Github.
Первоначально, в течение первых нескольких месяцев работы, я установил следующие правила оплаты за мой канал:
Да, эти сборы на порядок выше, чем по умолчанию, но, я просто хотел посмотреть, будут ли пользователи в сети проявлять недовольство. Однако, с такими комиссиями мой узел перенаправлял средства исключительно спорадически (время от времени). Предположительно, либо мои гонорары были слишком высокими, либо мой узел не достаточно хорошо вписался в структуру сети (либо и то, и другое).
Позже я установил следующую конфигурацию для charge-lnd:
И настройте для cronjob ежечасный запуск charge-lnd, добавив эту строку в /etc/crontab.:
0 * * * * jameson /path/to/charge-lnd -c /path/to/charge.config
В течение 48 часов после включения этого динамического управления политикой я увидел, что мой узел начал направлять больше платежей.
Вы не должны запускать этот скрипт чаще, чем раз в час, так как эти обновления распространяются относительно медленно, и если вы слишком часто меняете плату, то удалённые узлы, которые решат проложить маршрут через вас, часто будут получать ошибки FEE_INSUFFICIENT и, вероятно, занесут ваши каналы или узел в черный список на несколько часов. Также желательно уменьшить сетевой трафик от Gossip.
[Прим.переводчика. Gossip – технология, которая отвечает за мониторинг информации об узлах и каналах в сети Lightning, после чего транслирует эти данные в сеть посредством специального протокола. Таким образом, вместо того, чтобы полагаться на некое третье лицо для получения данной информации – узел в Lightning автоматически получает необходимые сведения от Gossip]
Но, через пару месяцев маршрутизация всё ещё имела спорадический характер, поэтому я изменил размер комиссий:
Правда, есть вещь, которую стоит отметить – использование менеджера политики динамических каналов несколько противоречит логике, используемой инструментом rebalance-lnd, который рассчитывая альтернативные издержки, которые вы платите, перемещая ликвидность, предполагает, что ваши сборы за канал останутся неизменными в обозримом будущем.
Например, если rebalance -lnd использует текущий размер комиссий вашего канала, чтобы решить, когда следует выполнить перебалансировку, но, charge-lnd, при этом, поменяет комиссию позже, rebalance lnd всё равно примет оптимальное решение, исходя из первой ставки, несмотря на действия charge-lnd. Соответственно, это делает логику его перебалансировки неверной.
В общем, похоже, что дополнительно rebalance-lnd потребуется знать конфигурацию комиссий у charge-lnd, а также историю прохождения средств по каналу, чтобы лучше прогнозировать будущие комиссионные доходы.
Покупка входящей ликвидности
Получение (и поддержание) входящей ликвидности является одной из самых больших проблем при запуске узла маршрутизации.
По состоянию на 5 июля 2021 года стоимость покупки максимального объема входящей ликвидности (16,7 млн сат/$5650) для канала через определённые сервисы составляет:
Также вы можете воспользоваться следующими сервисами для открытия канала или получения средств из основного блокчейна:
https://lightningconductor.net/channels
https://ln2me.com/
Правда, эти методы для ввода средств требуют доверия к сервису. Решение, требующее меньшего доверия, заключается в использовании функции открытия канала с двойным финансированием посредством bos, упомянутой ранее, хотя для этого требуется найти контрагента по каналу, который достаточно подкован, чтобы использовать интерфейс командной строки balanceofsatoshis.
Дополнительно, если у вас есть учётная запись на бирже, которая поддерживает депозиты в Lightning, вы можете отправить биткойны на биржу, а затем перевести их в ончейн, тем самым увеличив входящую пропускную способность. Несколько лет назад я уже выступал с презентацией о важности подключения бирж к сети Lightning для повышения ликвидности.
Дополнительно, вы может использовать различные каналы связи для координации ликвид-свопов:
https://lightningnetwork.plus/
Reddit Lightning Triangles
Rings of Fire
Plebnet
Если вы используете balanceofsatoshis – bos упростит вам работу с функцией Loop Outs посредством следующей команды:
bos increase-inbound-liquidity —amount <sats> —with <pubkey>
Но, имейте в виду, что выполнение одного из этих свопов обычно занимает не менее часа.
Однако, стоит отметить, что нет никаких гарантий, когда дело доходит до входящей ликвидности. Контрагенты всегда могут закрыть канал, если они решат, что их капитал распределён неправильно!
Единственным исключением является Lightning Pool, с которым вы заключаете контракт на покупку ликвидности на определённый период времени, и этот срок фактически соблюдается на уровне блокчейна, в соответствии с его технической документацией:
Надеюсь, в ближайшем будущем у нас также появится нативная ликвидность, доступная на уровне протокола.
Lightning Loop
Я надеялся, что получение входящей ликвидности через службу Lightning Loop будет проще и безопаснее, чем доверять различным сторонним сервисам. Было невероятно легко настроить инструмент loopd и использовать его в командной строке.
Похоже, что инструмент Autoloop также должен быть довольно простым в настройке, хотя я не уверен, действительно ли это необходимо для узла маршрутизации. Я, честно говоря, не решаюсь использовать функцию autolooping, потому что большинство ручных попыток, которые я пытаюсь выполнить, не завершаются.
Сложность при настройке Loop Outs для получения входящей ликвидности заключена в том, что вы пытаетесь завести как можно больше для получения более ощутимой прибыли с комиссий, но, чем больше значение – тем сложнее найти путь для получения средств из основного блокчейна.
Поэтому, подавляющее большинство моих попыток использовать Loop Outs для получения больших сумм потерпели неудачу из-за проблем с маршрутизацией в Lightning. Например, мой узел в течение 20 минут пытался найти способ вывести 4M sats из ноды Blockstream. Я подозреваю, что у них не так много исходящей ликвидности, ведь поскольку это магазин, то основная часть ликвидности, вероятно, направлена на него конкретно как на приёмник платежей.
Узел Lightning Loop
В качестве теста я открыл канал с помощью ноды Loop, за который заплатил 1 sat/b (154 sat). В течение 5 часов по этому каналу было переадресовано 11 платежей, которые потребляли 98% моей исходящей пропускной способности. При этом, я заработал чуть более 3000 sats в виде гонораров.
Затем узел LOOP закрыл мой канал на 2,5 sat/b (244 sat) – предположительно, потому, что он был настолько несбалансированным, что сервер не смог больше получать средства. Как я слышал, у них есть автоматическое закрытие, когда ваш баланс составляет 20% или ниже. Но, прибыль на 2,600 sats – уже неплохо, верно?
Похоже, что 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, чтобы она игнорировала этот канал и не снижала плату автоматически.
Через несколько дней я сократил плату вдвое, т.к. абсолютно не пересылал никаких платежей, после чего заметил, что количество платежей заметно возросло. Я могу повторить этот эксперимент позже с каналом Wumbo.
[Прим.переводчика. Каналы Wumbo позволяют проводить более крупные транзакции в Lightning Network]
Однако, Алекс Босворт отметил, что это не может работать как простой повторный цикл для открытия больших каналов посредством LOOP. Но, почему нет? Да, потому что каждый раз, когда вы это делаете, он использует вашу общую входящую ликвидность для всех ваших остальных каналов. Итак, представьте, что ваш узел имеет в общей сложности 10M sats входящей ликвидности, и вы начинаете открывать каналы по 1M sats с помощью узла LOOP. Вы сможете повторить это только ~10 раз, прежде чем не сможете направлять больше средств на узел LOOP с вашего последнего канала.
Итак, после изрядного количества экспериментов и ошибок Loop Out выясняется, что выигрышная стратегия заключена в следующем: нужно открыть большой канал с помощью узла 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 peers —fee-days 60 —sort fee_earnings
Вывод этой команды также покажет вам, какие каналы стоит перебалансировать (те, которые генерируют много комиссий за маршрутизацию).
Результаты
После того, как я надлежащим образом сбалансировал каналы – я подождал несколько недель, чтобы посмотреть, много ли я заработал на комиссиях
$ bos forwards —complete —days 90
По дюжине каналов я заработал 17 025 sats в виде платы за маршрутизацию
$ bos chart-fees-earned
Тем не менее, я потратил 31 897 sats на оплату транзакций из основного блокчейна
$ bos chart-chain-fees
Ещё через месяц или около того я ещё немного поиграл с моим узлом на выходных, сменил десятки каналов и добавил автоматизацию:
Правда, почти половина комиссий в основной блокчейн были выплачены за принудительное закрытие одного канала. Это принудительное закрытие обошлось более чем в 100 sats за виртуальный байт в виде комиссии, когда в обычной ситуации – это ~ 5 sats за виртуальный байт. В общем, оглядываясь назад, я полагаю, что этого можно было избежать, если бы я был терпелив и подождал, пока этот пир вернётся в сеть, прежде чем закрывать канал. Если бы не эта вынужденная ошибка, я бы, скорее всего, заработал больше на сборах в LN, нежели на сегодняшний день заплатил за комиссии в основном блокчейне. Это, по-видимому, распространённая проблема.
С другой стороны, якорные каналы должны решить эту проблему, чтобы вам не приходилось полагаться на старые и завышенные ставки по комиссиям. Начиная с версии lnd 0.13.0, вновь созданные каналы по умолчанию используют якоря – вам просто нужно убедиться, что вы сохраняете ~100 000 sats в своем сетевом кошельке для использования в качестве резерва для комиссий.
Что касается прибыли с комиссий в LN, я рад , что, хотя, мои комиссии в ppm сейчас ниже, я стал более последовательно маршрутизировать транзакции. Мой средний ежедневный сбор за последние 90 дней составляет 500 sats, в то время как мой средний сбор за последние 10 дней составляет 1000 sats.
И, хотя, на момент написания этой статьи, мой узел маршрутизации не прибылен, я всё же вижу свет в конце туннеля и продолжу свои усилия по анализу и настройке своего узла.
Другие соображения и случайные мысли
До обновления до lnd v0.13 мой узел (только для Tor) не мог подключаться к узлам IPV4, что значительно ограничивало мои возможности по развертыванию капитала. В общем, если вы используете узел, работающий только через Tor, вы должны понимать, что окажетесь в невыгодном положении, когда дело дойдет до получения входящей ликвидности с узлов, которые не работают через Tor.
Как оператор, вы должны ориентироваться не только на балансы отдельных каналов, но и на общее соотношение входящей/исходящей ликвидности вашего узла. Например, если у вас 100M sats исходящей ликвидности, но только 10M sats входящей, большая часть этой исходящей ликвидности бесполезна. Получение входящей ликвидности — одна из самых больших проблем в моем опыте, даже после выполнения большого операций Loop Outs.
Также, стоит отметить, что алгоритм 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М sats. По собственному опыту, знаю, что перенаправлять платежи размером более чем на 4М sats , как правило, проблематично. Помните, что максимальная сумма одного платежа по умолчанию составляет чуть более 4М sats. И даже если этот предел будет снят, все каналы будут идеально сбалансированы, а также иметь максимальную пропускную способность – максимально возможный платеж всё равно будет составлять 8,3М sats.
У доктора Карстена Отто есть масса полезных заметок касательно данной темы на его сайте по адресу: https://c-otto.de/
Движение вперёд
Стоит помнить, что есть ещё много разных возможностей для совершенствования в отношении инструментов, которые помогают операторам узлов Lightning лучше понимать принципы управления ликвидностью и маршрутизацией.
Например, я бы хотел видеть лучшую визуализацию каналов, которые пересылают платежи. Например, Thunderhub может создавать для этого наглядные диаграммы. Я надеюсь, что как можно больше программного обеспечения для отображения процессов и статистики в LN начнёт делать это автоматически.
Ещё будет здорово, если вы сможете легко отправлять сообщения операторам связанных с вами узлов, чтобы спросить их, как дела или определить их намерения. Теоретически вы можете использовать команду keysend для отправки им платежа в размере 1 sat со встроенным сообщением, но, нет гарантии, что оператор узла когда-либо его увидит.
В общем, команда Send в утилите bos делает именно это:
bos send <key> —message=»hey what’s up?»
Стоит учитывать, что при отправке сообщений возникает небольшая проблема с их получением. Операторы узлов могут не заметить их, потому что они не используют Thunderhub или не создали канал Telegram для получения сообщений от bos, поэтому другие операторы узлов также не утруждают себя отправкой сообщений, потому что они, скорее всего, будут пропущены.
Также, Рене Пикхардт и Стефан Рихтер опубликовали статью, в которой показано, что поиск оптимальных маршрутов значительно сложнее, если базовая плата не установлена равной 0.
Я видел, как множество людей устанавливали базовую плату для своего узла равной 0, но, подозреваю, что это ошибка и практически ничего не улучшит на момент написания данного материала. Это лишь теоретическая оптимизация, при которой узлы начнут получать выгоду только в том случае, если разработчики действительно реализуют алгоритм поиска от Рене и Стефана.
Кроме того, в их документе не обсуждаются иные компромиссы для реализации, такие как учёт возможного вектора атаки DoS. Учтите, что когда ваш узел работает с HTLC (Hash Time Locked Contracts) для маршрутизации средств через него – он должен сохранять данные, касательно этого HTLC, в своей базе данных. В противном случае, если ваша базовая плата равна 0, то кто-то может направлять миллионы платежей в миллисатоши через ваш узел, не платя больших комиссионных.
Однако, с учётом общей схемы потенциальных атак, это может быть довольно тривиальным по сравнению с другими известными проблемами, в том числе, неприятными поступками и попытками вымогательства со стороны злоумышленника, который, в частности, может спокойно блокировать значительное количество средств.
Также, будет здорово, если кто-нибудь создаст инструмент для визуализации входящей/исходящей ликвидности вашего узла и входящей/исходящей ликвидности всех связанных с вами узлов. Это несколько сложно понять (по замыслу), но, возможно, это поможет сделать хотя бы приблизительную оценку будущей схемы маршрутизации. Хотя, уже появился онлайн-сервис, помогающий лучше визуализировать ликвидность других узлов в сети.
Если вы добрались до конца сего труда, поздравляю! Надеюсь, теперь уже ясно, что сеть Lightning – это совершенно новый мир, который мы должны исследовать и строить сообща
Особая благодарность Алексу Босворту, Эрину Мэлоуну и доктору Карстену Отто за рецензирование и предоставление отзывов.
Автор: Jameson Lopp
