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

Совместно написаноДжеффри ХуиХарпер Ли

В последнее время в сообществе Bitcoin широко обсуждается возможность повторного включения опкодов, таких как OP_CAT, и Taproot Wizard привлек много внимания, запустив NFT Quantum Cats, утверждая, что им был присвоен BIP-420. Приверженцы утверждают, что включение OP_CAT позволит реализовать "завещания" и, таким образом, внедрить смарт-контракты или программирование в Bitcoin.

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

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

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

Что такое "Обязательства"?

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

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

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

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

Таким образом, довольно контринтуитивно, это приносит больше сценариев применения.

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

Гарантирование штрафов за стейкинг

Одним из наиболее интуитивных примеров ковенанта является снижение транзакции в процессе стейкинга Bitcoin в Вавилоне.

Процесс стейкинга Bitcoin в Вавилоне включает в себя отправку пользователей своих BTC на специальный сценарий на основной цепи с двумя условиями расходования:

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

Источник: Стейкинг Биткойна: Разблокировка 21 миллиона биткойнов для обеспечения экономики доказательства доли

Обратите внимание на слово "принудительно", что означает, что даже если UTXO можно разблокировать, актив можно отправить только на сжигание в другое место. Это гарантирует, что злонамеренный пользователь не сможет перевести актив обратно себе с собственной известной подписью.

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

До включения OP_CTV в Вавилоне потребуется обходной путь для эмуляции эффекта применения ковенантов путем совместной работы пользователя + комитета.

Управление перегрузкой/Масштабирование

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

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

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

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

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

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

Хранилища

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

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

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

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

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

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

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

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

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

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

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

Обзор Ковенантов

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

• Тип: общий, ограничительный
• Реализация: на основе операционного кода, на основе подписи
• Рекурсия: рекурсивная, нерекурсивная

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

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

Дизайны Заветов

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

Основная причина заключается в том, что текущие скрипты Bitcoin не могут читать саму транзакцию, что означает внутреннее рассмотрение транзакции.

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

Поэтому дизайн заветов также сосредоточен на том, как реализовать интроспекцию.

На основе опкодов против на основе подписей

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

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

APO

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

Текущий диапазон SIGHASH и его комбинации подписей для входов и выходов транзакций (источник: Mastering Bitcoin, 2-е издание)

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

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

Эта гибкость лежит в основе внедрения условий в APO:

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

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

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

Проблема с вышеуказанным процессом, однако, заключается в том, что есть dev@lists.linuxfoundation.org/msg08075.html">циклическая зависимость в вычислении, поскольку необходимо знать ввод, чтобы предварительно подписать и создать транзакцию.

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

OP_CTV

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

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

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

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

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

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

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

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

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

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

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

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

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

С момента своего предложения CTV прошел через изменение названия с COSHV в 2019 году, был назначен BIP-119 в 2020 году и появление Sapio, языка программирования, используемого для создания контракта в поддержку CTV, и получил много обсуждений, обновлений и дебатов о его вариантах активации в 2022 и 2023 годах, и по-прежнему остается одним из самых обсуждаемых предложений о мягком апгрейде в сообществе.

OP_CAT

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

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

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

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

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

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

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

Заключение

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

Техники реализации заветов, если их объединить с другими обновлениями, могут дополнительно разблокировать потенциал программирования. Например, недавнее предложение по 64-битной арифметике

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

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

Специальное спасибо

Спасибо Ajian, ФишериБендля рассмотрения и предложений!

Ссылки

• 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-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/en/topics/op_cat/
• 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

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

Будьте в курсе последних новостей от HashKey Capital -

Веб-сайт — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

утверждение:

1. Эта статья воспроизведена из [средний] , авторское право принадлежит оригинальному автору [Джеффри ХуиХарпер Ли], если у вас есть возражения к перепечатке, пожалуйста, свяжитесь с Gate Learnкоманда, и команда обработает это как можно скорее в соответствии с соответствующими процедурами.

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

3. Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в Gate.io, переведенная статья не может быть воспроизведена, распространена или использована в качестве плагиата.