Главная Top Обзор софтфорк- и ковенант-зависимых L2-решений для Биткойна

Обзор софтфорк- и ковенант-зависимых L2-решений для Биткойна

От

24.09.2024

Разработчик Биткойна Питер Тодд составил подробный обзор софтфорк- и ковенант-зависимых L2 предложений по масштабированию Биткойна, включая Ark, LN-Symmetry, Validity Rollups, BitVM, CTV, OP_CAT, Consensus Cleanup и другие. Каким общим техническим паттернам они следуют, какие новые опкоды им необходимы? Плюс оценка потенциальных и наиболее перспективных вариантов софт-форка. Масштабирование Биткойна — это далеко не только Lightning Network.

Ончейн-кошельки достигают примерно 1–1 соответствия транзакций: на каждую экономическую транзакцию пользователя приходится примерно одна блокчейн-транзакция. Агрегации, койнджойны, сквозные (cut-through) платежи и т.д. несколько размывают это утверждение, но в целом оно верно.

Lightning достиг соотношения транзакций множество-к-одному: магия LN заключается в том, что в одном lightning-канале, который сам привязан к одному неиспользованному выходу транзакции (UTXO), может происходить практически бесконечное количество экономических транзакций. По сути, мы взяли измерение «время» — транзакции — и добились значительного масштабирования, сократив это измерение.

Но создание даже одного UTXO на пользователя, возможно, недостаточно хороший результат. Поэтому существует множество предложений, направленных на достижение ещё большего масштабирования, позволяя нескольким пользователям делить один UTXO, по-прежнему бездоверительно (trustless) и самостоятельно — в «самосуверенном» режиме. Так ещё одно измерение масштабирования — пользователи — сводится к одному UTXO.

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

Попутно мы также определим, что такое протокол второго уровня (L2), какие возможности масштабирования уже есть благодаря Lightning Network, и поймём, какие улучшения нам ещё нужно внести в мемпулы, чтобы всего этого достичь.

Содержание

Определения
- — Что такое Layer 2
- — Что такое ковенанты
  - — Рекурсивные ковенанты
Цели
- — Пределы масштабирования Lightning Network
Обзор L2
Соображения по мемпулу
Паттерны функций и софт-форки
Фондовые пулы
Объём данных о сбоях
Consensus Cleanup: очистка консенсуса
Тестирование софт-форк-зависимых L2
Потенциальные софт-форки

Определения

Что такое Layer 2

Часто термин «Layer 2» (aka L2, второй уровень, второй слой) определяется слишком широко — до такой степени, что даже банкоподобная структура (например, Liquid) может быть определена как Layer 2. Для целей этой статьи сразу примем строгое определение: Layer 2 (L2) — это система, деноминированная в BTC и разработанная с целью позволить совершать транзакции в BTC с другими контрагентами чаще, чем это позволяет блокчейн Биткойна, — так, чтобы либо:

Никто не мог с выгодой для себя украсть средства в системе, учитывая предусмотренные внутри системы наказания и затраты. Любые формы затрат и наказания вне системы — такие как потеря репутации, юридические последствия и т.д., — не учитываются в нашем определении.
(Предпочтительно) Истинные владельцы средств могли в одностороннем порядке, без сотрудничества с третьими сторонами, вывести из системы свои средства за вычетом комиссий за транзакции.

Первый вариант необходим, потому что мы хотим, чтобы наши L2-системы могли представлять суммы и транзакции настолько малой стоимости, что они не могут быть представлены в блокчейне. Например, в Lightning Network HTLC могут иметь стоимость, слишком малую для представления в блокчейне. В этом случае в транзакции фиксации (commitment) стоимость HTLC добавляется к комиссии за транзакцию. Хотя lightning-узел может «украсть» пылевой HTLC, закрыв канал в нужный момент, эта операция будет дороже стоимости самого HTLC. (По крайней мере, так должно быть. Могут существовать реализации Lightning Network, не ограничивающие должным образом общую стоимость пылевых HTLC в процессе.)

При этом односторонний вывод средств всегда является нашей основной целью при проектировании.

Согласно этому определению, такие системы, как Lightning, считаются L2-системами. Однако такие системы, как Liquid, Cashu или Fedimint, не являются L2, потому что в них другая сторона (или несколько) контролирует ваши средства. Схемы валидации на стороне клиента, такие как RGB, также не подпадают под это определение L2, потому что они не обеспечивают бездоверительных транзакций непосредственно в BTC. Наконец, Statechains не подходят по этому критерию, потому что Statechain-субъект может украсть средства пользователей, если не будет следовать протоколу.

Что такое ковенанты?

…и почему они нужны более масштабируемым L2 системам?

В скриптах Биткойна ковенанты (covenants) — это механизмы, с помощью которых заранее ограничивается способ расходования txout (выхода транзакции), так что форма транзакций, используемых для расходования этого txout, предопределена или ограничена иным образом, не только подписями. L2-системам, которые разделяют UTXO между несколькими участниками, ковенанты нужны, чтобы ограничивать способы расходования UTXO для реализации правил и стимулов протокола L2.

Рекурсивные ковенанты

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

Цели

Lightning на сегодня является лучшей из существующих L2-систем. Однако у неё есть свои ограничения. А именно:

Масштабируемость. Lightning в настоящее время требует как минимум одного UTXO на каждого конечного пользователя. *
Ликвидность — Lightning требует блокировки средств в каналах.
Интерактивность — для бездоверительного получения lightning-платежей получатели должны быть онлайн и подключены к LN.

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

* Вы можете спросить, почему как минимум одного UTXO на каждого конечного пользователя, если в каждом канале два пользователя? Причина в том, что это Lightning Network: с одним UTXO на двух пользователей, максимум, что вы можете сделать, это несколько изолированных пар пользователей, без образования более широкой сети. Одного UTXO на узел достаточно, чтобы сформировать цепочку узлов, которые технически будут полностью соединены. Но на практике вам, конечно, понадобится больше, чем один UTXO на пользователя, потому что одна цепочка узлов может быть полезна только для очень малого количества узлов, поскольку проводить платежи через сотни переходов было бы технически и экономически нерационально.

Пределы масштабирования Lightning Network

Что это означает на практике: «один UTXO на конечного пользователя»? Поскольку lightning-каналы могут работать бесконечно, один из способов на это взглянуть — это спросить: сколько новых каналов можно создать в год? Создание taproot-выхода имеет предельную стоимость 43 vB (vByte); если оптимизировать создание каналов, объединив множество каналов в одну транзакцию, то другие накладные расходы транзакции могут быть сведены к минимуму, и можно открыть довольно большое количество каналов в год для подключения новых пользователей.

Для примера, предположим, что 90% пропускной способности блока используется для открытия новых taproot lightning-каналов:

Алекс Босуорт в 2022 году опубликовал в Твиттере анализ, где пришёл к тем же числам, что и я. Я то ли не видел этого анализа, то ли забыл о нём, поэтому приятно видеть, что наши расчёты совпадают.

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

Однако каналы не вечны. Иногда пользователи захотят сменить кошелёк, увеличить или уменьшить ёмкость канала и т.д. Наиболее эффективный метод изменения ёмкости канала — это сплайсинг, и особенно хорошо он реализован в Phoenix Wallet.

Как и открытие каналов, сплайсинг также можно оптимизировать для повышения эффективности, при этом несколько операций сплайсинга могут делить одну транзакцию, чтобы сократить количество входов и выходов, необходимых для добавления и удаления средств. Таким образом, дельта пространства блока, необходимого для сплайсинга одного пользователя, при условии использования musig, составляет 43 vB для taproot-выхода плюс 57,5 vB для taproot-пути к ключу, что в сумме даёт 100,5 vB. Если мы, опять же, используем 90% пространства блока, то получаем:

Тот факт, что splice-входы и splice-выходы можно объединить в одной транзакции, сокращает также количество необходимых дополнительных входов, так как splice-выходы могут обеспечивать средства для splice-входов. Также обратите внимание, что для внешнего наблюдателя такие транзакции неотличимы от coinjoin.

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

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

Обзор L2

Из подпадающих под наше определение L2-систем, в сообществе биткойн-разработчиков обсуждаются два основных проектных паттерна:

Каналы
Виртуальные UTXO

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

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

Для целей replace-by-fee схема с V-UTXO может фактически иметь множество предварительно подписанных транзакций, но цель этих многих транзакций будет состоять в выполнении единственной экономической транзакции — не как в Lightning, где это позволяет выполнить множество экономических транзакций.

Благополучный сценарий предполагает согласие всех сторон и рутинное использование, например, мультиподписи N-из-N. Taproot, в сущности, для того и разработан, позволяя определять путь к ключу как мультиподпись N-из-N с помощью musig. Если стороны согласны, реализуется оптимальный сценарий, позволяющий эффективно (и приватно) тратить монеты.

Интересно, что, поскольку виртуальные UTXO во многих смыслах являются «реальными», на их основе довольно легко строить каналы, просто создавая виртуальные UTXO, которые, если будут записаны в блок, приведут к созданию UTXO, необходимых для каналов. В этом смысле схемы с виртуальными UTXO являются несколько более низкоуровневыми по сравнению с каналами.

Lightning

Статус-кво, реализованный в продакшене как Lightning Network, преимущественно основывается на стандартах BOLTs. Lightning представляет собой комбинацию нескольких вещей, включая lightning-каналы и HTLC, P2P-сеть с маршрутизацией, луковую маршрутизацию, стандарты инвойсов и т.д. Примечательно, что Lightning не является системой консенсуса, поэтому различные элементы «системы Lightning» не обязательно должны приниматься всеми пользователями одинаково. В рамках этой статьи, говоря о Lightning, я буду использовать это понятие в широком смысле, включая и легко предсказуемые обновления текущего (типичного и широко используемого) протокола Lightning.

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

Поэтому многие будущие L2-системы также планируют участвовать в Lightning Network. Это можно видеть и на примере существующих не-вполне-L2 систем, таких как Cashu, полезность которых также сильно зависит от LN: основное использование Cashu, вероятно, заключается в отправке и получении lightning-платежей.

Неинтерактивные каналы

Эта конструкция улучшает работу lightning-каналов через использование OP_CTV для снижения требований к интерактивности. Но, поскольку это никак не влияет на лимит масштабируемости в 1 UTXO на пользователя, то мы здесь не будем её обсуждать.

Channel Factories: фабрики каналов

Здесь несколько сторон договариваются о создании одного N-из-N multisig адреса, а также о транзакции, которая тратит средства с этого multisig-адреса, создавая n различных UTXO, разделяющих средства. Эти UTXO, в свою очередь, используются для платёжных каналов. Каналы обладают той же степенью безопасности, как если бы были открыты непосредственно в блокчейне, потому что в случае необходимости зафиксировать состояние канала в блокчейне, транзакция разделения может быть замайнена. Это потенциально экономит место в блокчейне при закрытии каналов, так как n сторон могут — в теории — совместно закрыть все n каналов одновременно.

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

Сами по себе Channel Factories не требуют никаких софт-форков, однако простые фабрики каналов, описанные выше, вероятно, непрактичны за пределами очень небольшого числа участников ввиду необходимости координации для достижения эффекта масштабирования. Поэтому предложения по ковенантам, такие как OP_Evict или CTV (через деревья выходов транзакций), направлены на реализацию более детализированных исходов, когда отдельные участники могут публиковать транзакцию закрытия канала в блокчейне, не заставляя остальных участников закрывать каналы одновременно с ними.

Eltoo/LN-Symmetry

Поскольку Eltoo — несколько сбивающее с толку название, я в дальнейшем буду использовать только обновлённое название LN-Symmetry.

Если в «классической» реализации Poon и Dryja lightning-каналы поощряют публикацию правильного состояния в блокчейне, наказывая за публикацию неправильного, то LN-Symmetry, вместо этого, позволяет обновлять неправильные состояния с помощью дополнительной транзакции. Это имеет преимущество упрощения Lightning-каналов за счёт устранения сложности штрафов. Однако это может быть недостатком в сценариях без доверия, поскольку штрафы нужны в том числе для создания отрицательного стимула для мошенничества.

Для реализации LN-Symmetry необходим софт-форк с активацией SIGHASH_ANYPREVOUT, позволяющего транзакциям состояния повторно тратить другие транзакции состояния в процессе обновления.

Сама по себе LN-Symmetry не предлагает улучшений масштабируемости для обычных Lightning-каналов. Однако сторонники отмечают, что она упрощает реализацию таких вещей, как фабрики каналов.

Ark

Ark предлагает новый подход к масштабированию транзакций: полностью передаваемые виртуальные UTXO (V-UTXO), которые можно объединять и разделять в атомарных офчейн-транзакциях.

То есть транзакция Ark либо происходит, либо нет; её создание может занять часы или даже дни. Но либо в ней перемещаются все запланированные средства перемещаются, либо никакие.

В Ark центральный координатор, Ark Service Provider (ASP), предоставляет пользователям V-UTXO с определённым сроком действия, например, 4 недели. Эти периоды называются раундами. Эти V-UTXO создаются через пул выходов транзакций (txout), один на раунд, с использованием механизма CTV, чтобы в одном выходе ончейн-транзакции зафиксировать дерево V-UTXO. Благодаря определённому сроку раунда Ark и достигает преимущества в масштабировании: в конце раунда пул txout разблокируется, позволяя ASP в одностороннем порядке потратить его с одной подписью в небольшой транзакции. Срок действия V-UTXO истекает вместе со сроком действия пула txout, в котором они были созданы: пользователи, владеющие V-UTXO, должны либо потратить свои V-UTXO до истечения этого срока, либо самостоятельно вывести их в блокчейн (односторонний вывод).

Для совершения транзакций с V-UTXO между сторонами координатор Ark совместно подписывает транзакции, расходующие один или несколько V-UTXO, так что транзакции действительны только в том случае, если один или несколько других V-UTXO создаются в другом раунде. В сочетании с тщательно подобранными тайм-аутами — см. документацию Ark — эта зависимость делает траты V-UTXO бездоверительными: V-UTXO не могут быть истребованы ончейн, если новые V-UTXO не создаются в другой транзакции пула. Существует несколько потенциальных способов реализации этой зависимости, однако точные детали не имеют значения для целей этой статьи.

Обратите внимание, что это означает, что у данного Ark-сервис-провайдера будет много различных активных раундов одновременно. Новые раунды часто создаются для того, чтобы позволить перевод средств из существующих раундов. Но существующие раунды перекрываются с новыми раундами, так как они обычно истекают через какое-то время после создания новых раундов и новых пулов txout.

Экономика Ark

Когда V-UTXO тратится, ASP должен предоставить соответствующие BTC в новом выходе транзакции (txout) пула, представляющем новый раунд. Но они не могут восстановить стоимость потраченного V-UTXO до истечения раунда. Таким образом, экономика трат V-UTXO имеет стоимость времени денег из-за ликвидности, которую ASP должен предоставить.

Таким образом, экономика расходов на V-UTXO подразумевает временную стоимость денег из-за ликвидности, которую должен обеспечить ASP.

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

Таким образом, для траты V-UTXO требуется краткосрочный заём, чтобы покрыть временной интервал между текущим моментом и истечением срока раунда. Это означает, что стоимость ликвидности для траты V-UTXO фактически снижается по мере старения V-UTXO и приближения времени истечения, в конечном счёте — теоретически — достигая нуля, когда раунд наконец истекает.

Наконец, помните, что стоимость траты V-UTXO связана с общим размером потраченного V-UTXO, а не с суммой, выплаченной получателю. Это означает, что кошельки, предназначенные для непосредственных транзакций с V-UTXO (в отличие от управления одним V-UTXO, например, с целью открытия lightning-канала), должны идти на какие-то компромиссы в отношении того, как они делят средства на V-UTXO. Один V-UTXO минимизирует стоимость одностороннего вывода, одновременно максимизируя комиссии за транзакции, основанные на ликвидности; разделение средств на множество V-UTXO даёт противоположный эффект. Это совершенно не похоже на экономику транзакций в сети Биткойна или Lightning Network.

Сколько может стоить эта ликвидность? На начало сентября 2024, lightning-кошелёк Phoenix взимает комиссию в размере 1% за резервирование ликвидности канала на 1 год; в худшем случае Phoenix придётся заморозить свои средства на год. Однако это предполагает, что ликвидность не будет использована. Вполне возможно, что стоимость капитала для Phoenix на самом деле выше, но они предполагают, что средний клиент использует свою входящую ликвидность быстрее, чем за год. К тому же Phoenix зарабатывает на комиссиях за транзакции, и потенциально может субсидировать ликвидность канала из этих средств. Наконец, Phoenix может быть и неприбыльным.

Ставка по казначейским векселям США даёт нам ещё одну оценку. Опять же, на начало сентября ставка по 3-месячным казначейским векселям составляет около 5% годовых. Поскольку существует мнение, что эта ставка завышена из-за инфляционной динамики доллара США, для нашего анализа предположим, что стоимость ликвидности для фондов, номинированных в BTC, составляет 3% годовых.

Если интервал раунда составляет 4 недели, это означает, что транзакция начнётся с затрат на ликвидность в размере 3%/524 = 0,23%, со временем снижающихся до нуля. Предположим, что пользователь пытается перевести свои средства в новый раунд за две недели до истечения текущего раунда. Тогда он платит около 1,5% годовых в виде затрат на ликвидность для достижения самоконтроля над своими средствами. С другой стороны, если пользователь ждёт до последнего момента, затраты могут быть практически нулевыми, но при этом есть риск пропустить время истечения.

Помните, что, если ASP отказывает в трате V-UTXO для перевода в новый раунд, у пользователя остаётся только одна альтернатива — односторонний вывод в блокчейн. Это не только дорого, но занимает время: транзакции пользователя могут не успеть получить подтверждение до того, как ASP успеет потратить txout пула. Если раунд достаточно большой, пользователи могут даже конкурировать друг с другом за место в блоке.

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

Но что, если фиксированные затраты не так уж незначительны? Предположим, что у ASP 1000 пользователей, и txout пула создаются в среднем раз в час. За 4 недели это даёт 672 ончейн-транзакции, и получается, что для простого хранения своих средств пользователи ASP коллективно должны оплатить почти столько же транзакций, сколько пользователей в пуле! Вероятно, для них было бы дешевле открыть собственные lightning-каналы, даже если время ожидания подтверждения от ASP составит целый час.

Запуск Ark

Новый ASP с небольшим количеством пользователей сталкивается с дилеммой: либо раунды ASP происходят редко, и пользователям приходится долго ждать, пока предложенный раунд соберёт достаточно V-UTXO для достижения полезного масштабирования и снижения комиссии за транзакции. Либо транзакции пула ASP происходят часто и с высокими комиссиями, оплачиваемыми за счёт пользователей. Как мы уже увидели в предыдущем разделе, для амортизации частых раундов и ончейн-транзакций пула может потребоваться много пользователей.

Поскольку раунды имеют ограниченный срок действия, эта проблема остается актуальной и даже более серьёзной, чем та, с которой сталкиваются lightning-каналы. В отличие от пулов, lightning-канал может использоваться неограниченное время — его можно открыть прямо сейчас и постепенно амортизировать в течение многих месяцев. Более того, ограниченный срок действия раундов предполагает меньшую гибкость в отношении времени создания новых транзакций, поддерживающих эти раунды. Если комиссии остаются высокими в течение недели или двух, пользователи истекающих раундов вынуждены (коллективно) платить эти высокие комиссии для сохранения контроля над своими средствами. В случае с lightning-каналами существует гораздо больше гибкости в выборе времени открытия канала.

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

Интерактивность

Некастодиальная реализация Ark — это высокоинтерактивный протокол: ограниченный срок действия ваших V-UTXO означает, что у вас есть жёсткие сроки для взаимодействия с ASP, иначе он может выбрать изъятие ваших средств. Эту интерактивность нельзя передать на аутсорс: если в Lightning есть watchtowers, которые препятствуют попыткам контрагентов вас обмануть — даже если ваш канал не был онлайн, — то владельцы койнов Ark должны использовать собственные приватные ключи для обновления средств без доверия. Наиболее близким аналогом watchtower в Ark было бы подписание транзакций, позволяющих watchtower в одностороннем порядке выводить ваши средства в блокчейн к моменту истечения срока V-UTXO, что сопряжено со значительными затратами на ончейн-комиссии.

Что происходит с V-UTXO, если его владелец уходит офлайн: после истечения раунда ASP необходимо вернуть средства, чтобы восстановить ликвидность для следующих раундов. Если владелец V-UTXO уходит офлайн, то запись этого V-UTXO в блокчейн влечёт за собой значительные транзакционные издержки, поскольку ASP теперь нужно восстанавливать средства на нескольких уровнях дерева V-UTXO. ASP может перенести неиспользованные V-UTXO в новый раунд. Но это не будет «бездоверительным» (trustless) подходом с точки зрения владельцев V-UTXO, так как они не смогут потратить эти новые V-UTXO без получения данных от ASP. ASP же может просто записать неиспользованные V-UTXO как кастодиальный баланс. Или даже ввести политику изъятия средств.

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

Advanced Ark

Требования к ликвидности Ark, вероятно, можно уменьшить с помощью более продвинутых ковенантов, если ликвидность обычно частично используется в течение раунда. Например, предположим, что 50% от общей стоимости V-UTXO в пуле txout было потрачено. Если ASP сможет выкупить только эту часть пула за раунд, то он сможет быстрее восстановить ликвидность, снижая общие затраты на ликвидность. Хотя конкретные предложения о том, как это сделать, ещё не опубликованы, кажется, что это вполне возможно с помощью Sufficiently Advanced™ («достаточно продвинутых») ковенантов. Скорее всего, это будет достигнуто через какой-то софт-форк, добавляющий множество полезных опкодов одновременно.

Аналогично, с помощью Sufficiently Advanced™ ковенантов всю структуру дерева txout можно заменить на схему с поэтапным выводом, что потенциально может сэкономить место. Мы рассмотрим это в следующем разделе, так как эта техника может быть полезна и для других схем.

Проблема с кастодиальным хранением в конце раунда — это ещё один случай, когда Sufficiently Advanced™ ковенанты могли бы решить проблему: ковенант и, в частности, ZK-proof ковенант, мог бы вынудить ASP воссоздать в следующем раунде все неиспользованные V-UTXO. Вряд ли возможно реализовать это полностью бездоверительным (trustless) образом, так как пользователю, скорее всего, потребуется некоторая информация от ASP, чтобы потратить свои V-UTXO в новом раунде, но это могло бы устранить возможность для получения финансовой выгоды ASP от мошенничества против пользователей, находящихся офлайн.

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

Как и с Lightning, экономика оплаты комиссии в блокчейне и фактическая стоимость V-UTXO после вычета комиссий определяют, соответствует ли использование Ark нашему определению L2 через односторонний вывод или же мошенничество не приносит выгоды ASP. Мы обсудим это подробнее, когда будем рассматривать шаблон проектирования дерева txout.

Validity Rollup

Большой класс сайдчейн-подобных конструкций, которые обычно предлагают использовать различные формы технологии ZK-proof (доказательств с нулевым разглашением) для обеспечения соблюдения правил цепочки. Использование ZK-proof является критическим отличием технологии validity роллапов от других форм сайдчейнов: если схема ZK-доказательств работает, то корректность транзакций может быть гарантирована математически, а не за счёт доверия к третьей стороне. Аспект «нулевого разглашения» в ZK-proof на самом деле в данном случае не является обязательным: вполне допустимо, если доказательство раскроет информацию о том, что оно доказывает. Просто так сложилось, что большинство математических схем для этого класса доказательств являются zero-knowledge.

С точки зрения Биткойна, для реализации схемы validity роллапа нужны ковенанты, так как мы хотим иметь возможность создавать для схемы UTXO, которые могут быть потрачены только при соблюдении правил схемы. Это не обязательно децентрализованный процесс. Многие схемы validity роллапов на самом деле полностью централизованы; доказательство роллапа подтверждает, что централизованный последователь транзакций следовал правилам для определённой последовательности транзакций.

Что касается ковенантов… Технология доказательств с нулевым знанием (aka «с нулевым разглашением») — Zero-Knowledge Proof — всё ещё является очень новой и быстро эволюционирующей областью. Поэтому крайне маловероятно, что в Биткойн будут добавлены какие-либо опкоды, которые напрямую проверяют конкретные ZK-proof схемы. Вместо этого, обычно подразумевается, что конкретные схемы будут использовать опкоды более общего назначения, в частности OP_CAT, для проверки ZK-доказательств через скрипты. Например, StarkWare ведёт кампанию за принятие OP_CAT.

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

BitVM

BitVM — это, грубо говоря, такой способ создания lightning-канала между двумя сторонами, при котором правила lightning-канала обеспечиваются zero-knowledge доказательством. Поскольку для реализации BitVM на Биткойне не требуются ковенанты и она не может быть напрямую использована для создания L2-системы, масштабируемой за пределы ограничения в 1 UTXO на пользователя, мы здесь не будем её обсуждать.

Подробно о BitVM БитНовости писали здесь: Биткойн как дерево байтов и BitVM-2

Иерархические каналы

Иерархические каналы направлены на упрощение и удешевление ресайзинга каналов: «Иерархические каналы делают для ёмкости каналов то же, что LN делает для Биткойна». Однако они всё ещё не превышают фундаментального ограничения в 1 UTXO на пользователя. Они также не требуют никаких изменений в протоколе Биткойна. Поэтому мы здесь не будем дальше их обсуждать. Сторонникам иерархических каналов надо их просто реализовать — им не нужно чьё бы то ни было разрешение.

CoinPool

CoinPool позволяет нескольким пользователям делить один UTXO, переводить средства между различными пользователями и в одностороннем порядке их выводить. В предложении CoinPool обозначены три новых функции, активируемые через софт-форк: SIGHASH_ANYPREVOUT, SIGHASH_GROUP, позволяющая ограничивать действие подписи только определёнными UTXO, и OP_MerkleSub для проверки удаления конкретных ветвей из дерева Меркла; последнее может быть выполнено также с помощью OP_CAT.

На данный момент разработка CoinPool, похоже, застопорилась: последний коммит на сайт со спецификацией был сделан два года назад.

Enigma Network

Хотя меня даже просили рассказать об Enigma Network, кажется, что у нас нет достаточной документации, чтобы судить о том, что это на самом деле за предложение. Блог Bitfinex сделал довольно много заявлений на их счёт; страница MIT пуста. Поскольку блог не даёт чёткого представления о том, что именно здесь происходит и как, мы не будем обсуждать этот проект дальше.

Соображения по мемпулу

Текущая политика мемпула в Bitcoin Core не идеальна для L2 систем. Здесь мы рассмотрим некоторые из основных проблем мемпула, с которыми сталкиваются разработчики L2, и возможные улучшения.

Пиннинг транзакций

Атаки пиннингом транзакций относятся к различным ситуациям, когда кто-то может намеренно (или нет) затруднить включение желаемой транзакции в блок, предварительно транслировав в сеть конфликтующую транзакцию, которая не попадает в блок. Это по сути экономический эксплойт, потому что в реальной ситуации пиннинга существует некоторая желательная транзакция, от которой майнеры получили бы прибыль. В то время как конфликтующая транзакция не попадает в блок за разумное время, если вообще попадает.

Самый простой пример пиннинга заключается в том, что без полного и всеобщего доступа к опции replace-by-fee замещение транзакций может быть отключено, в результате чего мы вполне реально можем иметь транзакцию с низкой комиссией и с отключённой заменой по комиссии, которая не будет замайнена в блокчейн, но и не может быть заменена. Сегодня почти 100% хешрейта сети решили эту проблему включением RBF для всех транзакций, и по состоянию на начало сентября 2024 RBF для всех транзакций планируется включить по умолчанию в следующем релизе Bitcoin Core (после 11 лет усилий!).

Это оставляет возможность пиннинга только по правилу №3 из BIP-125 — единственную оставшуюся проблему пиннинга, актуальную для многопользовательских L2-протоколов и не исправленную в Bitcoin Core. Для справки, правило №3 из BIP-125 звучит так:

«Для замещающей транзакции требуется уплатить более высокую абсолютную комиссию (не только ставку комиссии), чем сумма комиссий всех замещаемых транзакций».

Это правило можно заэксплойтить, транслировав крупную транзакцию (или группу транзакций) с низкой комиссией, которая тратит выходы, относящиеся к многопользовательскому протоколу. Поскольку транзакция имеет низкую комиссию, она не будет своевременно замайнена в блокчейн, если вообще будет. Однако, поскольку общая комиссия высока, замещение её другой транзакцией экономически невыгодно.

Правило №3 легко исправляется с помощью replace-by-fee-rate, о котором я рассказывал здесь, и это работает во всех ситуациях. К сожалению, неясно, будет ли предложение о RBFR принято Bitcoin Core в ближайшем будущем, так как они потратили значительное количество усилий на менее эффективное частичное решение, TRUC/V3 Transactions.

Оплата комиссий: RBF, CPFP, `SIGHASH_ANYONECANPAY`, якоря и спонсорство

Поскольку ставки комиссий непредсказуемы, надёжный расчёт экономичной комиссии за предварительно подписанные транзакции представляет собой непростую задачу. Золотым стандартом при этом является использование replace-by-fee, начиная с изначально «заниженной» оценки и по необходимости заменяя транзакцию версиями с более высокой комиссией, пока она не будет включена в блок. Например, календарь OpenTimestamps использует RBF таким образом уже много лет, а LND добавили поддержку «deadline-aware» RBF в версии 0.18.

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

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

Эффективность важна, потому что неэффективность в оплате комиссий делает прямые офчейн (out-of-band) соглашения с майнерами прибыльным источником дохода для крупных майнеров. Меньшие децентрализованные майнеры не могут получать прибыль от оплаты комиссий вне сети ввиду непрактичности и малой полезности оплаты небольшому майнеру для подтверждения транзакции. Кроме того, оплата комиссий напрямую майнерам офчейн может вызывать проблемы с AML/KYC: в настоящее время большинство доступных систем оплаты комиссий вне блокчейна требуют прохождения процесса AML/KYC в той или иной форме — за исключением акселератора mempool.space, который по состоянию на август 2024 принимал lightning-платежи без создания учётной записи.

Чтобы использовать замену по комиссии напрямую в ситуациях с предподписанными транзакциями, вам нужно предварительно подписать варианты комиссий, охватывающие весь потенциальный диапазон. Хотя во многих случаях это вполне осуществимо, так как количество необходимых вариантов обычно невелико, до сих пор протокол Lightning, как и другие предлагаемые протоколы, выбирали вместо этого использовать Child-Pays-For-Parent (CPFP), обычно через якорные выходы.

1,05^75 = 1272, так что 75 вариантов комиссии с шагом 5% покрывают более чем весь диапазон исторических ставок комиссии за включение в следующий блок за всё время существования Биткойна.

Идея якорного выхода состоит в добавлении одного или нескольких выходов к транзакции с минимальной или нулевой стоимостью — с целью оплаты комиссий через CPFP, с тратой этих выходов в последующих транзакциях. Это, конечно, очень неэффективно применительно к таким протоколам, как LN, с небольшими ончейн-транзакциями, — в LN использование временного якорного выхода практически удваивает общий размер транзакции. Это не было бы настолько значимой проблемой в протоколах с более крупными транзакциями, как любые использующие OP_CAT для реализации ковенантов.

Менее очевидная проблема с якорными выходами заключается в необходимости хранить дополнительные UTXO для оплаты комиссий. В типичном «клиентском» приложении это может создавать ощутимую общую нагрузку, так как без якорных выходов зачастую нет необходимости поддерживать более одного UTXO. Действительно, вполне вероятно, что в условиях высоких комиссий некоторые из существующих потребительских lightning-кошельков уязвимы для кражи со стороны удалённого участника канала — из-за неспособности оплатить комиссии.

В некоторых случаях можно использовать для оплаты комиссии SIGHASH_ANYONECANPAY, позволяя добавлять дополнительные входы в подписанные транзакции; SIGHASH_SINGLE позволяет также добавлять новые выходы. Lightning использует это для HTLC-транзакций. В данный момент эта практика может быть уязвима для пиннинга транзакций, если применять её неосторожно, поскольку злоумышленник может добавить в транзакцию большое количество входов и/или выходов, чтобы заблокировать транзакцию с высокой суммой/низкой ставкой комиссии. Replace-by-fee-rate (RBFR) решает эту проблему; подход, используемый в TRUC/V3 транзакциях, — нет. Этот стиль оплаты комиссии не так эффективен, как RBF. Но он может быть эффективнее, чем якорные выходы.

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

Наконец, было предложено множество софт-форков для добавления в протокол Биткойна системы спонсирования комиссий. Это позволило бы транзакциям объявлять зависимости от других транзакций, так что спонсирующая транзакция могла бы быть замайнена только в том случае, если была замайнена спонсируемая транзакция (скорее всего, в том же блоке). Это могло бы быть гораздо эффективнее традиционного Child-pay-for-parent, так как спонсирующая транзакция могла бы объявить эту зависимость, используя значительно меньше вБайт, чем размер входа транзакции.

Циклическое замещение (Replacement Cycling)

Атака циклическим замещением (replacement cycling) использует замещение транзакций, чтобы попытаться заменять желаемую транзакцию второго уровня (L2) достаточно долго, чтобы вместо неё была добыта нежелательная. По сути, для атакующего атака циклическим замещением являются альтернативой техникам пиннинга транзакций, так как обе техники направлены на предотвращение майнинга желаемой, честной транзакции достаточно долго, чтобы вместо неё была замайнена нежелательная, нечестная транзакция. В отличие от атак пиннингом транзакций, атака циклическим замещением не может произойти случайно, по стечению обстоятельств.

Канонический пример рассматривается в контексте Hashed-Time-Locked контрактов (HTLC). HTLC можно представить как контракт, позволяет потратить транзакцию либо через раскрытие предобраза, либо через тайм-аут. В реальности, из-за ограниченных скриптовых возможностей Биткойна, HTLC позволяет всегда потратить транзакцию через раскрытие предобраза, а затем, после тайм-аута, дополнительно через механизм тайм-аута.

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

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

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

Паттерны функций и софт-форки

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

`OP_Expire`

Сперва разберёмся с этим. OP_Expire был предложен как простой способ устранения атаки циклическим замещением путём устранения непосредственно источника проблемы: того факта, что HTLC могут быть потрачены двумя разными способами одновременно. В контексте L2 систем это актуально для всего, что использует HTLC-подобный механизм, и, возможно, для некоторых других сценариев тоже. OP_Expire позволил бы сделать выходы транзакции нерасходуемыми после определённого момента времени, благодаря чему условия траты HTLC можно было бы сделать настоящим исключающим ИЛИ, а не «программистским ИЛИ».

Фактический софт-форк OP_Expire, скорее всего, мог бы состоять из двух функций, аналогично тому, как опкоды OP_CheckLockTimeVerify и OP_CheckSequenceVerify состоят из двух частей:

Поле с высотой экспирации для транзакций, скорее всего, реализованное средствами taproot.
Опкод OP_Expire, который проверяет, что высота экспирации установлена как минимум на желаемую высоту.

Хотя сам по себе OP_Expire едва ли можно квалифицировать как ковенант, он выглядит полезным для многих ковенант-зависимых L2 систем. Однако, его полезность может быть недостаточной, учитывая, что циклическое замещение может быть смягчено также альтруистической ретрансляцией.

Очень заметная проблема с развёртыванием и использованием OP_Expire — это реорганизации: техническое сообщество Биткойна, начиная с Сатоши, пыталось гарантировать, что протокол консенсуса Биткойна спроектирован таким образом, чтобы после глубокой реорганизации ранее замайненные транзакции могли быть включены в новые блоки. Этот принцип проектирования стремится избежать кошмарного сценария, когда сбой консенсуса приводит к крупной реорганизации, в которой большое количество подтверждённых койнов становится навсегда недействительным, и пользователи теряют деньги.

Coinbase-транзакции по своей природе связаны с блоками, в которых они существуют. Сатоши сделал эти выходы нерасходуемыми до тех пор, пока блок, в котором они содержатся, не достигнет 100 подтверждений. Сатоши также писал об этой проблеме на bitcointalk, объясняя, почему опкод OP_BLOCKNUMBER был бы опасен.

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

Значительным препятствием для внедрения срока экспирации для транзакций является достижение консенсуса по вопросу о том, является ли этот компромисс приемлемым или даже необходимым. Те типы транзакций, где OP_Expire был бы полезен, уже включают достаточно длинные тайм-ауты, в течение которых средства пользователя заморожены. Увеличение этих тайм-аутов ещё больше нежелательно. Кроме того, двойные траты всегда были другим способом аннулирования монет после реорганизации: с увеличением использования RBF и предложенным использованием якорных выходов без ключей, сделают ли транзакции с экспирацией сколько-нибудь значительную разницу?

`SIGHASH_ANYPREVOUT`

BIP-118 предлагает два новых режима хеширования подписей, ни один из которых не привязывается к конкретному расходуемому UTXO:

SIGHASH_ANYPREVOUT, который (по сути) привязывается к scriptPubKey, и
SIGHASH_ANYPREVOUTANYSCRIPT, который позволяет использовать любой скрипт.

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

SIGHASH_ANYPREVOUT также может быть полезен в случаях, когда мы хотим использовать предподписанные варианты комиссий для RBF вместе с предварительно подписанными транзакциями, поскольку тот факт, что подпись больше не зависит от конкретного txid, позволяет избежать лавинообразного увеличения вариантов комиссий. Однако текущий проект BIP-118 не рассматривает этот случай использования и может быть несовместим с ним из-за того, что SIGHASH_ANYPREVOUT также предполагается привязать к значению UTXO.

Первоначальное возражение против SIGHASH_ANYPREVOUT заключалось в том, что кошельки по неосторожности могут создать для себя проблемы, если будут использовать опкод ненадлежащим образом. Проблема в том, что как только одна SIGHASH_ANYPREVOUT подпись опубликована, её можно использовать для траты любого выхода транзакции с указанным скриптом. Таким образом, если случайно создаётся второй выход с тем же скриптом, то SIGHASH_ANYPREVOUT позволяет легко провести атаку повторного выполнения и украсть эти монеты. Однако на фоне множества других потенциальных проблем в кошельках и L2 решениях это беспокойство, похоже, отошло на второй план.

На данный момент техническое сообщество в целом положительно относится к потенциальному внедрению BIP-118. Однако, как отмечалось выше в обсуждении LN-Symmetry, существует дискуссия вокруг того, является ли основное применение BIP-118 — LN-Symmetry — действительно хорошей идеей.

`OP_CheckTemplateVerify`

Наше первое предложение по добавлению специфического для ковенантов опкода, OP_CheckTemplateVerify — или CTV, как его часто называют, — направлено на создание очень специфического, ограниченного ковенант-опкода, выполняющего одну единственную задачу: хеширование транзакции расходования определённым образом без привязки к входным UTXO и сверка полученного дайджеста с верхним элементом стека. Это позволяет заранее ограничить транзакцию расходования, без создания возможности для ограничений настоящих рекурсивных ковенантов.

Почему рекурсивные ковенанты невозможны в CTV? Из-за хеш-функций: CTV проверяет транзакцию на соответствие шаблонному хешу, и нет способа создать шаблон, содержащий CTV с хешем самого себя. (Если вы найдёте сообщение, содержащее собственный хеш SHA256, я настоятельно рекомендую поскорее продать свои биткойны, закупиться оружием, едой и боеприпасами и найти хорошую пещеру для лагеря.)

Тем не менее это не обязательно является реальным ограничением: на современных компьютерах вы можете легко хешировать цепочку хешей шаблонов CTV до глубины в десятки миллионов транзакций всего за несколько секунд. С relative nSequence таймлоками и ограниченным размером блока достижение конца такой цепочки запросто может занять тысячи лет.

Текущее предложение CTV в BIP-119 имеет только один режим хеширования, известный как DefaultCheckTemplateVerifyHash, который по сути фиксирует все аспекты транзакции в шаблонном хеше. С практической точки зрения, это означает, что во многих случаях единственным доступным механизмом оплаты комиссии будет child-pay-for-parents. Как упоминалось выше, это потенциальная проблема, поскольку делает оплату комиссии вне блокчейна нетривиальной экономией средств в случаях, когда транзакции с использованием CTV имеют небольшой размер.

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

LNHANCE

Одно из предложений по внедрению CTV заключается в том, чтобы объединить его с двумя дополнительными опкодами: OP_CheckSigFromStack(Verify) и OP_InternalKey. Проблема в том, что на момент написания документация в этом пулл-реквесте и связанных BIP’ах попросту недостаточна для аргументированного высказывания за или против этого предложения. BIP полностью лишены какого-либо обоснования того, что эти опкоды должны делать в реальных условиях, не говоря уже о подробных примерах скриптов.

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

`OP_TXHASH`

Подобно CTV, это предложение достигает функциональности нерекурсивного ковенанта путём хеширования данных из расходной транзакции. В отличие от CTV, предложение OP_TXHASH предоставляет механизм «выбора поля», позволяя гибко задавать ограничения для расходной транзакции. Эта гибкость достигает двух основных целей:

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

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

`OP_CAT`

Оператор конкатенации, который конкатенирует два верхних элемента стека и помещает результат обратно в стек. Биткойн изначально был выпущен с включённым опкодом OP_CAT. Но Сатоши тихо удалил его в 2010 году, вероятно, из-за того, что первоначальная реализация была уязвима к DoS-атакам из-за отсутствия ограничений на размер результирующего элемента скрипта. Рассмотрим следующий скрипт:

DUP CAT DUP CAT...

Без ограничения размера элемента каждая итерация DUP CAT удваивает размер верхнего элемента стека, в конечном счёте используя всю доступную память.

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

Собираете частичную, без witness-данных, транзакцию на стеке с помощью одного или нескольких вызовов OP_CAT (и любой другой логики, специфичной для ковенанта, если это необходимо).
Проверяете, что транзакция на стеке соответствует расходной транзакции.

Как оказалось, используя математику подписей Шнорра, второй шаг можно выполнить с помощью OP_CheckSig через тщательно сконструированные подписи. Однако более вероятно, что софт-форк OP_CAT будет комбинироваться с OP_CheckSigFromStack, что позволит выполнить второй шаг, проверяя, что подпись в стеке является действительной подписью для транзакции, а затем повторно использовать ту же подпись с OP_CheckSig для проверки соответствия транзакции расходования.

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

Тот факт, что нам нужно собрать транзакцию без witness-данных, является ключевым моментом: ковенант должен проверять лишь что делает транзакция — её входы и выходы — а не witness-данные (если они есть), которые фактически делают её действительной.

В пределах ограничений размера скрипта, комбинации OP_CAT и OP_CheckSigFromStack достаточно для создания многих типов ковенантов, включая рекурсивные. По сравнению с более эффективными решениями, такими как CTV, это дороже. Но разница в стоимости меньше, чем можно было бы ожидать!

Грубо говоря, использование OP_CAT для этого требует, чтобы вся часть транзакции, не связанная с witness, была помещена в стек через свидетеля. Для типичных случаев использования CTV, таких как деревья txout, расходная транзакция вообще не будет иметь witness-данных. Поскольку поле witness дисконтируется на 75%, это увеличивает нашу эффективную комиссию за транзакцию для дочерней транзакции всего на 25% — неплохо!

`OP_CAT` слишком мощный?

Это, вероятно, самое большое политическое и техническое препятствие для внедрения OP_CAT: очень трудно предсказать, какие варианты использования станут возможными благодаря этому. Выпущенного «джина» очень трудно будет загнать обратно в бутылку.

Отличный пример: утверждается, что внедрения OP_CAT достаточно для обеспечения разумно эффективной и безопасной проверки STARK средствами Bitcoin скрипта. Поскольку STARK способны доказывать чрезвычайно общие утверждения, возможность эффективной реализации STARK имеет значительные последствия, выходящие за рамки L2 систем. Это позволило бы создавать множество различных систем на основе Биткойна, и сильным аргументом против OP_CAT является то, что эти варианты использования могут в целом не быть полезными для пользователей Биткойна.

Создание вредоносного централизующего MEV (Miner Extractable Value) является ключевой потенциальной проблемой, — разработчик Bitcoin Core Мэтт Коралло оценочно называет это «MEVil» (от evil, «зло»). Вкратце, MEVil — это любая ситуация, когда крупные майнеры/пулы могут извлекать из майнинга дополнительную выгоду за счёт использования сложных стратегий майнинга транзакций — далеко за рамками простой максимизации общей суммы комиссий, — непрактичных применять для меньших майнеров и пулов. Огромная сложность потенциальных финансовых инструментов, которые могут быть созданы с помощью OP_CAT, делает исключение MEVil чрезвычайно трудной задачей. Значительный элемент MEVil уже появлялся в Биткойне из-за протоколов аукциона токенов; к счастью, этот конкретный случай был преодолён благодаря принятию полного RBF (Replace-by-Fee).

Помимо угрозы MEVil, существует множество других конкретных случаев использования OP_CAT, которые могут быть вредными. Например, предложение Drivechains, о котором я писал здесь, широко воспринимается как вредное для Биткойна. Считается, что Drivechains возможно реализовать с использованием OP_CAT. Другой пример — предложения токенов, такие как Taproot Assets. Хотя в целом невозможно предотвратить их реализацию с проверкой на стороне клиента, существуют предложения реализовать их с помощью OP_CAT таким образом, чтобы они были гораздо более привлекательны для конечных пользователей, при этом используя гораздо больше места в блоках, что потенциально может вытеснить «легитимные» биткойн-транзакции. Такие сценарии использования могут также стать источником юридических проблем из-за того, как часто протоколы токенов используются для финансового мошенничества.

Инкрементальное хеширование

В контексте ковенантов OP_CAT будет использоваться в основном для конкатенации данных, а затем их хеширования. Другой способ достичь той же цели — это использовать какой-либо инкрементальный хеширующий опкод, который принимает промежуточное состояние SHA256 и добавляет в него больше данных; сам SHA256 работает с блоками по 64 байта. Существует множество возможных вариантов дизайна инкрементальных хеширующих опкодов.

Одним из важных проектных решений является вопрос о том, следует ли отображать фактические байты промежуточного состояния на стеке в какой-либо «канонической» форме или представлять их в новом типе непрозрачного элемента стека, чьё фактическое значение нельзя напрямую поменять. SHA256 определён для конкретного, фиксированного вектора инициализации, и, по-видимому, неизвестно, сохраняются ли криптографические свойства SHA256, когда допускаются произвольные промежуточные состояния/векторы инициализации.

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

Script Revival: реактивация отключенных опкодов

OP_CAT был одним из 15 опкодов, которые Сатоши отключил. В дополнение к восстановлению OP_CAT, Расти Рассел предлагает фактически вернуть скрипт Биткойна к «оригинальному видению Сатоши», вновь включив большинство из этих опкодов, добавив некоторые ограничения для предотвращения DoS-атак и, возможно, добавив ещё несколько опкодов в рамках того же софт-форка. В частности, в этом сценарии вероятно появление OP_CheckSigFromStack.

Впервые Rusty Russell публично предложил реактивацию скриптов в докладе на конференции bitcoin++ Austin 2024. На момент подготовки поста он также работает над черновиком BIP и его реализацией.

Если OP_CAT открывает возможности для реализации (рекурсивных) ковенантов, то полное «возрождение Bitcoin Script» сделало бы возможными более сложные ковенанты — и намного более простыми средствами, — так как частями расходной транзакции можно было бы манипулировать напрямую. Например, можно представить себе скрипт ковенанта, использующий арифметические опкоды для обеспечения того, чтобы общая стоимость выходов транзакции соответствовала некоторому желаемому свойству.

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

Simplicity

Как и реактивация отключенных опкодов, Simplicity направлен на развитие L2 и ковенантов, делая возможным выполнение любых задач. В отличие от реактивации прежних опкодов, софт-форк Simplicity добавляет совершенно новый язык программирования в систему скриптов Биткойна, основанную на девяти примитивных операторах, известных как комбинаторы.

На практике Simplicity одновременно и слишком прост и вовсе не так уж прост. Примитивные комбинаторы настолько низкоуровневые, что базовые операции, такие как сложение, приходится трудоёмко реализовывать с нуля; так что чистый Simplicity на практике был бы чрезвычайно многословным. Поэтому любое реальное использование Simplicity будет опираться на систему подстановок кода, аналогичную вызовам библиотечных функций, известную как jets. Это создает практическую и политическую проблему: как решить, какие «джеты» реализовать? Скорее всего, jets будут реализованы на C++, как и любой другой опкод, требуя обновления через софт-форк для каждого нового «джета».

`OP_FancyTreeManipulationStuff`

Существует большое разнообразие относительно специализированных опкодов, предложенных для эффективных и экономичных манипуляций с деревьями для ковенант-зависимых L2. Например, Coinpools предложили TAPLEAF_UPDATE_VERIFY и OP_MERKLESUB, оба из которых манипулируют taproot-деревьями способами, необходимыми для предложения Coinpools, а авторы предложения MATT предложили опкод OP_CheckContractVerify, который, по сути, проверяет утверждения о деревьях Меркла.

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

Такая же динамика возникла бы, если бы Биткойн принял систему скриптов Simplicity. Эквивалентом опкодов в Simplicity является добавление «джетов» для часто используемых паттернов. Внедрение джетов для операций, специфичных для конкретных вариантов использования, таких как манипуляции деревьями, имеет аналогичные плюсы и минусы, как и внедрение сложных опкодов для специфичных операций.

Фондовые пулы

Все L2-системы, пытающиеся сделать так, чтобы несколько пользователей делили один UTXO, можно рассматривать как своего рода многопользовательский пул средств, где пользователи обладают неким правом на вывод своих средств. Возможно, будет также механизм для добавления средств в пул (то есть помимо создания пула с заранее внесёнными средствами).

Чтобы такой фондовый пул был полезен, он должен иметь некое «состояние распределения долей»: как делится значение txout (выхода транзакции)? Если фондовый пул должен изменяться со временем, это состояние также должно изменяться по мере добавления или удаления средств из пула. Поскольку мы строим на основе Биткойна, добавление или удаление средств из пула неизбежно будет включать трату UTXO, контролируемых пулом.

Не забывайте, что сама система консенсуса Биткойна основана на валидации изменений состояния: транзакции доказывают с помощью своих witness-данных, что изменения в состоянии UTXO-сета являются валидными; proof-of-work позволяет нам прийти к консенсусу о том, какой набор транзакций является правильным. Это означает, что фондовые пулы также будут основаны на валидации изменений состояния: при каждом изменении состояния мы доказываем каждому узлу Биткойна, что правила для фондового пула соблюдаются.

Но есть ещё один ключевой аспект бездоверительных L2 фондовых пулов: при изменении состояния фондового пула система должна автоматически публиковать достаточные данные, чтобы участники пула могли восстановить свои средства. Если это не обеспечивается, то, значит, система не гарантирует односторонний вывод средств без взаимодействия с третьими сторонами. Многие схемы на основе роллапов не обеспечивают этого: они страдают от проблем с доступностью данных, когда пользователь не может восстановить свои средства при сбое сторонних координаторов из-за отсутствия необходимых данных для создания валидной транзакции восстановления.

С учётом этих ограничений, на каких структурах данных будут строиться фонды? Неизбежно это будут деревья. Точнее, те или иные подвиды деревьев Меркла. Это должны быть деревья, потому что это практически единственная масштабируемая структура данных в компьютерных науках; и они должны быть мерклизованы, потому что это практически единственный разумный способ криптографически зафиксировать состояние дерева. Наконец, обновления дерева неизбежно будут публиковаться в блокчейне Биткойна, потому что это единственная среда публикации, используемая всеми пользователями L2, и единственная, в которой мы можем заставить пользователей публиковать информацию для перемещения монет. И потому что любая реализация ковенанта потребует частей дерева для проверки соблюдения правил ковенанта.

Итак, с теорией на высоком уровне разобрались. Как это на практике переводится в скрипты и транзакции Биткойна?

Отдельные предварительно подписанные транзакции

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

Единственный необходимый здесь «ковенант» — самый базовый: предварительно подписанная транзакция.

Деревья выходов транзакций

Следующий, более сложный, паттерн проектирования, который мы видим в фондовых пулах, — это дерево txout (выхода транзакции). Примером может служить Ark. Здесь фондовый пул может быть разделён путём траты корневого UTXO в дереве предварительно определённых транзакций, обеспеченных простыми соглашениями, такими как предварительно подписанные транзакции или CTV, разделяя значение этого UTXO на всё меньшие и меньшие суммы, пока не будут достигнуты конечные узлы в листьях дерева, которые могут быть потрачены законными владельцами.

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

Так какие возможности может предоставить дерево txout? Опять же, Ark является отличным примером: мы не хотим, чтобы ради погашения ончейн одного V-UTXO приходилось записывать в блокчейн каждый V-UTXO. При использовании древовидной структуры процесс погашения может вместо этого разбивать дерево на более мелкие части, пока нужный V-UTXO не будет записан в блокчейн.

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

Масштабируемость деревьев txout имеет интересные экономические эффекты. Стоимость первого V-UTXO, помещённого в блокчейн в фондовом пуле с n V-UTXO, примерно в log₂(n) раз дороже, чем одна транзакция, так как в блокчейн должны быть добавлены log₂(n) уровней разделённых транзакций. Однако, как только первый V-UTXO помещён в блокчейн, последующие V-UTXO становятся дешевле для погашения, потому что кто-то уже оплатил стоимость включения промежуточных транзакций в блок.

Помните, что общее количество элементов в бинарном дереве с n листьев равно 2n. Это означает, что для размещения всех V-UTXO в блокчейне, общая стоимость такой операции через дерево txout будет лишь небольшим кратным общей стоимости выполнения этого в одной транзакции. Удивительно эффективно!

Или нет… Если совокупный объём погашений фондового пула достаточно значителен, это создать существенный спрос на блокчейн-пространство. А поскольку место в блоках — это система спроса и предложения, при высоком спросе в какой-то момент комиссии за транзакции неизбежно вырастут. В экстремальном сценарии вполне возможно создать деревья txout настолько развесистые и глубокие, что фактическое погашение каждого V-UTXO в дереве станет экономически нецелесообразным.

Открытый вопрос при использовании деревьев txout: кто оплачивает комиссии и как. Одно из очевидных решений — использовать безключевой якорный выход в листовых транзакциях и позволить любому, кто хочет, чтобы листовые транзакции были замайнены, оплатить комиссии через child-pay-for-parent. В некоторых сценариях использования V-UTXO могут быть потрачены сразу после создания, без задержки CSV, что позволяет использовать сами V-UTXO для добавления комиссий посредством CPFP.

Replace-by-fee сложно реализовать из-за проблем с разрешениями. Очевидным источником для взимания комиссий за RBF является V-UTXO. Но как обеспечить, чтобы только владелец мог подписать транзакцию с более высокой комиссией? Во многих случаях не очевидно, как это сделать эффективнее, чем с использованием безключевого якорного выхода. Однако если этого не сделать, возникают серьёзные проблемы для схем, используемых кошельками конечных пользователей. Эти пользователи могут не иметь UTXO для выполнения CPFP, если сами V-UTXO нельзя потратить немедленно.

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

Если это так, то очевидно, что данная система не соответствует нашим критериям L2 для малых V-UTXO.

Схемы на основе баланса

Машина состояний дерева txout остаётся относительно простой: фондовый пул либо существует, либо расходуется для создания двух или более меньших фондовых пулов. При использовании более продвинутых ковенантов мы могли бы рассматривать фондовый пул как динамический баланс, позволяющий добавлять и вычитать средства.

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

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

Интересно, что, как и в деревьях выходов транзакций, невозможно добиться лучшего результата, чем масштабирование порядка log(n), сохраняя при этом аналогичные свойства безопасности. Почему? Предположим, что у нас есть гипотетический опкод OP_ZKP, который с помощью сложных математических методов требует всего 32 байта для доказательства любого утверждения. Хотя это zk-доказательство могло бы подтвердить, что меркелизованная структура данных была изменена в соответствии с правилами L2 системы, оно не смогло бы предоставить данные, необходимые следующему пользователю для внесения изменений в состояние. Это не соответствует нашему предпочтительному критерию обеспечения одностороннего и независимого от внешних условий вывода средств: в лучшем случае только один пользователь мог бы осуществить безусловный вывод. Но последующие пользователи не смогли бы этого сделать.

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

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

Наконец, обратите внимание на возможность комбинирования деревьев выходов транзакций и подхода, основанного на балансе. Если используемая структура данных является деревом выходов транзакций, то средства могут быть добавлены в дерево выхода транзакции путём траты выхода и внесения новых средств с помощью скрипта ковенанта, верифицирующего фактическое добавление средств в дерево выходов транзакций. Точно так же средства могут быть удалены всеми механизмами, обычно доступными для дерева выхода транзакции. Advanced Ark является примером этой категории схем.

Объём данных о сбоях

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

Максимальная ёмкость блока во всех децентрализованных (и централизованных) блокчейнах ограничена техническими параметрами. В Биткойне максимальный размер блока таков, что Биткойн работает практически на полную мощность ~100% времени. Поскольку майнинг Биткойна функционирует как аукционная система, продающая место в блоке тому, кто предложит наибольшую цену, на практике это означает, что минимальная комиссия за транзакцию, чтобы она была включена в блок, увеличивается и уменьшается в зависимости от текущего спроса.

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

Были предложены различные атаки, где эта ситуация намеренно провоцируется в Lightning, такие как flood-and-loot и атака массового выхода. Поскольку пропускная способность блокчейна Биткойна разделяется между всеми вариантами его использования, возможны и атаки между различными системами второго уровня: например, провоцирование массового выхода из Ark для увеличения прибыли от lightning-каналов.

L2, разделяющие UTXO между несколькими пользователями, по своей природе могут усугубить эти проблемы, так как в случае сбоя спрос на место в блоке в наихудшем случае будет пропорционально выше. До сих пор мы не наблюдали масштабных сбоев в Lightning Network, которые потребовали бы одновременного закрытия большого количества каналов. Существует веский аргумент в пользу того, что нам следует накопить дополнительный операционный опыт с Lightning с его масштабированием до примерно 1-UTXO-на-пользователя, прежде чем расширять пределы дальше с помощью схем разделения UTXO.

Во-вторых, перед широким внедрением новых схем обмена UTXO необходимо тщательно изучить потенциальную прибыльность атак в периоды высокого спроса на блокспейс. Например, в системе, подобной Ark, где ASP может выкупать средства, используя значительно меньше блокчейн-ресурсов, чем другие участники, может оказаться выгодным намеренное повышение комиссий с последующим изъятием средств, которые невозможно рентабельно вывести в одностороннем порядке. Такое мошенничество нарушает условия, необходимые для создания полноценной L2 системы.

Consensus Cleanup: очистка консенсуса

Есть ряд аспектов, которые Сатоши реализовал неправильно в первоначальном протоколе Биткойна. К ним относятся уязвимости к DoS-атакам через скрипты, атака timewarp и проблемы с деревом Меркла. Ранее уже было исправлено несколько других уязвимостей консенсуса с помощью софт-форков, таких как переход к оценке nLockTime на основе медианного времени в прошлом и попытка исправить проблему с дублирующимися txid.

Последний софт-форк, Taproot, имел относительно спорный процесс внедрения, занявший довольно много времени. Аргумент в пользу проведения в первую очередь софт-форка для «очистки» консенсуса — до включения новых опкодов или функций для новых типов L2, — заключается в том, что мы получим более четкое представление о готовности широкого сообщества внедрить то, что должно быть относительно бесспорным софт-форком, приносящим пользу всем участникам.

Тестирование софт-форк-зависимых L2

Разработчикам нет нужды ждать активации софт-форка, чтобы протестировать свои идеи. Один из особенно сложных подходов, используемых разработчиками Ark в covenant-less Ark, заключается в симуляции необходимых им ковенантов с помощью предварительно подписанных транзакций. Это позволяет им тестировать идеи Ark с реальными биткойнами в основной сети, с теми же характеристиками доверия, которые ожидается достичь с помощью ковенантов. Компромисс заключается в том, что covenant-less Ark требует, чтобы все участники были онлайн для подписания предварительно подписанных транзакций. Поскольку clArk работает с реальными биткойнами, он может оказаться достаточно полезным для использования в производственных целях для некоторых случаев передачи, которые могут терпеть компромисс в интерактивности.

Более простой подход заключается в предположении, что определённые стороны не могут выполнять действия, предотвращаемые ковенантами. Например, если предлагаемый протокол хочет использовать CTV для обеспечения того, чтобы дерево txout было потрачено в дереве транзакций, каждое использование CTV можно заменить на NOP или CheckSig. Хотя дерево txout фактически не будет обеспечено, все фрагменты кода, взаимодействующие с деревом, и все стороны могут быть протестированы так, как если бы оно было обеспечено. И поскольку NOP и CheckSig допустимы в стандартных скриптах, протокол можно протестировать в основной сети с реальными средствами.

Потенциальные софт-форки

Какой вариант эффективнее? Здесь мы сведём вместе все основные схемы L2, которые мы проанализировали выше, и определим, какие софт-форки полезны (U) или необходимы (R) для успешной реализации этих L2. Как обсуждалось выше, OP_CAT (и, соответственно, Script Revival, включающий в себя и OP_CAT), может эмулировать все остальные софт-форки в этом списке — за исключением OP_Expire и Fee Sponsorship — поэтому, если потребности проекта наиболее эффективно удовлетворяются каким-либо другим софт-форком напрямую, мы не будем включать OP_CAT.

Мы также исключим все предложенные опкоды для манипуляций деревьями Меркла. Они слишком нишевые, слишком специфичные для конкретных узких вариантов использования, чтобы иметь сколько-нибудь значимые шансы на принятие в ближайшем будущем. В той мере, в какой эти опкоды полезны, реализация их эффектов через OP_CAT и/или Script Revival представляется гораздо более вероятной для принятия.

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

	`OP_ Expire`	`SIGHASH_ ANYPREVOUT`	CTV	`OP_CAT`	Script Revival
Lightning	U	U	U
Channel Factories	U		U
LN-Symmetry	U	R
Ark	U		R
Advanced Ark	U		U		R
Validity Rollups				R	U

CTV (OP_CheckTemplateVerify) здесь явный победитель, за ним следует SIGHASH_ANYPREVOUT (OP_Expire полезен для многих вещей, решая проблему циклического замещения, но не является необходимым). CTV побеждает, потому что множество вещей вписывается в паттерн «убедитесь, что расходная транзакция соответствует этому шаблону»; даже конструкции OP_CAT могут эффективно использовать CTV.

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

И если кому-то интересно моё мнение, то я бы предложил провести софт-форк Consensus Cleanup, а вслед за ним CTV.

Подписывайтесь на BitNovosti в Telegram!
Делитесь вашим мнением об этой статье в комментариях ниже.

Источник