On-chain кошельки достигают примерно 1-1 сопоставления транзакций с транзакциями: для каждой экономической транзакции, которую выполняет пользователь, требуется примерно одна блокчейн-транзакция. Агрегации, coinjoin, cut-through-payments и т.д. немного изменяют это утверждение. Но это примерно правильно.

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

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

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

Благодарность идет в адрес Fulgur Venturesза спонсирование этого исследования. Они не имели редакционного контроля над содержанием этого сообщения и не рассматривали его перед публикацией.

Спасибо также идетДаниэла Броццони, Сара Кокс, и другие для предварительного рецензирования до публикации.

Определения

Что такое Уровень 2?

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

1. Никто не может выгодно похищать средства в системе, учитывая внутрисистемные наказания и затраты. Затраты и наказания вне системы, такие как потеря репутации, юридические последствия и т. д., не учитываются в нашем определении.
2. (Предпочтительно) Истинные владельцы средств могут односторонне вывести свои средства, за вычетом комиссии за транзакцию, без сотрудничества с какими-либо третьими сторонами.

Первый вариант необходим, потому что мы хотим, чтобы наши L2-системы могли представлять собой суммы и транзакции такой малой стоимости, которые не могут быть представлены on-chain. Например, в Lightning HTLC-контракты могут иметь слишком маленькую стоимость для представления on-chain. В этом случае стоимость HTLC добавляется к комиссии за транзакцию сделки. В то время как узел Lightning может «украсть» пылинку HTLC, закрывая канал в нужный момент, это обходится дороже.¹чем стоит HTLC, что делает кражу нерентабельной.

Тем не менее, одностороннее отзыв всегда является нашей основной целью дизайна.²

С этим определением такие вещи, как Lightning, считаются системами уровня 2. Однако системы, такие как Liquid, Cashu и Fedimint, не являются уровнями 2, потому что другая сторона или стороны контролируют ваши средства. Схемы валидации с клиентской стороны, такие как RGB, также не являются уровнями 2 по этому определению, потому что они не могут совершать сделки с BTC без доверия. Наконец, @RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains не проходит проверку, потому что сущность Statechain может похитить средства, если они не следуют протоколу.

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

... и почему им нужны более масштабируемые системы уровня 2?

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

Рекурсивные Договоры

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

Цели

Lightning - это текущая «лучшая в своем классе» система уровня 2. Однако у нее есть ограничения. А именно:

1. Масштабирование - Lightning в настоящее время требует по крайней мере одного UTXO на каждого конечного пользователя.³
2. Ликвидность - молния требует, чтобы средства были привязаны в каналах.
3. Интерактивность - Lightning требует, чтобы получатели платежей были онлайн, чтобы получать их доверительно.

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

Ограничения масштабирования Lightning

Что на практике означает "один UTXO на конечного пользователя"? Поскольку молниеносные каналы могут функционировать бесконечно, один из способов посмотреть на это - спросить, сколько новых каналов может быть создано в год⁴. Создание выходного тапрута имеет предельную стоимость 43vB; если создание канала амортизировано, с множеством каналов, созданных в одной транзакции, другие накладные расходы на транзакцию могут быть незначительными, и каждый год может быть открыто значительное количество каналов для привлечения новых пользователей. Например, предположим, что 90% емкости блока было использовано для открытия новых тапрут-каналов Lightning:

Предполагается, что Около половины всемирного населения владеют смартфоном, 4.3 миллиарда человек. Таким образом, фактически мы можем привлечь значительный процент всего населения, которое, вероятно, сможет воспользоваться каналом Lightning в течение года.

Однако каналы не длится вечно. В некоторых случаях пользователи захотят переключить кошельки, увеличить или уменьшить ёмкость канала и т. д. Самый эффективный метод изменения ёмкости канала - через сплайсинг, отличается внедрением в Кошелек Phoenix.

Как и при открытии канала, соединение также может осуществляться амортизированным способом для повышения эффективности, с несколькими операциями соединения, использующими одну транзакцию, чтобы уменьшить количество входов и выходов, необходимых для добавления и удаления средств.⁵. Таким образом, дельта-блочное пространство, необходимое для сращивания пользователей, при условии использования musig, является выходом ответвления 43vB плюс

57.5vB ключевой путь taproot, на сумму 100.5vB. Если снова предположить использование блокового пространства на уровне 90%, мы получим:

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

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

Обзор Уровня 2

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

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

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

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

Шаблон проектирования "счастливого пути" - это использование пути сценария "все стороны согласны", такого как N-of-N мультиподпись; taproot разработан специально для этой концепции, позволяя пути ключа быть N-of-N мультиподписью через musig. Предполагая, что все стороны согласны, счастливый путь позволяет эффективно (и конфиденциально) потратить монеты.

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

немного нижний уровень, чем каналы.

Молния

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

Как уже говорилось выше, ключевой характеристикой Lightning является ограничение масштабируемости для конечных пользователей из-за необходимости иметь по крайней мере одну UTXO на пользователя. Тем не менее, для «основного» элемента маршрутизации Lightning — общедоступных узлов Lightning, которые маршрутизируют подавляющее большинство транзакций — эти ограничения масштабируемости не являются большой проблемой, поскольку Lightning прекрасно функционирует, если конечных пользователей гораздо больше, чем узлов маршрутизации, потому что каждый публичный канал, используемый для маршрутизации платежей, может легко поддерживать большое количество транзакций в секунду. По этой же причине многие будущие системы L2 также ожидают участия в сети Lightning. Мы также видим это в том, что существующие не совсем L2-системы, такие как Kasu, в значительной степени полагаются на сеть Lightning, чтобы быть действительно полезными: основное использование Cashu, вероятно, заключается в отправке и получении платежей Lightning.

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

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

Фабрики каналов

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

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

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

Eltoo/LN-Symmetry

Поскольку Eltoo - ужасно запутанное имя, мы будем использовать только обновленное имя LN-Symmetry в будущем.

В то время как каналы Poon-Dryja поощряют публикацию правильного состояния в цепочке, наказывая за неправильные состояния, LN-Symmetry вместо этого позволяет обновлять неправильные состояния с помощью дополнительной транзакции. Преимущество этого метода заключается в упрощении каналов Lightning за счет упрощения штрафов. Тем не менее, это, вероятно, будет недостатком в ненадежных сценариях, поскольку штрафы, возможно, необходимы для предотвращения мошенничества.

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

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

Арк

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

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

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

Арк Экономика

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

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

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

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

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

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

Если интервал раунда составляет 4 недели, это означает, что транзакция начнется с затрат на ликвидность в размере

, в конечном итоге снижается до нуля. Предполагая, что пользователь пытается переместить свои средства на новый уровень за две недели до истечения срока, пользователь платит примерно 1,5% в год в виде ликвидационных издержек, чтобы обеспечить самостоятельное сохранение своих средств. С другой стороны, если пользователь ждет до последнего момента⁸, стоимость может быть практически нулевой, с риском пропуска срока истечения.

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

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

Загрузка Арка

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

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

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

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

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

Рассмотрим, что произойдет с V-UTXO, если владелец уйдет в оффлайн: после истечения раунда ASP необходимо вернуть средства, чтобы вернуть свою ликвидность для дальнейших раундов. Если владелец V-UTXO переходит в автономный режим, размещение этого V-UTXO в блокчейне влечет за собой значительные транзакционные издержки, поскольку ASP теперь необходимо восстанавливать средства на нескольких уровнях дерева V-UTXO. ASP может воссоздать неизрасходованные V-UTXO в новом раунде. Но с точки зрения владельцев V-UTXO это не лишено доверия, поскольку они не могут потратить эти V-UTXO, не получив данных⁹от ASP. ASP также может просто записывать неизрасходованные V-UTXO в качестве депозита. Или даже иметь политику конфискации средств!

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

Продвинутый Арк

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

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

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

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

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

Роллапы валидности

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

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

Что же касается какого завета... Технология доказательства с нулевым разглашением все еще является очень новой областью, в которой все еще часто происходят улучшения. Таким образом, крайне маловероятно, что мы увидим какие-либо опкоды, добавленные в Биткойн, которые напрямую проверяют какие-либо конкретные ZK-устойчивые схемы. Вместо этого принято считать, что конкретные схемы будут использовать более общие коды операций, в частности OP_CAT, для проверки ZK-доказательств с помощью скриптов. Например StarkWareэтоКампанииполучить принятие OP_CAT.

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

BitVM

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

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

Иерархические каналы¹⁰ стремится сделать изменение размера канала быстрым и дешевым: «Иерархические каналы делают для пропускной способности канала то же, что LN делает для биткоина». Тем не менее, они по-прежнему принципиально не превышают лимит в 1 UTXO на пользователя. Они также не требуют каких-либо изменений в протоколе Биткойна. Поэтому мы не будем обсуждать их дальше. Их сторонники должны просто выполнять их! Им не нужно наше разрешение.

CoinPool

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

В настоящее время развитие CoinPool, кажется, застыло, последний коммит на сайте спецификации был сделан два года назад.

Сеть Enigma

Когда меня попросили рассказать о сети Engima, кажется, что не хватает документации о том, что это на самом деле. Bitfinex’sзапись в блоге предъявляет много претензий; тем Страница MIT пусто. Поскольку в блоге не очень ясно, что именно должно происходить, мы не будем обсуждать это дальше.

Соображения Mempool

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

Закрепление транзакции

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

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

Таким образом, остается правило BIP-125 #3 закрепления, единственная оставшаяся проблема закрепления, которая имеет отношение к многосторонним протоколам L2 и не исправлена в Bitcoin Core. Для справки, Правило #3 BIP-125 гласит следующее:

Для оплаты более высокой абсолютной комиссии требуется замещающая транзакция (не

чем сумма комиссий, уплаченных всеми заменяемыми транзакциями.)

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

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

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

Поскольку стоимость комиссии не предсказуема, надежно и экономично платить в ситуациях, когда транзакции предварительно подписаны, затруднительно. Золотой стандарт для оплаты комиссии - использование RBF, начиная с начальной "низкой" оценки, и замена транзакции версиями с более высокой комиссией по мере необходимости, пока она не будет добыта. Например, программа календаря OpenTimestamps уже много лет использует RBF таким образом, а LND добавила поддержку для ...RBF с учетом крайних сроков в версии 0.18.

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

Эффективность важна, потому что неэффективность в оплате гонораров приводит к тому, что оплата комиссии вне диапазона выгодный источник дохода для крупных майнеров; Более мелкие, децентрализованные майнеры не могут получать прибыль от внеполосных платежей из-за непрактичности и бесполезности платить мелкому майнеру за подтверждение транзакции. Внеполосная оплата комиссий также, по-видимому, вызывает проблемы AML/KYC: в настоящее время большинство систем оплаты комиссий по внешнему каналу, фактически доступных прямо сейчас, требуют определенного процесса AML/KYC для осуществления платежа комиссии, за заметным исключением ускоритель mempool.space, который на момент написания (август 2024 года) принимает Lightning без учетной записи.

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

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

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

SIGHASH_ANYONECANPAY может быть использован для оплаты комиссий в некоторых случаях, позволяя добавлять дополнительные входные данные к подписанным транзакциям; SIGHASH_SINGLE также позволяет добавлять выходы. Lightning использует это для транзакций HTLC. На данный момент эта практика может быть уязвима для закрепления транзакций, если с ней не обращаться осторожно¹³, поскольку злоумышленник может добавить большое количество входов и/или выходов в транзакцию, чтобы создать высокую комиссию/низкую ставку комиссии. RBFR решает эту проблему; подход, используемый в транзакциях TRUC/V3, не способен решить эту проблему. Этот способ оплаты комиссии не так эффективен, как RBF. Но он может быть более эффективным, чем якорные выходы.

Наконец, было предложено несколько вариантов мягкой ветви для добавления спонсирование комиссиисистема в протоколе Bitcoin. Это позволило бы транзакциям объявлять зависимости от других транзакций, так что спонсорская транзакция может быть добыта только в том случае, если спонсируемая транзакция также была добыта (скорее всего в том же блоке). Это может быть намного эффективнее, чем традиционный CPFP, так как спонсорская транзакция может объявить эту зависимость, используя значительно меньше vbytes, чем размер входа транзакции.

Замена велосипедиста

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

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

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

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

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

Шаблоны функций и мягкие вилки

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

OP_Expire

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

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

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

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

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

В случае большой реорганизации транзакции с использованием срока действия могут стать недобываемыми из-за достижения их истекшей высоты. Предложение OP_Expire предполагает устранить эту проблему, обрабатывая выводы транзакций, использующих срок действия, аналогично транзакциям coinbase, делая их также непотратными в течение ~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 ее можно использовать для расходования любого txout с указанным скриптом. Таким образом, если случайно созданы вторые выходы с тем же скриптом, SIGHASH_ANYPREVOUT позволяет легко повторить атаку и украсть эти монеты. Однако, так как в кошельках и реализациях L2 есть так много других потенциальных ошибок, связанных с безопасностью, эту проблему, кажется, оставили в прошлом.

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

OP_CheckTemplateVerify

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

Почему невозможны рекурсивные соглашения в CTV? Потому что хэш-функции: CTV проверяет тратящую транзакцию на соответствие хешу шаблона, и нет способа¹⁸создания шаблона, содержащего CTV с хешем самого себя.

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

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

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

LNHANCE

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

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

OP_TXHASH

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

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

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

OP_CAT

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

ДУП КОТ ДУП КОТ ...

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

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

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

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

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

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

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

Слишком мощен ли OP_CAT?

Это, вероятно, является самым большим политическим и техническим препятствием для развёртывания OP_CAT: очень сложно предсказать, какие случаи использования станут возможны благодаря OP_CAT. А когда "кот" выйдет из мешка, его очень сложно вернуть.

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

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

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

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

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

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

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

Возрождение сценария

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

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

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

Простота

Подобно Script Revival, Simplicity относится к L2 и обетам, позволяя делать всё возможное. В отличие от Script Revival, в случае Simplicity мягкий форк добавит совершенно новый язык программирования в систему сценариев Bitcoin на основе девяти примитивных операторов, известных как комбинаторы.

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

OP_FancyTreeManipulationStuff

Существует большое разнообразие относительно специализированных кодов операций, которые были предложены для эффективного манипулирования деревом для предложений L2, зависящих от ковенантов. Например, Coinpools предложили и то, и другое ПРОВЕРКА_OБНОВЛЕНИЯ_TAPLEAF и OP_MERKLESUB, оба из которых манипулируют деревьями taproot таким образом, что необходимо для предложения Coinpools, и MATT Предложение предложило OP_CheckContractVerify код операции, который, по сути, проверяет утверждения о деревьях Меркла.

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

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

Пулы фондов

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

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

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

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

С учетом этих ограничений, на каких структурах данных будут основываться фондовые пулы? Неизбежно, это все какой-то вид дерева. Конкретно, какой-то вид дерева Меркла. Они должны быть деревом, потому что это практически единственная масштабируемая структура данных в компьютерной науке; они должны быть Мерклизованными, потому что это практически единственный разумный способ криптографически зафиксировать состояние дерева. Наконец, обновления дерева неизбежно будут опубликованы в блокчейне Bitcoin, потому что это единственный.публикационная средавсе пользователи уровня 2 делятся, и это единственное, на что мы можем заставить пользователей публиковать, чтобы перемещать монеты. И поскольку любая реализация договора будет нуждаться в частях дерева для проверки соблюдения правил договора.

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

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

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

Здесь требуется только самое базовое 'завещание': предварительно подписанная транзакция.

Деревья Txout

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

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

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

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

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

Помните, что общее количество элементов в бинарном дереве с

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

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

V-UTXO в дереве невозможно.

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

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

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

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

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

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

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

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

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

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

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

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

Соотношение данных о сбоях

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

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

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

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

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

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

Очистка консенсуса

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

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

Тестирование зависимого от Soft-Fork L2

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

Более простой подход заключается в том, чтобы просто притворяться, что определенные стороны не могут выполнять действия, которые бы предотвратили ковенанты. Например, если предлагаемый протокол хочет использовать 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 является гораздо более вероятным путем к принятию.

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

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

Мое личное рекомендация: проведите очистку согласования с помощью мягкого форка, а затем CTV.

Отказ:

1. Эта статья перепечатана с [петертодд], Переадресуйте оригинальный заголовок «Отстает ли дорожная карта Ethereum?», Все авторские права принадлежат оригинальному автору [petertodd]. Если есть возражения против этого перепечатывания, пожалуйста, свяжитесь сGate Learn команды, и они оперативно с этим справятся.

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

3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.