Отчет об исследовании HashKey Capital: Ковенанты, программируемость Биткойна

Место работы: Руководитель отдела инвестиционных исследований HashKey Capital Джеффри ХУ, Менеджер по инвестициям HashKey Capital Харпер Л.И.

Недавно в сообществе Биткойн прошла волна дискуссий о повторном включении таких кодов операций, как OP_CAT. Taproot Wizard также привлек большое внимание, запустив NFT Quantum Cats и заявив, что получил номер BIP-420. Сторонники утверждают, что включение OP_CAT может обеспечить «заветы», смарт-контракты или программируемость Биткойна.

Если вы заметите слово «ограничения» и немного поищите, вы обнаружите, что это еще одна кроличья нора. Разработчики уже много лет обсуждают, что помимо OP_CAT существуют еще OP_CTV, APO, OP_VAULT и другие методы реализации ограничительных положений.

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

Что такое «ограничения»

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

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

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

Более строго говоря, текущий биткойн-скрипт также имеет определенные ограничения. Например, временная блокировка на основе кода операции предназначена для реализации ограничения по времени до того, как транзакция будет потрачена, путем анализа поля nLock или nSequence транзакции, но по сути это так. ограничено временными ограничениями.

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

Как ни странно, это может открыть больше сценариев применения.

Сценарии применения

Обеспечьте штрафы за стейкинг

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

Процесс размещения биткойнов в Babylon предназначен для того, чтобы пользователи отправляли свои активы BTC на специальный скрипт в основной цепочке. Условия расходов включают в себя два типа:

• Счастливый конец: через определенный период времени пользователь может разблокировать его своей подписью, что завершает процесс отмены ставки.

• Плохой конец: если пользователь совершает злые действия, такие как двойная подпись в определенной цепочке PoS, арендованной Babylon, то с помощью EOTS (извлекаемые одноразовые подписи, одноразовые извлекаемые подписи) эта часть активов может быть разблокирована. и Исполнительный субъект в сети принудительно отправляет часть активов на адрес записи (косая черта).

来源:Стейкинг биткойнов: разблокировка 21 миллиона биткойнов для обеспечения экономики Proof-of-Stake

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

Если эта функция реализована после реализации ограничений, таких как OP_CTV, коды операций, такие как OP_CTV, могут быть добавлены в ветвь «плохого конца» сценария ставок для реализации ограничений.

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

контроль перегрузок

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

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

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

Как показано на диаграмме ниже, когда спрос на пространство блока высок, проведение транзакций становится очень дорогим. Используя OP_CHECKTEMPLATEVERIFY, крупные платежные системы могут объединить все свои платежи в одну транзакцию O(1) для подтверждения. Затем, со временем, когда спрос на пространство блоков уменьшится, платежи можно будет масштабировать за пределы этого UTXO.

Источник: https://utxos.org/uses/scaling/

Этот сценарий представляет собой типичный случай применения, предложенный условием ограничения OP_CTV. Дополнительные примеры применения можно найти по адресу https://utxos.org/uses/. Помимо описанного выше контроля перегрузки, на странице перечислены ставки на софт-форк, децентрализованные варианты, приводные цепи, пакетные каналы, неинтерактивные каналы, майнинг без доверительной координации. Пулы, хранилища, лимиты безопасных хешированных контрактов с временной блокировкой (HTLCS) и т. д.

Сейф

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

Приложения класса Vault можно относительно легко создать на основе методов реализации ограничений.

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

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

• Если будет обнаружено, что эта транзакция была украдена (или была принудительно использована во время «атаки гаечного ключа»), ее можно немедленно отправить на другой безопасный адрес (более безопасное хранилище для пользователя) до того, как будет отправлена ​​транзакция вывода N блоков.

Процесс OP_VAULT, источник: BIP-345

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

Сравнение OP_VAULT и предварительно подписанных процессов хранилища, источник: BIP-345.

Более надежные и гибкие каналы состояния

В целом можно считать, что каналы состояния, включая Lightning Network, имеют почти такую ​​же безопасность, как и основная цепочка (при условии, что узлы могут наблюдать за последним статусом и обычно могут публиковать последний статус в цепочке). Однако при наличии ограничений некоторые новые идеи проектирования каналов состояния могут быть более надежными или гибкими поверх сети Lightning. К наиболее известным из них относятся Eltoo, Ark и т. д.

Eltoo (также известный как LN-Symmetry) — один из наиболее типичных примеров. Это техническое решение аналогично «L2» и предлагает уровень выполнения для сети Lightning, который позволяет любому последующему состоянию канала заменять предыдущее состояние без необходимости использования механизма штрафов. Таким образом, оно также может избежать необходимости сохранения, аналогично Lightning. Сетевые узлы. Несколько предыдущих состояний, чтобы не дать противнику совершить зло. Для достижения вышеуказанного эффекта компания Eltoo предложила метод подписи SIGHASH_NOINPUT, а именно APO (BIP-118).

Ark стремится снизить сложность входящей ликвидности и управления каналами сети Lightning. Это протокол в стиле пула соединений, в котором несколько пользователей могут принять одного поставщика услуг в качестве контрагента в течение определенного периода времени и проводить виртуальные транзакции UTXO (vUTXO) вне цепочки, но совместно использовать UTXO в цепочке для снижения затрат. Подобно хранилищу, Ark также может быть реализован в текущей сети Биткойн, однако после введения ограничений Ark может уменьшить объем необходимого взаимодействия на основе шаблонов транзакций и добиться более надежного одностороннего выхода.

Технический обзор ограничений

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

• Тип: Общий тип, специальный тип

• Метод реализации: на основе кода операции, на основе подписи.

• Рекурсия: рекурсивная, нерекурсивная.

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

Некоторые популярные конструкции ограничительных статей включают в себя:

* Рекурсия: в сочетании с OP_CAT.

Дизайн ограничений

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

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

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

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

На основе кода операции или на основе сигнатуры

Самая простая и грубая идея — добавить один или несколько кодов операций (т. е. один код операции + несколько параметров или несколько кодов операций с разными функциями) для непосредственного чтения содержимого транзакции. Это идея, основанная на кодах операций.

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

ИЛИ

SIGHASH_ANYPREVOUT (APO) — предлагаемый метод подписи Биткойн. Самый простой способ подписи — это фиксация как ввода, так и вывода транзакции, но у Биткойна также есть более гибкий способ, а именно SIGHASH, который выборочно фиксирует ввод или вывод транзакции.

Текущий диапазон сигнатур SIGHASH и его комбинаций для ввода и вывода транзакций (источник «Освоение биткойнов, 2-й»

Как показано на рисунке выше, в дополнение к ALL, который применяется ко всем данным, метод подписи NONE применяется только ко всем входам и не используется для вывода; SINGLE основан на этом и применяется только к выходам с одинаковым входным порядковым номером. Кроме того, SIGHASH также можно комбинировать. После наложения модификатора ANYONECANPAY он применим только к одному входу.

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

Эта гибкость является теоретической основой для APO для реализации ограничительных положений:

• Одна или несколько транзакций могут быть созданы заранее.

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

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

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

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

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

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

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), BIP-119, использует улучшенный подход к коду операций. Он принимает хэш обязательства в качестве параметра и требует, чтобы любая транзакция, выполняющая код операции, содержала набор выходных данных, соответствующих этому обязательству. Благодаря CTV пользователям биткойнов будет разрешено ограничивать использование своих биткойнов.

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

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

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

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

Источник: https://bitcoinops.org/en/newsletters/2019/05/29/#propose-transaction-output-commitments.

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

Источник: https://twitter.com/OwenKemeys/status/1741575353716326835

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

Мы можем продолжить приведенный выше пример с 10 получателями. Получатель может дополнительно установить свой адресный ключ на подписанный, но нешироковещательный tx и отправить его на следующий пакет адресов получателей и так далее, образуя систему, как показано на рисунке ниже. . древовидная структура. Алиса может создать изменение баланса учетной записи с участием нескольких пользователей, используя только 1 пространство блока utxo в цепочке.

Источник: https://twitter.com/OwenKemeys/status/1741575353716326835

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

Источник: https://twitter.com/OwenKemeys/status/1744181234417140076

С тех пор, как был предложен CTV, в 2019 году он сменил название на COSHV, в 2020 году ему был присвоен BIP-119, и он стал языком программирования Sapio для поддержки контрактов CTV. В 22 и 23 годах он получил множество обсуждений. обновления и обновления от сообщества. Дебаты по поводу плана активации по-прежнему являются одним из наиболее обсуждаемых предложений по обновлению софт-форка в сообществе.

ОП_КАТ

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

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

Дополнительные основы реализации также включают улучшения подписей Шнорра: условия подписи расходов сценария могут быть установлены на объединение открытого ключа пользователя и открытого одноразового номера, тогда, если подписывающая сторона захочет подписать другую транзакцию, средства будут потрачены в другом месте; использовать один и тот же одноразовый номер и вызвать утечку закрытого ключа. То есть приверженность к nonce реализуется посредством OP_CAT, тем самым обеспечивая достоверность подписанной транзакции.

Другие сценарии применения OP_CAT включают: Bistream, древовидную подпись, квантово-устойчивую подпись Лампорта, хранилище и т. д.

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

Но не приведет ли повторное включение OP_CAT к проблеме взрыва стека, упомянутой выше? Поскольку текущее предложение OP_CAT предполагает включение его только в Tapscript, что ограничивает размер каждого элемента стека не более чем 520 байтами, предыдущая проблема взрыва стека не возникнет. Есть также некоторые разработчики, которые считают, что прямой запрет Сатоши на OP_CAT может быть слишком суровым. Однако из-за гибкости OP_CAT некоторые сценарии приложений, которые могут привести к уязвимостям, в настоящее время не могут быть исчерпаны.

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

Заключение

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

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

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

Спасибо Аджиану, Фишеру и Бену за обзор и предложения по этой статье!

Справочные материалы https://utxos.org/

https://bitcoincovenants.com/

Коллекция ресурсов, связанных с ковенантами:

https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068

https://anyprevout.xyz/

BIP 345: Предложение OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/

https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final2 8.pdf

https://maltemoeser.de/paper/covenants.pdf

https://bitcoinops.org/en/topics/op_cat/

ОП_КАТ:

https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md

Уловки CAT и Шнорра: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298