Второй уровень – это не волшебное решение

В наши дни многие в этой сфере в ответ на любое обсуждение изменений в протоколе Биткоина парируют: «Не трогайте базовый уровень! Можно просто работать со вторым уровнем!» Кажется, это очень логично, не так ли? Зачем рисковать безопасностью и стабильностью первого уровня, если можно просто использовать его как основу? Проблема в том, что здесь принципиально не учитывается взаимосвязь между первым и вторым уровнем.

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

Эволюция платежных каналов

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

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

Решением стал CHECKLOCKTIMEVERIFY, опкод временной блокировки. CLTV позволял сделать средства непригодными для использования после определенной высоты блока или момента в будущем. Это, в сочетании с возможностью создавать скрипты для траты разными способами позволяло UTXO с мультиподписью получить путь скрипта, по которому отправитель мог бы потратить все средства самостоятельно после блокировки по времени. Таким образом отправитель мог вернуть деньги в худшем случае, даже если транзакция была нарушена. Однако канал по-прежнему мог обеспечивать только односторонние платежи.

Для двусторонних платежей было необходимо правильное решение для податливости транзакций. Это послужило толчком для создания Segregated Witness. Таймлок – это все, что было необходимо для одностороннего канала, потому что сумма денег увеличивалась только в одном направлении. Единственным риском для отправителя было то, что другая сторона не потребует средств, уже отправленных ончейн, оставив деньги отправителя в ловушке. Возврат с использованием блокировки по времени дал получателю стимул получить средства ончейн до наступления блокировки, иначе он потерял бы уже отправленные средства, а отправителю – использовать право регресса и навсегда отключить получателя от сети. Скрипт не поддерживал принудительное использование определенных сумм в определенных будущих сценариях, поэтому предварительно подписанная транзакция являлась единственным жизнеспособным механизмом первоначального возврата, если платежи осуществлялись в обоих направлениях. Это вновь открыло риск того, что средства застрянут.

С переходом на Segwit эта проблема была решена. Вместо возврата денег вследствие блокировки, стимулирующей честное поведение, был введен штрафной ключ. Поскольку средства в двустороннем канале могут двигаться туда и обратно в любом направлении, неизбежно возникнет случай, когда обе стороны будут иметь больше денег в предыдущем состоянии канала, чем в текущем. Создавая боковой канал для заранее подписанной транзакции с использованием штрафного ключа, пользователи могут обмениваться им после подписания нового состояния и знать, что если другая сторона попытается использовать старую транзакцию, они смогут запросить 100% средств в канале. Блокировки по времени используются для обеспечения справедливого расходования средств, когда пользователи видят, что их балансы несоответствующие в течение определенного времени, чтобы дать участникам канала возможность использовать штрафной ключ в случае необходимости. Однако здесь есть проблема: использование CLTV означает, что в какой-то момент в будущем канал должен закрыться, иначе срок блокировки истечет, и у вас больше не будет этого периода безопасности, чтобы наказать нечестную сторону.

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

Однако до сих пор не существует способа направить платеж по нескольким платежным каналам. Проводить платежи можно в обе стороны, но только между двумя людьми в канале. Для маршрутизации платежей по нескольким каналам понадобятся, как вы уже догадались, другие функции первого уровня. Контракты с блокировкой времени хеширования позволяют добиться этого, и для них требуются как CLTV, так и хешлоки. Хешлоки требуют предоставления прообраза хеша для траты монет. Это похоже на подпись, за исключением того, что вы просто раскрываете «закрытый ключ» вместо того, чтобы подписывать с его помощью. Это позволяет получателю платежа Lightning предоставить хеш-лок, а каждому промежуточному каналу между отправителем и получателем создать сценарий для немедленной траты деньги с помощью прообраза хеша или возврата денег после блокировки по времени. Если получатель раскрывает хеш-лок, каждый может запросить деньги за пересылку платежа; если этого не произойдет, то деньги можно запросить назад.

Таким образом, Lightning Network в том виде, в котором она существует сегодня, полностью зависит от пяти функциональных возможностей, доступных на базовом уровне Биткоина: скрипты с несколькими подписями, абсолютные таймлоки, относительные таймлоки, Segregated Witness и хеш-локи. Без какой-либо из этих функций на базовом уровне не было бы сети Lightning, как мы ее знаем сегодня. Ее существование как второго уровня полностью зависит от функциональности первого уровня.

В чем подвох

Тем не менее, говоря строго технически, все же возможно построить эту двунаправленную систему платежных каналов без трех функций на базовом уровне – огромной ценой с точки зрения доверия к другим в том, чтобы они не украли ваши деньги, когда у них есть такая возможность. Федеративный сайдчейн. Каждый мог бы просто создать федеративную цепочку, например Liquid или Rootstock, и добавить эти функции в сайдчейн, построив там сеть Lightning вместо основной сети. Проблема в том, что это не одно и то же. На техническом уровне сеть будет функционировать точно так же, но никто из пользователей не будет иметь такой же степени контроля над своими средствами.

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

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

В чем смысл?

«Второй уровень» – это не волшебное заклинание, нельзя просто произнести слова, чтобы все стало возможным каким-то волшебным образом. Существуют строгие неизбежные ограничения того, на что способен второй уровень, и совладать с этими ограничениями под силу базовому уровню. Это просто неотъемлемый факт инженерной реальности, если смотреть на такую систему, как Биткоин. Этого нельзя избежать: чем большей гибкости второго уровня за пределами возможностей базового уровня мы хотим достичь, тем больше будет необходимо доверия.

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

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