Чуть более года назад три команды, занимающиеся имплементацией сети Lightning Network, объединили усилия для разработки общей спецификации стека протоколов. Теперь, когда и эта спецификация, и наши три имплементации становятся стабильными и удобными в использовании, пришло время задуматься о последующих действиях, таких как дальнейшее совершенствование протокола, добавление новых функций, упрощение и устранение недостатков.
Одним из основных нововведений, которое стало возможным благодаря Lightning, был офф-чейн механизм обновления, позволяющий пересмотреть состояние и гарантировать, что прошлое состояние невозможно закрепить он-чейн. Сегодня мы с удовольствием публикуем нашу последнюю исследовательскую работу о новом упрощенном механизме обновления состояния для протоколов второго уровня, который называется eltoo.
Как работает eltoo?
Офф-чейн переговоры можно представить как договорное соглашение между рядом сторон, а расчёт — как представление дела в суде, который примет окончательное решение — в данном случае судом является блокчейн. Поскольку все обновления происходят вне сети, нам нужен способ, которым он-чейн суд мог бы выслушать аргументы всех сторон до вынесения окончательного решения. На случай, если участник инициирует расчет по контракту, нам нужен механизм, который позволил бы отложить окончательный расчет, чтобы дать контрагенту возможность предоставить свой текущий статус. Суд должен продолжать ожидание обновления статуса, пока в конце концов он не решит принять последнее известное обновление, которое он выслушал. Удивительным образом, большинство требований, которые необходимо удовлетворить, чтобы создать этот блокчейн специально для протоколов второго уровня, уже реализованы в блокчейне Биткоин.
Рисунок 1: Пример выполнения протокола eltoo, показывающий как промежуточные состояния могут быть пропущены, связав более позднюю транзакцию обновления с более ранней или непосредственно с установочной транзакцией. В блокчейне может быть подтверждена только последняя расчетная транзакция.
В eltoo каждое состояние представлено в виде совокупности двух транзакций: транзакция обновления, которая тратит выходы контракта и создает новый выход, и транзакция расчета, которая тратит вновь созданный выход и делит средства в соответствии с согласованным распределением. У выхода есть сценарий, который позволяет моментально присоединить новую транзакцию обновления или присоединить транзакцию расчета после настраиваемого тайм-аута. Если участники договариваются об обновлении до истечения времени ожидания, они создают новую транзакцию обновления, потратив предыдущий выход и дважды потратив соответствующий расчет, тем самым фактически его аннулируя.
Повторное аннулирование предыдущего состояния для согласования нового состояния создает длинную цепочку транзакций обновления, которая в конечном итоге завершится последней транзакцией расчета. Однако такой метод имеет существенный недостаток: если мы хотим произвести расчет, нам придется воспроизвести всю цепочку обновлений в блокчейне. Если так, то мы могли просто выполнить весь протокол он-чейн. Ключевой момент в eltoo заключается в том, что мы можем пропустить промежуточные обновления, грубо говоря, связав заключительную транзакцию обновления с созданием контракта. Чтобы подобное “короткое замыкание” обновлений стало возможным, мы предлагаем ввести новый флаг SIGHASH, SIGHASH_NOINPUT, который позволяет привязывать вход транзакции к любому выходу транзакции с помощью соответствующего сценария. Поскольку все сценарии входов предыдущих транзакций-выходов обновления соответствуют более поздним сценариям входа, мы можем связать более позднее обновление с любым предыдущим обновлением, что позволяет нам пропускать любое количество промежуточных обновлений. Исследовательская работа содержит полную конструкцию протокола, в том числе подробную информацию о том, как создаются сценарии.
Улучшение Lightning
Описанное выше представляет собой механизм обновления, который позволяет конечным точкам платежного канала многократно корректировать свои балансы и использовать более сложные конструкции, такие как HTLC применительно к состоянию.
Значит ли это, что так как основным вкладом исходного протокола Lightning был подобный механизм обновления, мы пытаемся заменить Lightning этим предложением? Однозначно нет!
Рисунок 2: Схема различных суб-протоколов, являющихся частью стека Lightning.
Спецификация Lightning Network больше не является спецификацией отдельного протокола, а скорее представляет собой полный стек протоколов, каждый из которых выполняет свои функции. eltoo не ставит целью заменить весь стек Lightning; скорее это - полная замена исходного механизма обновления, который поддерживает обратную совместимость с другими частями стека.
В eltoo обеспечиваются принципиально иные компромиссы, чем механизм, представленный в первой публикации о Lightning; этот механизм мы будем называть LN-штрафом. В то время как для LN-штрафа использовалась система штрафов, чтобы наказать ненадлежащим образом ведущую себя сторону, eltoo просто обеспечивает соблюдение последнего согласованного состояния офф-чейн контракта. Это имеет важные последствия для применимости и безопасности протоколов, построенных поверх этого механизма обновления.
Отчасти это происходит из-за того, что в eltoo все участники совместно используют общий набор транзакций, в отличие от механизма LN-штрафа, требующего асимметрии, при которой одна сторона имеет доступ к некоторым транзакциям, к которым нет доступа у других участников, ведущих себя ненадлежащим образом. Это изменение устраняет то, что мы называем токсичной информацией в Lightning. Токсичная информация поступает из транзакций, принадлежащих устаревшим состояниям, которые в случае утечки приведут к потере средств. Это происходит не только в том случае, если та или иная сторона ведет себя ненадлежащим образом, но и в том случае, если нода забывает об обновлении (например, при восстановлении из резервной копии). С eltoo это больше невозможно, потому что утверждаться могут только согласованные состояния (это значит, что в eltoo нет штрафов).
Управление данными для участников также упрощено в соответствии с новой парадигмой: им больше не нужно хранить прообразы хеш-функции для недействительных состояний HTLC, которые были признаны недействительными, поскольку транзакция расчета, к которой они были присоединены, не может быть отправлена в блокчейн. Все, что им нужно для хранения — это последняя транзакция обновления, соответствующая транзакция расчета и, возможно, HTLC, которые оплачиваются из этого расчета. Кроме того, расчет упрощается, поскольку он просто привязывает последнюю транзакцию обновления к выходу установочной транзакции, позволяя тайм-ауту истечь до передачи транзакции расчета.
Мы можем объединить результаты обновления с SIGHASH_SINGLE, чтобы разрешить присоединить дополнительные входы и выходы к транзакции обновления во время расчета. Хотя это может показаться незначительным изменением, оно позволяет присоединять комиссии к транзакциям обновления во время расчета, освобождая нас от необходимости фиксировать комиссию заранее. В существующих имплементациях мы должны были бы согласовать и фиксировать комиссию заранее, возможно, за несколько месяцев до совершения попыток подтвердить транзакции он-чейн, что заставляет нас предсказывать, как будет развиваться рынок комиссий; такие меры безопасности могут привести к огромной перегрузке. При выборе отложенной комиссии нам больше не нужно договариваться о размере комиссии, и мы можем даже увеличить сборы, если они окажутся недостаточными.
Благодаря использованию флагов функций, которые позволяют узлу сигнализировать о поддержке новой функции при первом подключении к другому узлу, eltoo можно разворачивать постепенно поверх существующей сегодня сети. Нет необходимости разворачивать совершенно новую сеть.
За пределами Lightning
Как универсальный механизм обновления второго уровня eltoo может использоваться для любого количества систем за пределами Lightning. Например, он позволяет создавать многосторонние офф-чейн контракты, которые в настоящее время могут иметь до семи участников, и которые могут иметь любое количество участников, в сочетании с подписями Шнорра.
Одним из таких многосторонних офф-чейн контрактов является фабрика каналов, представленная Burchert et al как масштабируемый способ пополнения любого количества платежных каналов поверх одной он-чейн транзакции и динамически перебалансировать или перераспределить их, даже не взаимодействуя с блокчейном.
Путь к eltoo
Прежде чем мы сможем реализовать eltoo, нам надо будет внести небольшие изменения в Биткоин, а именно ввести флаг SIGHASH_NOINPUT для подписей. Впервые это обсуждалось несколько месяцев назад в контексте т.н. “сторожевых башен”, чтобы помочь защитить каналы Lightning, но официально это изменение не предлагалось. Официальное предложение об обновлении протокола теперь можно найти в документации eltoo.
Мы предлагаем сообществу рассмотреть наше предложение и принять участие в его обсуждении. Мы надеемся прийти к консенсусу относительно использования SIGHASH_NOINPUT, чтобы его можно было принять и включить в будущий софт-форк Биткоин-скрипта. Это позволит нам перейти на путь к более надежной и простой сети Lightning Network, включающей новый механизм обновления, который также можно использовать для множества других приложений.