Ограничения Биткойна: новое направление для Программируемости

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

"Ограничительные условия"(covenants) этот концепт вызвал многолетние дискуссии среди разработчиков. Кроме OP_CAT, существуют различные технические решения для реализации ограничительных условий, такие как OP_CTV, APO, OP_VAULT и другие. Итак, что такое "ограничительные условия" Биткойна? Почему они вызывают такой широкий и продолжительный интерес? Какую Программируемость они могут принести Биткойну? Каковы принципы их проектирования? В данной статье будет представлено общее введение и обсуждение этих вопросов.

Что такое "ограничительные условия"

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

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

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

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

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

Применение

Убедитесь в наказании за Staking

Интуитивным примером условий ограничения является сделка по штрафам в стейкинге Биткойн от Babylon.

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

1. Нормальное завершение: через определенное время пользователь может разблокировать и завершить процесс unstake с помощью своей подписи.

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

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

После реализации ограничительных условий, таких как 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) является典型例子. Он предлагает уровень исполнения для сети Lightning, позволяя любому последующему состоянию канала заменять предыдущее состояние без механизма наказания, что позволяет избежать необходимости узлов сети Lightning хранить несколько предыдущих состояний на случай злонамеренных действий противника. Eltoo предлагает способ подписи SIGHASH_NOINPUT, то есть APO(BIP-118) для достижения этого эффекта.

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

Обзор технических условий ограничения

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

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

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

Основные ограничения в проектировании условий включают:

• OP_CTV: универсальный, основанный на операционном коде, не рекурсивный
• APO: универсальный, на основе подписи, нерекурсивный
• OP_VAULT: специализированный, основанный на операциях, не рекурсивный
• OP_CAT: Универсальный, основанный на кодах операций, рекурсивный ( если в сочетании с OP_CAT )

Дизайн ограничительных условий

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

Основная причина заключается в том, что текущий скрипт Биткойн не может считывать содержимое самой транзакции, то есть "интроспекция" ( introspection ).

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

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

Базируется на операционных кодах vs Базируется на подписях

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

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

АПО

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

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

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

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

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

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

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

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

![Подробное объяснение Ковенантов: как реализовать Программируемость Биткойна?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(

) OP_CTV

OP_CHECKTEMPLATEVERIFY###CTV(, то есть BIP-119, использует улучшенные операции кода