BTC является наиболее ликвидной и безопасной блокчейн-системой в настоящее время. После взрывного роста BTC экосистема привлекла множество разработчиков, которые быстро следовали за проблемами программирования BTC и проблемой масштабирования. Путем введения разных подходов, таких как ZK, DA, сайдчейн, rollup, restaking и других, экосистема BTC переживает новый подъем и становится главным сюжетом текущего бычьего рынка.
Однако во многих из этих конструкций сохраняется опыт масштабирования Смарт-контрактов, таких как ETH, и они должны полагаться на централизованный кроссчейн мост, что является уязвимым местом системы. Мало кто предлагает решение, основанное на собственных характеристиках BTC, что связано с неприятным опытом разработчиков самого BTC. По некоторым причинам он не может выполнять Смарт-контракты так же, как ETH.
Язык сценариев BTC ограничивает тьюринг-полноту в целях безопасности, что не позволяет выполнять смарт-контракты так же, как в ETH.
В то же время хранение на блокчейне BTC предназначено для простых транзакций и не оптимизировано для сложных смарт-контрактов.
Самое важное, что у BTC нет Виртуальная машина для выполнения смарт-контракт.
В 2017 году введение SegWit (SegWit) увеличило размер блока BTC; В 2021 году обновление Taproot позволило проводить проверку пакетной подписи, что облегчило и ускорило обработку транзакций (разблокирование атомных свопов, МультисигналКошелек и условные платежи). Все это позволяет сделать программирование на BTC возможным.
В 2022 году разработчик Кейси Родармор представил свою «Ordinal Theory», в которой описана схема нумерации Сатоши, которая позволяет встраивать любые данные, такие как изображения, в транзакции BTC, открывая новые возможности для непосредственного встраивания информации о состоянии и метаданных в блокчейн BTC. Это открывает новые перспективы для приложений, таких как смарт-контракты, которым требуются доступные и проверяемые данные о состоянии.
В настоящее время большинство проектов, расширяющих программную обеспеченность BTC, зависят от вторичной сети BTC (L2), что создает большие вызовы для пользователей в получении Ликвидность через кроссчейн мост, требующий доверия. Кроме того, в настоящее время у BTC отсутствует встроенная Виртуальная машина или программная обеспеченность, что представляет собой вызов для обеспечения коммуникации между L2 и L1 без дополнительного доверия.
RGB、RGB++ и сеть Arch пытаются улучшить программируемость BTC, исходя из его первоначальных свойств, предоставляя возможности для смарт-контрактов и сложных сделок различными способами:
RGB - это смарт-контракт, который проверяется клиентом вне блокчейна, изменения состояния смарт-контракта записываются в UTXO BTC. Несмотря на определенные преимущества в плане конфиденциальности, его использование громоздко и не обладает возможностью комбинирования контрактов, поэтому развитие идет очень медленно.
RGB++ - это еще один путь расширения в рамках концепции RGB, который по-прежнему основан на привязке UTXO, но путем использования самой цепи в качестве клиентского проверяющего соглашения предоставляется решение для кросс-чейн взаимодействия метаданных, что позволяет поддерживать передачу любых UTXO-структурных цепей.
Arch Network предоставляет родной Смарт-контракт решение для BTC, создает ZK Виртуальную машину и соответствующую сеть валидаторовУзел, регистрирует изменение состояния и фазы активов в BTC транзакциях путем агрегации транзакций.
RGB
RGB - это расширение идеи смарт-контрактов для сообщества BTC, которое использовалось в ранних этапах развития. Оно записывает данные о состоянии через UTXO и предоставляет важную идею для дальнейшего масштабирования BTC в его первоначальном виде.
RGB использует метод проверки вне блокчейна, который перемещает проверку передачи Токена с уровня консенсуса BTC на вне блокчейна и проверяет ее с помощью специального клиента, связанного с определенной транзакцией. Этот подход сокращает необходимость в широковещательной передаче по всей сети, улучшает конфиденциальность и эффективность. Однако такой подход к улучшению конфиденциальности имеет и отрицательные стороны. Участие только определенных Узлов, связанных с конкретной транзакцией, в процессе проверки обеспечивает повышение конфиденциальности, но делает операции сложными для третьих лиц и затрудняет разработку, что приводит к низкому пользовательскому опыту.
Кроме того, RGB вводит концепцию пломбировки одноразового использования. Каждый UTXO может быть потрачен только один раз, что эквивалентно тому, что он был заблокирован при создании UTXO и разблокирован при его использовании. Состояние смарт-контракта упаковывается через UTXO и управляется пломбировкой, что обеспечивает эффективный механизм управления состоянием.
RGB++
RGB++ - это еще один расширенный путь в рамках концепции RGB, который по-прежнему основан на привязке UTXO.
RGB++ использует UTXO-цепочку, завершенную Тьюрингом (например, CKB или другую цепочку), для обработки данных вне блокчейна и смарт-контрактов, что дополнительно повышает программирование BTC, а также обеспечивает безопасность через изоморфную привязку BTC.
RGB++ использует Тьюринг завершенную UTXO цепочку. Используя UTXO цепочку, такую как CKB, как внешнюю цепочку, RGB++ может обрабатывать данные вне блокчейна и смарт-контракты. Эта цепочка не только может выполнять сложные смарт-контракты, но также может быть связана с UTXO BTC, что увеличивает программирование и гибкость системы. Кроме того, UTXO BTC и UTXO внешней цепочки имеют изоморфную привязку, что гарантирует согласованность состояния и активов между двумя цепочками и обеспечивает безопасность транзакций.
В дополнение к этому RGB++ может быть расширен до всех Тьюринг завершенных UTXO цепей, а не ограничиваться только CKB, тем самым повышая Кроссчейн взаимодействие и Ликвидность активов. Эта поддержка нескольких цепей позволяет RGB++ взаимодействовать с любой Тьюринг завершенной UTXO цепью, увеличивая гибкость системы. Кроме того, RGB++ реализует безмостовое Кроссчейн взаимодействие с помощью изоморфного привязывания UTXO, в отличие от традиционных мостов для Кроссчейн взаимодействия, что позволяет избежать проблемы «поддельных монет» и обеспечивает подлинность и согласованность активов.
Через проверку в блокчейне через теневую цепь RGB++ упрощает процесс проверки клиентов. Пользователям нужно только проверить соответствующие транзакции в теневом блокчейне, чтобы убедиться, что вычисление состояния RGB++ правильное. Этот способ проверки в блокчейне не только упрощает процесс проверки, но и оптимизирует пользовательский опыт. Благодаря использованию Тьюринг завершенной теневой цепи, RGB++ избегает сложного управления UTXO в RGB, обеспечивая более простой и удобный опыт для пользователей.
Рекомендуемое чтение: RGB++ Layer: открывает новую эру для экосистемы BTC
Сеть Arch
Arch Network состоит из Arch zkVM и сети узлов верификации Arch, которые используют доказательства с нулевым разглашением (zk-proofs) и децентрализованную сеть проверки для обеспечения безопасности и конфиденциальности смарт-контрактов, более удобного использования по сравнению с RGB и без необходимости привязки к другой цепи UTXO, как в RGB++.
Arch zkVM использует RISC Zero ZKVM для выполнения смарт-контрактов и генерации доказательства с нулевым разглашением, которое проверяется сетью узлов, основанной на децентрализации. Система работает на основе модели UTXO и состояние смарт-контрактов упаковывается в состояние UTXO для повышения безопасности и эффективности.
Asset UTXO используется для представления BTC или других Токенов и может быть управляем путем делегирования. Сеть проверки Arch через случайно выбранного лидера Узла проверяет содержимое ZKVM и агрегирует подписи Узлов с использованием схемы подписи FROST, в конечном итоге транслируя транзакции в сеть BTC.
Arch zkVM предоставляет Виртуальную машину, Тьюринг завершенную для BTC, которая может выполнить сложный смарт-контракт. После каждого выполнения смарт-контракта Arch zkVM генерирует Доказательство с нулевым разглашением (zk-SNARKs), которые используются для проверки правильности контракта и изменения состояния.
ARCH также использует модель UTXO для BTC, где состояние и активы упакованы в UTXO и осуществляется переход состояния через концепцию одноразового использования. Данные состояния смарт-контракта записываются как состояние UTXO, а исходные активы записываются как Asset UTXO. ARCH гарантирует, что каждый UTXO может быть потрачен только один раз, обеспечивая безопасное управление состоянием.
Хотя ARCH не представляет собой инновационную структуру блокчейн, она требует сети узлов-валидаторов. В каждый период ARCH Epoch система случайным образом выбирает Leader Узел на основе его доли в системе, который отвечает за распространение информации, полученной им, на все другие валидаторы Узел в сети. Все zk-доказательства проверяются децентрализованной сетью валидаторов, которая обеспечивает безопасность и устойчивость системы к цензуре, и создают подпись для Leader Узел. Как только транзакция подписана требуемым количеством узлов, она может быть передана в сеть BTC.
Вывод
В отношении программирования BTC RGB, RGB++ и Arch Network имеют свои особенности, но они все продолжают идею привязки UTXO, свойство однократной аутентификации UTXO более подходит для записи состояния смарт-контракта.
Однако его недостатки явно проявляются в плохом пользовательском опыте, задержках и низкой производительности, сопоставимых с BTC, то есть функциональность расширена, но производительность не улучшена, что более заметно в Arch и RGB; в то время как RGB++ предлагает более хороший пользовательский опыт, вводя более высокую производительность цепочки UTXO, но также предполагает дополнительные меры безопасности.
С увеличением числа разработчиков, присоединяющихся к сообществу BTC, мы увидим больше планов масштабирования, таких как обсуждение обновления предложения op_cat. Необходимо уделять особое внимание решениям, соответствующим первоначальным свойствам BTC, и метод привязки UTXO - самый эффективный способ расширения способов программирования BTC без обновления сети BTC, при условии успешного решения проблем пользовательского опыта, станет огромным прогрессом для Смарт-контрактов BTC.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Подробное объяснение BTC Смарт-контрактов RGB, RGB++ и Arch Network
Автор: Trustless Labs; оригинальная ссылка:
BTC является наиболее ликвидной и безопасной блокчейн-системой в настоящее время. После взрывного роста BTC экосистема привлекла множество разработчиков, которые быстро следовали за проблемами программирования BTC и проблемой масштабирования. Путем введения разных подходов, таких как ZK, DA, сайдчейн, rollup, restaking и других, экосистема BTC переживает новый подъем и становится главным сюжетом текущего бычьего рынка.
Однако во многих из этих конструкций сохраняется опыт масштабирования Смарт-контрактов, таких как ETH, и они должны полагаться на централизованный кроссчейн мост, что является уязвимым местом системы. Мало кто предлагает решение, основанное на собственных характеристиках BTC, что связано с неприятным опытом разработчиков самого BTC. По некоторым причинам он не может выполнять Смарт-контракты так же, как ETH.
В 2017 году введение SegWit (SegWit) увеличило размер блока BTC; В 2021 году обновление Taproot позволило проводить проверку пакетной подписи, что облегчило и ускорило обработку транзакций (разблокирование атомных свопов, МультисигналКошелек и условные платежи). Все это позволяет сделать программирование на BTC возможным.
В 2022 году разработчик Кейси Родармор представил свою «Ordinal Theory», в которой описана схема нумерации Сатоши, которая позволяет встраивать любые данные, такие как изображения, в транзакции BTC, открывая новые возможности для непосредственного встраивания информации о состоянии и метаданных в блокчейн BTC. Это открывает новые перспективы для приложений, таких как смарт-контракты, которым требуются доступные и проверяемые данные о состоянии.
В настоящее время большинство проектов, расширяющих программную обеспеченность BTC, зависят от вторичной сети BTC (L2), что создает большие вызовы для пользователей в получении Ликвидность через кроссчейн мост, требующий доверия. Кроме того, в настоящее время у BTC отсутствует встроенная Виртуальная машина или программная обеспеченность, что представляет собой вызов для обеспечения коммуникации между L2 и L1 без дополнительного доверия.
RGB、RGB++ и сеть Arch пытаются улучшить программируемость BTC, исходя из его первоначальных свойств, предоставляя возможности для смарт-контрактов и сложных сделок различными способами:
RGB
RGB - это расширение идеи смарт-контрактов для сообщества BTC, которое использовалось в ранних этапах развития. Оно записывает данные о состоянии через UTXO и предоставляет важную идею для дальнейшего масштабирования BTC в его первоначальном виде.
RGB использует метод проверки вне блокчейна, который перемещает проверку передачи Токена с уровня консенсуса BTC на вне блокчейна и проверяет ее с помощью специального клиента, связанного с определенной транзакцией. Этот подход сокращает необходимость в широковещательной передаче по всей сети, улучшает конфиденциальность и эффективность. Однако такой подход к улучшению конфиденциальности имеет и отрицательные стороны. Участие только определенных Узлов, связанных с конкретной транзакцией, в процессе проверки обеспечивает повышение конфиденциальности, но делает операции сложными для третьих лиц и затрудняет разработку, что приводит к низкому пользовательскому опыту.
Кроме того, RGB вводит концепцию пломбировки одноразового использования. Каждый UTXO может быть потрачен только один раз, что эквивалентно тому, что он был заблокирован при создании UTXO и разблокирован при его использовании. Состояние смарт-контракта упаковывается через UTXO и управляется пломбировкой, что обеспечивает эффективный механизм управления состоянием.
RGB++
RGB++ - это еще один расширенный путь в рамках концепции RGB, который по-прежнему основан на привязке UTXO.
RGB++ использует UTXO-цепочку, завершенную Тьюрингом (например, CKB или другую цепочку), для обработки данных вне блокчейна и смарт-контрактов, что дополнительно повышает программирование BTC, а также обеспечивает безопасность через изоморфную привязку BTC.
RGB++ использует Тьюринг завершенную UTXO цепочку. Используя UTXO цепочку, такую как CKB, как внешнюю цепочку, RGB++ может обрабатывать данные вне блокчейна и смарт-контракты. Эта цепочка не только может выполнять сложные смарт-контракты, но также может быть связана с UTXO BTC, что увеличивает программирование и гибкость системы. Кроме того, UTXO BTC и UTXO внешней цепочки имеют изоморфную привязку, что гарантирует согласованность состояния и активов между двумя цепочками и обеспечивает безопасность транзакций.
В дополнение к этому RGB++ может быть расширен до всех Тьюринг завершенных UTXO цепей, а не ограничиваться только CKB, тем самым повышая Кроссчейн взаимодействие и Ликвидность активов. Эта поддержка нескольких цепей позволяет RGB++ взаимодействовать с любой Тьюринг завершенной UTXO цепью, увеличивая гибкость системы. Кроме того, RGB++ реализует безмостовое Кроссчейн взаимодействие с помощью изоморфного привязывания UTXO, в отличие от традиционных мостов для Кроссчейн взаимодействия, что позволяет избежать проблемы «поддельных монет» и обеспечивает подлинность и согласованность активов.
Через проверку в блокчейне через теневую цепь RGB++ упрощает процесс проверки клиентов. Пользователям нужно только проверить соответствующие транзакции в теневом блокчейне, чтобы убедиться, что вычисление состояния RGB++ правильное. Этот способ проверки в блокчейне не только упрощает процесс проверки, но и оптимизирует пользовательский опыт. Благодаря использованию Тьюринг завершенной теневой цепи, RGB++ избегает сложного управления UTXO в RGB, обеспечивая более простой и удобный опыт для пользователей.
Рекомендуемое чтение: RGB++ Layer: открывает новую эру для экосистемы BTC
Сеть Arch
Arch Network состоит из Arch zkVM и сети узлов верификации Arch, которые используют доказательства с нулевым разглашением (zk-proofs) и децентрализованную сеть проверки для обеспечения безопасности и конфиденциальности смарт-контрактов, более удобного использования по сравнению с RGB и без необходимости привязки к другой цепи UTXO, как в RGB++.
Arch zkVM использует RISC Zero ZKVM для выполнения смарт-контрактов и генерации доказательства с нулевым разглашением, которое проверяется сетью узлов, основанной на децентрализации. Система работает на основе модели UTXO и состояние смарт-контрактов упаковывается в состояние UTXO для повышения безопасности и эффективности.
Asset UTXO используется для представления BTC или других Токенов и может быть управляем путем делегирования. Сеть проверки Arch через случайно выбранного лидера Узла проверяет содержимое ZKVM и агрегирует подписи Узлов с использованием схемы подписи FROST, в конечном итоге транслируя транзакции в сеть BTC.
Arch zkVM предоставляет Виртуальную машину, Тьюринг завершенную для BTC, которая может выполнить сложный смарт-контракт. После каждого выполнения смарт-контракта Arch zkVM генерирует Доказательство с нулевым разглашением (zk-SNARKs), которые используются для проверки правильности контракта и изменения состояния.
ARCH также использует модель UTXO для BTC, где состояние и активы упакованы в UTXO и осуществляется переход состояния через концепцию одноразового использования. Данные состояния смарт-контракта записываются как состояние UTXO, а исходные активы записываются как Asset UTXO. ARCH гарантирует, что каждый UTXO может быть потрачен только один раз, обеспечивая безопасное управление состоянием.
Хотя ARCH не представляет собой инновационную структуру блокчейн, она требует сети узлов-валидаторов. В каждый период ARCH Epoch система случайным образом выбирает Leader Узел на основе его доли в системе, который отвечает за распространение информации, полученной им, на все другие валидаторы Узел в сети. Все zk-доказательства проверяются децентрализованной сетью валидаторов, которая обеспечивает безопасность и устойчивость системы к цензуре, и создают подпись для Leader Узел. Как только транзакция подписана требуемым количеством узлов, она может быть передана в сеть BTC.
Вывод
В отношении программирования BTC RGB, RGB++ и Arch Network имеют свои особенности, но они все продолжают идею привязки UTXO, свойство однократной аутентификации UTXO более подходит для записи состояния смарт-контракта.
Однако его недостатки явно проявляются в плохом пользовательском опыте, задержках и низкой производительности, сопоставимых с BTC, то есть функциональность расширена, но производительность не улучшена, что более заметно в Arch и RGB; в то время как RGB++ предлагает более хороший пользовательский опыт, вводя более высокую производительность цепочки UTXO, но также предполагает дополнительные меры безопасности.
С увеличением числа разработчиков, присоединяющихся к сообществу BTC, мы увидим больше планов масштабирования, таких как обсуждение обновления предложения op_cat. Необходимо уделять особое внимание решениям, соответствующим первоначальным свойствам BTC, и метод привязки UTXO - самый эффективный способ расширения способов программирования BTC без обновления сети BTC, при условии успешного решения проблем пользовательского опыта, станет огромным прогрессом для Смарт-контрактов BTC.