Сводка:

Недавно Delphi Digital выпустила отчет под названием «Рассвет программирования Bitcoin: Путь для Роллапов», который излагает ключевые концепции, связанные с Bitcoin Rollups, включая набор BitVM, ограничения OP_CAT и Covenant, DA-слои экосистемы Bitcoin, мосты и четыре основных решения Layer 2 с использованием BitVM: Bitlayer, Citrea, Yona и Bob. Хотя отчет дает обзор технологии Bitcoin Layer 2, он остается довольно общим и не содержит подробных описаний, что делает его сложным для понимания. Geek Web3 расширил отчет Delphi, чтобы помочь большему количеству людей систематически понять технологии, такие как BitVM.

Мы будем сотрудничать с командой исследований Bitlayer и китайским сообществом BitVM для запуска серии под названием «Приближение к BTC». Эта серия будет фокусироваться на ключевых темах, таких как BitVM, OP_CAT и мосты межблокчейнов Биткоина, нацеленных на разъяснение технологий Биткоинового уровня 2 для более широкой аудитории и подготовки почвы для большего числа энтузиастов.

Несколько месяцев назад Робин Линус, лидер ZeroSync, опубликовал статью под названием "BitVM: Вычислите что угодно на Bitcoin", официально представляя концепцию BitVM и продвигая технологию Bitcoin Layer 2. Это считается одним из наиболее революционных инноваций в экосистеме Bitcoin, вызывая значительный интерес и активность в пространстве Bitcoin Layer 2. Он привлек заметные проекты, такие как Bitlayer, Citrea и BOB, принося новую энергию на рынок. С тех пор к исследованиям присоединились более квалифицированные специалисты для улучшения BitVM, в результате чего были созданы несколько итеративных версий, таких как BitVM1, BitVM2, BitVMX и BitSNARK. Общий обзор следующий:

1. Робин Линус впервые представил белую книгу реализации BitVM в прошлом году, которая основана на концептуальной схеме логических элементов и известна как BitVM0.
2. В последующих презентациях и интервью Робин Линус неофициально представил концепцию BitVM на основе теоретического процессора, известного как BitVM1. Это аналогично системе защиты от мошенничества Optimism Cannon, и она может моделировать эффект общего процессора вне цепи с использованием биткоин-скриптов.
3. Робин Линус также предложил BitVM2, протокол безразрешительного одношагового неинтерактивного протокола доказательства мошенничества.
4. Участники Rootstock Labs и Fairgate Labs опубликовали белую книгу по BitVMX. Подобно BitVM1, они стремятся имитировать эффект общего процессора вне цепи с использованием биткоин-скриптов.

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

Для большинства людей понять BitVM и технические термины, связанные с Bitcoin Layer 2, не легко. Это требует системного понимания базовых знаний, особенно скриптов Bitcoin и Taproot. Существующие онлайн-ресурсы часто либо слишком длинны и полны несущественных деталей, либо слишком кратки, чтобы быть понятными. Мы стремимся решить эти проблемы, используя четкий и краткий язык, чтобы помочь большему числу людей понять основные концепции Bitcoin Layer 2 и построить комплексное понимание системы BitVM.

MATT и обязательства: базовая концепция BitVM

Основная концепция BitVM вращается вокруг MATT, что означает Merkleize All The Things. Этот подход использует дерево Меркля, иерархическую структуру хранения данных, для представления выполнения сложных программ. Он нацелен на обеспечение проверки мошенничества на собственной сети Bitcoin. MATT может захватывать детали сложной программы и ее действий по обработке данных, но не публикует эти обширные данные непосредственно в блокчейне Bitcoin из-за их большого размера. Вместо этого подход MATT хранит эти данные во внеблоковом дереве Меркля и публикует только корневой Меркл-дерева (верхнее краткое изложение Меркл-дерева) в блокчейне. Дерево Меркля в первую очередь содержит три ключевые компоненты:

• Код сценария смарт-контракта
• Данные, необходимые для контракта
• Трассы выполнения контракта (записи изменений памяти и регистров ЦП во время выполнения смарт-контрактов виртуальными машинами, такими как EVM)

(Простая схема дерева Меркля. Его корень Меркля вычисляется из 8 фрагментов данных внизу изображения с помощью многоуровневого хеширования)

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

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

В какой-то момент хеш данных можно использовать в качестве «обязательства» к самим данным. К другим схемам обязательств относятся обязательство KZG или дерево Меркля. В обычном протоколе доказательства мошенничества Layer2 издатель данных будет публиковать полный набор данных вне цепи и обязательство опубликовать набор данных в цепи. Если кто-то обнаружит недействительные данные в наборе данных вне цепи, обязательство данных в цепи будет оспариваться.

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

В настоящее время основные схемы BitVM, такие как BitVM0, BitVM1, BitVM2 и BitVMX, все следуют похожей абстрактной структуре:

1. Декомпозиция программ и обязательства: Изначально сложная программа разбивается на множество базовых опкодов (компиляция). Записываются следы выполнения этих опкодов (по сути, изменения состояния при запуске программы на ЦП и в памяти, известные как Trace). Все данные, включая Trace и опкоды, организованы в набор данных, и для этого набора данных генерируется обязательство. Можно использовать различные схемы обязательств, такие как деревья Меркла, PIOPs (различные ZK алгоритмы) и хэш-функции.
2. Стейкинг активов и предварительная подпись: Издатель данных и проверяющий должны заблокировать определенное количество активов на блокчейне через предварительную подпись, с определенными ограничительными условиями. Эти условия вызывают действия для потенциальных будущих событий. Если издатель данных действует злонамеренно, проверяющий может предоставить доказательства и заблокировать активы издателя данных.
3. Публикация данных и обязательств: Издатель данных публикует обязательство on-chain и полный набор данных off-chain. Проверяющий извлекает и проверяет набор данных на наличие ошибок. Каждая часть набора данных off-chain связана с on-chain обязательством.
4. Испытание и Штраф: Если верификатор находит ошибки в данных, предоставленных издателем данных, он выносит эту часть данных на цепь для прямой верификации (требующей детальных данных). Этот процесс следует логике доказательства мошенничества. Если данные подтверждаются недействительными, активы издателя данных будут забраны оспаривающим верификатором. В итоге издатель данных, Алиса, раскрывает все следы, сгенерированные во время выполнения транзакций уровня 2 вне цепи, и публикует соответствующее обязательство на цепи. Чтобы доказать, что часть данных неверна, сначала нужно показать узлу Bitcoin, что эти данные относятся к обязательству на цепи, подтверждая, что их раскрыла Алиса, а затем узел Bitcoin проверяет точность данных. Поняв общую идею BitVM, все варианты BitVM придерживаются этой базовой парадигмы. Далее мы рассмотрим некоторые ключевые технологии, используемые в этом процессе, начиная с основ Bitcoin-скриптов, Taproot и предварительных подписей.

Что такое Bitcoin Script?

Понимание биткойна может быть более сложным, чем у Ethereum, поскольку даже самые простые транзакции включают в себя несколько ключевых концепций. К ним относятся UTXO (невыполненный выход транзакции), скрипты блокировки (также известные как ScriptPubKey) и скрипты разблокировки (также известные как ScriptSig). Давайте сначала разберём эти фундаментальные концепции.

(Пример кода сценария Bitcoin состоит из более низкоуровневых операционных кодов по сравнению с языками более высокого уровня) Метод представления активов Ethereum аналогичен системам, таким как Alipay или WeChat, где каждая транзакция просто корректирует балансы различных счетов. Этот подход на основе учетных записей рассматривает балансы активов как просто числа, связанные со счетами. В отличие от этого, представление активов Bitcoin более похоже на работу с золотом, где каждый кусок золота (UTXO) помечен владельцем. Суть транзакции Bitcoin заключается в уничтожении старого UTXO и создании нового, с изменением собственности в процессе. Bitcoin UTXO включает две ключевые компоненты:

• Сумма: Измеряется в «сатоши» (один BTC равен ста миллионам сатоши);
• Скрипт блокировки (ScriptPubKey): Это определяет условия, необходимые для разблокировки UTXO. Собственность Bitcoin UTXO определяется блокирующим сценарием. Например, если вы хотите передать свой UTXO Сэму, вы инициируете транзакцию, которая уничтожает ваш UTXO и создает новый с условием «только Сэм может разблокировать». Когда Сэм хочет использовать эти биткойны, он должен представить разблокировочный сценарий (ScriptSig). В этом сценарии Сэм предоставляет свою цифровую подпись, чтобы доказать свою личность. Если разблокировочный сценарий соответствует исходному блокирующему сценарию, Сэм может разблокировать биткойны и передать их кому-то еще.

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

Конкретно, во входных данных транзакции вам нужно объявить, какие UTXO вы собираетесь разблокировать и указать "местоположение хранения" этих данных UTXO. Важно понимать, что Bitcoin и Ethereum обрабатывают это по-разному. Ethereum использует контрактные счета и Счета с Внешним Управлением (EOA) для хранения данных, с балансами активов, записанными как числа в этих счетах. Вся эта информация хранится в базе данных, называемой "состояние мира". Когда происходит транзакция, "состояние мира" непосредственно обновляет балансы конкретных счетов, что облегчает поиск данных. В отличие от этого, у Bitcoin нет "состояния мира". Вместо этого данные активов распределяются по предыдущим блокам как неизрасходованные UTXO, хранящиеся индивидуально в выходе каждой транзакции.

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

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

(Когда вы создаете транзакцию для передачи своего UTXO кому-то другому, вам необходимо указать местоположение этого UTXO в истории транзакций Биткойна, ссылаясь на хэш/идентификатор транзакции, к которому он принадлежит.) Интересно, что результаты транзакций биткоина вычисляются вне блокчейна. Когда пользователи генерируют транзакции на своих локальных устройствах, они должны заранее создать все входы и выходы, эффективно вычисляя выходные данные транзакции. Затем транзакция транслируется в сеть Bitcoin, проверяется узлами и добавляется в блокчейн. Эта модель «off-chain computation — on-chain verification» полностью отличается от модели Ethereum. На Ethereum вам нужно только указать входные параметры транзакции, а результаты транзакции рассчитываются и выводятся узлами Ethereum. Кроме того, скрипт блокировки UTXO можно настроить. Вы можете настроить UTXO так, чтобы он был «разблокирован владельцем определенного биткойн-адреса», требуя, чтобы владелец предоставил цифровую подпись и открытый ключ (P2PKH). В транзакциях Pay-to-Script-Hash (P2SH) вы можете добавить хэш скрипта в скрипт блокировки UTXO. Разблокировать UTXO может любой, кто сможет отправить скрипт, соответствующий этому хешу и выполнивший условия, указанные в скрипте. Скрипт Taproot, на который опирается BitVM, использует функции, аналогичные тем, что используются в P2SH.

Как запустить сценарий биткойна

Для понимания механизма срабатывания скриптов Bitcoin мы начнем с примера P2PKH, что означает "Pay to Public Key Hash". В этой конфигурации блокировочный скрипт UTXO содержит хэш открытого ключа, и для его разблокировки необходимо предоставить соответствующий открытый ключ. Этот механизм соответствует стандартному процессу биткоин-транзакций. В этом контексте узел биткоина должен проверить, что открытый ключ в разблокировочном скрипте совпадает с хэшем открытого ключа, указанным в блокировочном скрипте. По сути, он проверяет, что "ключ", предоставленный пользователем, подходит для "замка", установленного UTXO. Подробнее, в рамках схемы P2PKH, когда узел биткоина получает транзакцию, он объединяет разблокировочный скрипт пользователя (ScriptSig) с блокировочным скриптом (ScriptPubKey) UTXO для разблокировки, а затем выполняет этот объединенный скрипт в среде выполнения скрипта биткоина. Ниже приведено изображение объединенного результата перед выполнением:

Читатели, возможно, не знакомы со средой выполнения скриптов BTC, поэтому давайте кратко представим ее. Биткоин-скрипты состоят из двух элементов: данных и опкодов. Эти элементы помещаются в стек последовательно слева направо и выполняются в соответствии с заданной логикой для получения окончательного результата (для объяснения того, что такое стек, читатели могут обратиться к ChatGPT). В приведенном выше примере в левой части показан сценарий разблокировки (ScriptSig), предоставленный кем-либо, который включает в себя цифровую подпись и открытый ключ. В правой части показан скрипт блокировки (ScriptPubKey), который содержит ряд опкодов и данных, установленных создателем UTXO при генерации этого UTXO (достаточно понять общую идею; нам не нужно углубляться в значение каждого опкода). Коды операций в скрипте блокировки справа, такие как DUP, HASH160 и EQUALVERIFY, хэшируют открытый ключ из скрипта разблокировки слева и сравнивают его с предустановленным хэшем открытого ключа в сценарии блокировки. Если они совпадают, он подтверждает, что открытый ключ в скрипте разблокировки совпадает с хэшем открытого ключа в скрипте блокировки, проходя первую проверку. Однако есть проблема: содержимое скрипта блокировки публично видно в блокчейне, а это означает, что любой может увидеть хэш открытого ключа. Таким образом, любой желающий мог предоставить соответствующий открытый ключ и ложно выдать себя за уполномоченное лицо. Чтобы решить эту проблему, после проверки открытого ключа и хэша открытого ключа система также должна проверить, действительно ли инициатор транзакции контролирует открытый ключ, что включает в себя проверку цифровой подписи. Код операции CHECKSIG в сценарии блокировки обрабатывает эту проверку. Таким образом, по схеме P2PKH сценарий разблокировки инициатора транзакции должен включать открытый ключ и цифровую подпись. Открытый ключ должен совпадать с хэшем открытого ключа, указанным в сценарии блокировки, а цифровая подпись должна быть правильной. Эти условия должны быть выполнены для успешной разблокировки UTXO.

(Это динамическая иллюстрация: диаграмма разблокировки биткойновых скриптов в рамках схемы P2PKH
Источник: https://learnmeabitcoin.com/technical/script)

Важно отметить, что сеть Биткойн поддерживает различные типы транзакций помимо Pay to Public Key/Public Key Hash, такие как P2SH (Pay to Script Hash). Конкретный тип транзакции зависит от того, как настроен блокировочный сценарий при создании UTXO.

Важно понимать, что в соответствии со схемой P2SH скрипт блокировки может предварительно установить хэш скрипта, а скрипт разблокировки должен предоставить полное содержимое скрипта, соответствующее этому хэшу скрипта. Затем узел Биткойна может выполнить этот сценарий, и если он включает логику проверки с несколькими подписями, он эффективно включает кошельки с несколькими подписями в блокчейне Биткойна. В схеме P2SH создатель UTXO должен сообщить человеку, который будет разблокировать UTXO в будущем, о содержимом скрипта, соответствующем Script Hash. До тех пор, пока обе стороны осведомлены о содержимом скрипта, мы можем реализовать еще более сложную бизнес-логику, чем просто мультиподпись. Также стоит отметить, что блокчейн Биткоина напрямую не записывает, какие UTXO связаны с какими адресами. Вместо этого он записывает, какие UTXO могут быть разблокированы с помощью хэша открытого ключа или хэша скрипта. Тем не менее, мы можем быстро получить соответствующий адрес (строку символов, которая выглядит как тарабарщина, отображаемую в интерфейсах кошельков) из хэша открытого ключа или хэша скрипта.

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

Segregated Witness и Witness

Понимание P2SH приближает нас к Taproot, важному компоненту для BitVM. Однако перед погружением в Taproot важно понять концепцию Witness и Segregated Witness (SegWit). При рассмотрении скриптов разблокировки и блокировки, а также процесса разблокировки UTXO, выявляется проблема: цифровая подпись для транзакции включена в скрипт разблокировки. При генерации этой подписи сам скрипт разблокировки не может быть частью данных, которые подписываются (поскольку параметры, используемые для генерации подписи, не могут включать саму подпись).

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

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

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

Проще говоря, проблема пластичности транзакций возникает из-за того, что вычисление идентификатора транзакции и хэша включает данные из сценария разблокировки. Посредники, такие как узлы Биткойна, могут вносить небольшие изменения в сценарий разблокировки, в результате чего идентификатор транзакции не соответствует ожиданиям пользователя. Эта проблема связана с ранними ограничениями дизайна в Биткойне. Обновление Segregated Witness (SegWit) решает эту проблему, отделяя идентификатор транзакции от сценария разблокировки. В SegWit вычисление хэша транзакции исключает данные скрипта разблокировки. Сценарии блокировки UTXO в SegWit начинаются с кода операции "OP_0" в качестве маркера, а соответствующий скрипт разблокировки переименовывается из SigScript в Witness.

Соблюдая правила Segregated Witness (SegWit), проблема изменяемости транзакций эффективно решается, устраняя опасения относительно возможности вмешательства в данные транзакций узлами биткойна. Функциональность P2WSH (Pay to Witness Script Hash) существенно не отличается от P2SH (Pay to Script Hash). Вы можете предварительно установить хэш скрипта в блокировочном скрипте UTXO, а лицо, представляющее разблокировочный скрипт, предоставит соответствующее содержимое скрипта цепи для выполнения. Однако, если содержимое скрипта, которое вам нужно, очень большое и содержит много кода, традиционные методы могут не позволить вам представить весь скрипт в блокчейн биткойна (из-за ограничений размера блока). В таких случаях вступает в игру Taproot. Taproot позволяет сжимать содержимое скрипта on-chain, что делает возможным обработку более крупных скриптов. BitVM использует Taproot для создания более сложных решений. В следующей статье нашей серии “Подход к BTC” мы предоставим подробные объяснения Taproot, предварительной подписи и других передовых технологий, связанных с BitVM. Следите за обновлениями!

Оговорка:

1. Эта статья взята из [ Гик Web3], с авторскими правами, принадлежащими оригинальным авторам [Nickqiao & Faust & Shew Wang]. Если есть возражения против перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и команда немедленно обработает его в соответствии с соответствующими процедурами.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями авторов и не являются инвестиционными советами.
3. Другие языковые версии статьи были переведены командой Gate Learn. Без упоминанияGate.io, переведенные статьи не должны быть скопированы, распространены или украдены.