В последнее время в сообществе Биткойн возникло обсуждение о повторном включении операций OP_CAT и других кодов. Taproot Wizard привлек внимание многих, выпустив Quantum Cats NFT и заявив о получении номера BIP-420. Сторонники утверждают, что включение OP_CAT позволит реализовать "ограничительные условия", что в свою очередь приведет к созданию смарт-контрактов или Программируемости для Биткойн.
Если вы обратите внимание на слово "ограничительные условия" и немного поищете, вы обнаружите, что это еще одна большая кроличья нора. Разработчики обсуждают это на протяжении многих лет, помимо OP_CAT, существуют также технологии реализации ограничительных условий, такие как OP_CTV, APO, OP_VAULT и др.
Итак, что же такое "ограничительные условия" Биткойна? Почему они привлекают столь многих разработчиков на протяжении нескольких лет? Какую Программируемость может обеспечить Биткойн? Каковы основные принципы его проектирования? В этой статье мы постараемся сделать обзорное введение и обсуждение.
Что такое "ограничительные условия"
Ограничительные условия ( Ковенанты ) являются механизмом, который позволяет устанавливать условия для будущих Биткойн-транзакций.
Текущий скрипт Биткойна также содержит ограничительные условия, например, необходимо ввести действительную подпись при расходовании, предоставить соответствующий скрипт и т.д. Однако, как только пользователь сможет разблокировать, он может потратить этот UTXO в любом месте, где он пожелает.
А ограничительные условия заключаются в том, что на основе данного ограничения по разблокировке накладываются дополнительные ограничения, например, ограничение на расходы после UTXO, что позволяет достичь эффекта, аналогичного "целевому использованию"; или другие условия входных данных, отправленных в одной транзакции и т.д.
Более строго говоря, текущий Биткойн скрипт также имеет определенные ограничения, такие как временные замки, основанные на операционных кодах, которые реализуются через поля nLock или nSequence транзакции для ограничения времени до расходования средств, но в основном они ограничиваются только временными ограничениями.
Итак, почему разработчики и исследователи должны разрабатывать эти проверки ограничений? Потому что ограничения не просто для ограничения, а для установления правил выполнения транзакций. Таким образом, пользователи могут выполнять транзакции только в соответствии с заранее установленными правилами, что позволяет завершить заранее определенные бизнес-процессы.
Поэтому довольно неинтуитивно, но это может разблокировать большее количество сценариев применения.
Сценарии применения
Убедитесь в наказаниях за Staking
Ограничительным условием является самый наглядный пример — это транзакция slash в процессе стейкинга Биткойн в Babylon.
Процесс стейкинга Биткойн в Babylon заключается в том, что пользователи отправляют свои BTC активы в специальный скрипт на основной цепи, условия траты включают два вида:
В нормальных условиях: после определенного времени пользователь может разблокировать, используя свою подпись, что означает завершение процесса unstake.
Аномальная ситуация: если пользователь совершает злонамеренные действия, такие как двойная подпись, на PoS-цепочке, арендованной у Babylon, то через EOTS(extractable one-time signatures, одноразовые извлекаемые подписи), можно разблокировать эту часть активов, и часть активов будет принудительно отправлена на адрес сжигания(slash) сетевыми исполнителями.
Обратите внимание на "принудительную отправку", это означает, что даже если этот UTXO можно разблокировать, этот актив не может быть отправлен произвольно в любое другое место, его можно только сжечь. Это необходимо для того, чтобы гарантировать, что злонамеренные пользователи не смогут заранее использовать свои известные подписи, чтобы вернуть активы себе и избежать наказания.
Эта функция, если она будет реализована после внедрения ограничительных условий, таких как OP_CTV, может быть добавлена в "ветвь исключительных случаев" скрипта стейкинга с использованием opcode, таких как OP_CTV, для реализации ограничений.
И прежде чем включить OP_CTV, Babylon должен будет использовать обходные методы, чтобы совместно с пользователями и комиссией смоделировать эффект принудительного выполнения ограничительных условий.
Управление загруженностью
В общем, загруженность означает, что когда комиссии за транзакции в сети Биткойн очень высокие, в пуле транзакций накопилось много сделок, ожидающих упаковки, поэтому, если пользователь хочет быстро подтвердить транзакцию, ему необходимо увеличить комиссию.
А в это время, если пользователь должен отправить несколько транзакций нескольким получателям, ему придется повысить комиссию, неся довольно высокие затраты. Это также соответственно приведет к дальнейшему увеличению комиссии по всему сети.
Если есть ограничительные условия, одним из решений может быть то, что отправитель может сначала пообещать провести пакетную транзакцию. Это обещание позволит всем получателям поверить, что окончательная транзакция будет выполнена, и можно дождаться низкой комиссии, чтобы отправить конкретную транзакцию.
Когда спрос на блок-пространство высок, проводить транзакции становится очень дорого. Используя OP_CHECKTEMPLATEVERIFY, крупные платежные процессоры могут агрегировать все свои платежи в одну транзакцию O(1) для подтверждения. Затем, спустя некоторое время, когда спрос на блок-пространство снижается, платежи могут быть извлечены из данного UTXO.
Этот сценарий является довольно типичным примером применения ограничения, предложенного OP_CTV.
Хранилище
Хранилище(vault) является одной из широко обсуждаемых сценариев применения в области Биткойна, особенно в рамках ограничительных условий. Поскольку в повседневной деятельности неизбежно необходимо балансировать между хранением средств и потребностями в их использовании, люди надеются на существование приложений для хранения средств: которые могут гарантировать безопасность капитала и даже в случае, если учетная запись будет взломана( и ключи доступа) будут скомпрометированы, смогут ограничить использование средств.
На основе технологий реализации ограничительных условий приложения типа хранилища можно довольно легко создать.
В качестве примера дизайна OP_VAULT: при использовании средств из хранилища необходимо сначала отправить транзакцию в блокчейн. Эта транзакция указывает на намерение использовать хранилище, то есть "trigger", и устанавливает условия:
Если всё в порядке, то вторая транзакция является окончательной транзакцией на вывод средств. После ожидания N блоков средства можно будет потратить в любом месте.
Если будет обнаружено, что эта транзакция была украдена ( или была принуждена во время "атаки с гаечным ключом" ), до отправки транзакции на вывод в N блоках, можно немедленно отправить на другой безопасный адрес ( для более безопасного хранения пользователя ).
Важно отметить, что без ограничительных условий можно создать приложение для хранения, и одним из возможных способов является подготовка подписи для будущих расходов с помощью приватного ключа, а затем его уничтожение. Однако все еще существует множество ограничений, например, необходимо обеспечить, чтобы этот приватный ключ был уничтожен (, что аналогично процессу доверенной настройки в нулевых знаниях ), сумма и комиссия должны быть заранее определены (, поскольку требуется предварительная подпись ), что приводит к недостатку гибкости и так далее.
Более надежные и гибкие каналы состояний
В общем, можно считать, что каналы состояния, включая сеть Lightning, обладают почти равной безопасности с основной цепочкой ( при условии, что узлы могут наблюдать за последним состоянием и нормально публиковать последнее состояние в основной цепочке ). Однако с введением ограничивающих условий некоторые новые идеи дизайна каналов состояния могут быть более надежными или гибкими на основе сети Lightning. Среди них наиболее известны Eltoo, Ark и другие.
Eltoo (, также известный как LN-Symmetry), является одним из наиболее типичных примеров. Эта техническая схема основана на созвучии с "L2" и предлагает уровень выполнения для сети Lightning, позволяя любому последующему состоянию канала заменять предыдущее состояние без необходимости в механизме наказания, тем самым также избегая необходимости для узлов сети Lightning сохранять несколько предыдущих состояний для предотвращения злонамеренных действий со стороны противника. Для достижения вышеуказанного эффекта Eltoo предложил способ подписи SIGHASH_NOINPUT, то есть APO(BIP-118).
А Ark призван снизить сложность, связанную с входящей ликвидностью и управлением каналами в сети Lightning. Это протокол в форме joinpool, где несколько пользователей могут в течение определенного времени принимать одного и того же поставщика услуг в качестве контрагента, проводя сделки с виртуальными UTXO(vUTXO) вне цепи, но при этом делая общим один UTXO на цепи, тем самым снижая затраты. Подобно хранилищу, Ark также может быть реализован в текущей сети Биткойн; но после введения ограничительных условий Ark может снизить необходимое количество взаимодействий на основе шаблонов транзакций, обеспечивая более децентрализованный односторонний выход.
Обзор технических условий ограничения
Из вышеупомянутых приложений видно, что ограничительные условия больше похожи на эффект, чем на какую-либо технологию, поэтому существует множество технических способов реализации. Если классифицировать, можно включить:
Тип: универсальный, специализированный
Способы реализации: на основе Opcode, на основе подписи
Рекурсия: рекурсия, нерекурсия
А именно, рекурсия означает: реализация некоторых ограничительных условий может также ограничивать следующий вывод, что позволяет ограничивать вывод следующей транзакции, достигая более глубоких торговых уровней.
Некоторые основные дизайны ограничительных условий включают:
OP_CTV: универсальный, основанный на Opcode, некорректный
OP_VAULT: специализированный, основанный на Opcode, не рекурсивный
APO: универсальный, основанный на подписи, нерекурсивный
OP_CAT: универсальный, основанный на Opcode, рекурсивный*
OP_CSFS:Универсальный, основанный на подписи, рекурсивный
*Если объединить OP_CAT
Дизайн ограничительных условий
Из предыдущего введения видно, что текущий скрипт Биткойна в основном ограничивает условия разблокировки, но не ограничивает, как этот UTXO может быть потрачен дальше. Чтобы реализовать ограничения, нам нужно переосмыслить: почему текущий скрипт Биткойна не может реализовать ограничения?
Причина в том, что текущий скрипт Биткойн не может читать содержимое самой транзакции, то есть "интроспекция" (introspection).
Если мы сможем реализовать внутреннюю проверку транзакций — проверку любого содержимого транзакции (, включая вывод ), то можно будет реализовать ограничительные условия.
Поэтому основная идея разработки ограничительных условий заключается в том, как реализовать интроспекцию.
основанный на кодах операций против основанный на подписях
Самая простая и грубая идея заключается в том, чтобы добавить один или несколько кодов операций (, то есть один код операции + несколько параметров, или несколько кодов операций ) с различными функциями, чтобы напрямую считывать содержимое транзакции. Это и есть подход, основанный на кодах операций.
А другая идея заключается в том, что можно не считывать и не проверять содержимое самой транзакции напрямую в скрипте, а использовать хэш содержимого транзакции — если этот хэш уже подписан, то достаточно изменить в скрипте, например, OP_CHECKSIG и т.д., чтобы осуществить проверку этой подписи, что позволит косвенно реализовать внутреннюю инспекцию транзакций и ограничения условий. Эта идея основана на дизайне, основанном на подписи. Основные элементы включают APO и OP_CSFS и т.д.
АПО
SIGHASH_ANYPREVOUT(APO) является предложенным способом подписи Биткойн. Самый простой способ подписи заключается в том, чтобы пообещать как входы, так и выходы транзакции, но Биткойн также предлагает более гибкий способ, а именно SIGHASH, который позволяет выборочно обещать входы или выходы в транзакции.
А SIGHASH APO подписывает только выходы, а не входные части. Это означает, что транзакции, подписанные с помощью метода APO, могут быть в
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Подробное объяснение ограничений Биткойна: открытие новой эпохи Программируемости
Подробное объяснение ограничительных условий: реализация Программируемость Биткойна
В последнее время в сообществе Биткойн возникло обсуждение о повторном включении операций OP_CAT и других кодов. Taproot Wizard привлек внимание многих, выпустив Quantum Cats NFT и заявив о получении номера BIP-420. Сторонники утверждают, что включение OP_CAT позволит реализовать "ограничительные условия", что в свою очередь приведет к созданию смарт-контрактов или Программируемости для Биткойн.
Если вы обратите внимание на слово "ограничительные условия" и немного поищете, вы обнаружите, что это еще одна большая кроличья нора. Разработчики обсуждают это на протяжении многих лет, помимо OP_CAT, существуют также технологии реализации ограничительных условий, такие как OP_CTV, APO, OP_VAULT и др.
Итак, что же такое "ограничительные условия" Биткойна? Почему они привлекают столь многих разработчиков на протяжении нескольких лет? Какую Программируемость может обеспечить Биткойн? Каковы основные принципы его проектирования? В этой статье мы постараемся сделать обзорное введение и обсуждение.
Что такое "ограничительные условия"
Ограничительные условия ( Ковенанты ) являются механизмом, который позволяет устанавливать условия для будущих Биткойн-транзакций.
Текущий скрипт Биткойна также содержит ограничительные условия, например, необходимо ввести действительную подпись при расходовании, предоставить соответствующий скрипт и т.д. Однако, как только пользователь сможет разблокировать, он может потратить этот UTXO в любом месте, где он пожелает.
А ограничительные условия заключаются в том, что на основе данного ограничения по разблокировке накладываются дополнительные ограничения, например, ограничение на расходы после UTXO, что позволяет достичь эффекта, аналогичного "целевому использованию"; или другие условия входных данных, отправленных в одной транзакции и т.д.
Более строго говоря, текущий Биткойн скрипт также имеет определенные ограничения, такие как временные замки, основанные на операционных кодах, которые реализуются через поля nLock или nSequence транзакции для ограничения времени до расходования средств, но в основном они ограничиваются только временными ограничениями.
Итак, почему разработчики и исследователи должны разрабатывать эти проверки ограничений? Потому что ограничения не просто для ограничения, а для установления правил выполнения транзакций. Таким образом, пользователи могут выполнять транзакции только в соответствии с заранее установленными правилами, что позволяет завершить заранее определенные бизнес-процессы.
Поэтому довольно неинтуитивно, но это может разблокировать большее количество сценариев применения.
Сценарии применения
Убедитесь в наказаниях за Staking
Ограничительным условием является самый наглядный пример — это транзакция slash в процессе стейкинга Биткойн в Babylon.
Процесс стейкинга Биткойн в Babylon заключается в том, что пользователи отправляют свои BTC активы в специальный скрипт на основной цепи, условия траты включают два вида:
Обратите внимание на "принудительную отправку", это означает, что даже если этот UTXO можно разблокировать, этот актив не может быть отправлен произвольно в любое другое место, его можно только сжечь. Это необходимо для того, чтобы гарантировать, что злонамеренные пользователи не смогут заранее использовать свои известные подписи, чтобы вернуть активы себе и избежать наказания.
Эта функция, если она будет реализована после внедрения ограничительных условий, таких как OP_CTV, может быть добавлена в "ветвь исключительных случаев" скрипта стейкинга с использованием opcode, таких как OP_CTV, для реализации ограничений.
И прежде чем включить OP_CTV, Babylon должен будет использовать обходные методы, чтобы совместно с пользователями и комиссией смоделировать эффект принудительного выполнения ограничительных условий.
Управление загруженностью
В общем, загруженность означает, что когда комиссии за транзакции в сети Биткойн очень высокие, в пуле транзакций накопилось много сделок, ожидающих упаковки, поэтому, если пользователь хочет быстро подтвердить транзакцию, ему необходимо увеличить комиссию.
А в это время, если пользователь должен отправить несколько транзакций нескольким получателям, ему придется повысить комиссию, неся довольно высокие затраты. Это также соответственно приведет к дальнейшему увеличению комиссии по всему сети.
Если есть ограничительные условия, одним из решений может быть то, что отправитель может сначала пообещать провести пакетную транзакцию. Это обещание позволит всем получателям поверить, что окончательная транзакция будет выполнена, и можно дождаться низкой комиссии, чтобы отправить конкретную транзакцию.
Когда спрос на блок-пространство высок, проводить транзакции становится очень дорого. Используя OP_CHECKTEMPLATEVERIFY, крупные платежные процессоры могут агрегировать все свои платежи в одну транзакцию O(1) для подтверждения. Затем, спустя некоторое время, когда спрос на блок-пространство снижается, платежи могут быть извлечены из данного UTXO.
Этот сценарий является довольно типичным примером применения ограничения, предложенного OP_CTV.
Хранилище
Хранилище(vault) является одной из широко обсуждаемых сценариев применения в области Биткойна, особенно в рамках ограничительных условий. Поскольку в повседневной деятельности неизбежно необходимо балансировать между хранением средств и потребностями в их использовании, люди надеются на существование приложений для хранения средств: которые могут гарантировать безопасность капитала и даже в случае, если учетная запись будет взломана( и ключи доступа) будут скомпрометированы, смогут ограничить использование средств.
На основе технологий реализации ограничительных условий приложения типа хранилища можно довольно легко создать.
В качестве примера дизайна OP_VAULT: при использовании средств из хранилища необходимо сначала отправить транзакцию в блокчейн. Эта транзакция указывает на намерение использовать хранилище, то есть "trigger", и устанавливает условия:
Важно отметить, что без ограничительных условий можно создать приложение для хранения, и одним из возможных способов является подготовка подписи для будущих расходов с помощью приватного ключа, а затем его уничтожение. Однако все еще существует множество ограничений, например, необходимо обеспечить, чтобы этот приватный ключ был уничтожен (, что аналогично процессу доверенной настройки в нулевых знаниях ), сумма и комиссия должны быть заранее определены (, поскольку требуется предварительная подпись ), что приводит к недостатку гибкости и так далее.
Более надежные и гибкие каналы состояний
В общем, можно считать, что каналы состояния, включая сеть Lightning, обладают почти равной безопасности с основной цепочкой ( при условии, что узлы могут наблюдать за последним состоянием и нормально публиковать последнее состояние в основной цепочке ). Однако с введением ограничивающих условий некоторые новые идеи дизайна каналов состояния могут быть более надежными или гибкими на основе сети Lightning. Среди них наиболее известны Eltoo, Ark и другие.
Eltoo (, также известный как LN-Symmetry), является одним из наиболее типичных примеров. Эта техническая схема основана на созвучии с "L2" и предлагает уровень выполнения для сети Lightning, позволяя любому последующему состоянию канала заменять предыдущее состояние без необходимости в механизме наказания, тем самым также избегая необходимости для узлов сети Lightning сохранять несколько предыдущих состояний для предотвращения злонамеренных действий со стороны противника. Для достижения вышеуказанного эффекта Eltoo предложил способ подписи SIGHASH_NOINPUT, то есть APO(BIP-118).
А Ark призван снизить сложность, связанную с входящей ликвидностью и управлением каналами в сети Lightning. Это протокол в форме joinpool, где несколько пользователей могут в течение определенного времени принимать одного и того же поставщика услуг в качестве контрагента, проводя сделки с виртуальными UTXO(vUTXO) вне цепи, но при этом делая общим один UTXO на цепи, тем самым снижая затраты. Подобно хранилищу, Ark также может быть реализован в текущей сети Биткойн; но после введения ограничительных условий Ark может снизить необходимое количество взаимодействий на основе шаблонов транзакций, обеспечивая более децентрализованный односторонний выход.
Обзор технических условий ограничения
Из вышеупомянутых приложений видно, что ограничительные условия больше похожи на эффект, чем на какую-либо технологию, поэтому существует множество технических способов реализации. Если классифицировать, можно включить:
А именно, рекурсия означает: реализация некоторых ограничительных условий может также ограничивать следующий вывод, что позволяет ограничивать вывод следующей транзакции, достигая более глубоких торговых уровней.
Некоторые основные дизайны ограничительных условий включают:
*Если объединить OP_CAT
Дизайн ограничительных условий
Из предыдущего введения видно, что текущий скрипт Биткойна в основном ограничивает условия разблокировки, но не ограничивает, как этот UTXO может быть потрачен дальше. Чтобы реализовать ограничения, нам нужно переосмыслить: почему текущий скрипт Биткойна не может реализовать ограничения?
Причина в том, что текущий скрипт Биткойн не может читать содержимое самой транзакции, то есть "интроспекция" (introspection).
Если мы сможем реализовать внутреннюю проверку транзакций — проверку любого содержимого транзакции (, включая вывод ), то можно будет реализовать ограничительные условия.
Поэтому основная идея разработки ограничительных условий заключается в том, как реализовать интроспекцию.
основанный на кодах операций против основанный на подписях
Самая простая и грубая идея заключается в том, чтобы добавить один или несколько кодов операций (, то есть один код операции + несколько параметров, или несколько кодов операций ) с различными функциями, чтобы напрямую считывать содержимое транзакции. Это и есть подход, основанный на кодах операций.
А другая идея заключается в том, что можно не считывать и не проверять содержимое самой транзакции напрямую в скрипте, а использовать хэш содержимого транзакции — если этот хэш уже подписан, то достаточно изменить в скрипте, например, OP_CHECKSIG и т.д., чтобы осуществить проверку этой подписи, что позволит косвенно реализовать внутреннюю инспекцию транзакций и ограничения условий. Эта идея основана на дизайне, основанном на подписи. Основные элементы включают APO и OP_CSFS и т.д.
АПО
SIGHASH_ANYPREVOUT(APO) является предложенным способом подписи Биткойн. Самый простой способ подписи заключается в том, чтобы пообещать как входы, так и выходы транзакции, но Биткойн также предлагает более гибкий способ, а именно SIGHASH, который позволяет выборочно обещать входы или выходы в транзакции.
А SIGHASH APO подписывает только выходы, а не входные части. Это означает, что транзакции, подписанные с помощью метода APO, могут быть в