Подробное объяснение необходимых фоновых знаний для BitVM

Авторы: Nickqiao & Faust & Shew Wang, Geek Web3

Консультант: исследовательская группа Bitlayer

Резюме:

Недавно компания Delphi Digital выпустила Биткойн отчет о техническом исследовании под названием «Рассвет Биткойн Программируемость: прокладывая путь для роллапов», в котором систематически разобрались основные концепции, связанные с Биткойн Rollup, такие как BitVM Family Bucket, OP_CAT и Covenant Restriction Clauses, Биткойн Ecosystem DA Layer, Bridge и Bitlayer, Citrea, Yona, Bob и другие четыре основных уровня Биткойна 2 с использованием BitVM.

Хотя этот доклад в целом показывает общую картину второго уровня технологии Bitcoin, он в целом довольно общий и не содержит детального описания, что делает его трудным для понимания. Geek web3 в своем докладе Delphi раскрывает более детальное исследование, пытаясь помочь большему числу людей систематически понять такие технологии, как BitVM.

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

Текст:

Несколько месяцев назад Робин Линус, глава ZeroSync, опубликовал статью под названием “BitVM: Compute Anything on Bitcoin”, в которой официально была представлена концепция BitVM, что способствовало развитию технологии второго уровня биткойна. Можно сказать, что это одно из наиболее революционных нововведений в экосистеме биткойна, которое подогрело всю экосистему биткойна второго уровня и привлекло такие звездные проекты, как Bitlayer, Citrea, BOB, придавая всему рынку живость.

Позже больше исследователей присоединились к улучшению BitVM, последовательно выпустили различные итерационные версии, такие как BitVM1, BitVM2, BitVMX, BitSNARK и т. д. Общая ситуация примерно следующая:

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

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

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

MATT и обещание: основные принципы BitVM

Сначала мы хотим подчеркнуть, что основная идея BitVM - это MATT, что означает Merkleize All The Things, что в основном означает представление сложного процесса выполнения программы через структуру хранения данных в виде дерева Меркля, чтобы каким-то образом обеспечить проверку обмана нативного биткойна.

MATT, хотя и способен выразить сложную программу и следы обработки данных, но не будет напрямую публиковать эти данные в блокчейне BTC, потому что общий объем этих данных очень велик. Схема MATT предполагает хранение данных только в Merkle-дереве вне блокчейна и публикацию только сводки (Merkle Root) верхнего уровня Merkle-дерева в блокчейне. Это Merkle-дерево в основном содержит три основных компонента:

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

В рамках MATT-схемы только крайне маленький корень Меркля хранится в блокчейне, а полный набор данных, содержащийся в дереве Меркля, хранится вне блокчейна, что использует подход, называемый ‘обязательство’ (Commitment). Здесь объясняется, что такое ‘обязательство’ (Commitment).

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

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

С помощью обязательств (Commitment) второй уровень может сжимать и обрабатывать большие объемы данных, публикуя только свои ‘обязательства’ на цепочке биткойна. Конечно же, следует обеспечить возможность наблюдения за полным набором данных, опубликованным вне блокчейна.

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

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

Конкретные схемы обязательств могут иметь различные формы, такие как: деревья Меркла, PIOPs (различные алгоритмы ZK), хэш-функции

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

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

4. Вызовы и наказания: Когда валидатор обнаруживает ошибки в данных, предоставленных поставщиком данных, он непосредственно проверяет эти данные в блокчейне (перед этим необходимо разделить эти данные на отдельные части), так работает доказательство мошенничества. Если результат проверки показывает, что поставщик данных действительно предоставил недействительные данные вне блокчейна, его активы будут отобраны его валидаторами.

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

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

Что такое скрипт Bitcoin

Знания, связанные с биткойном, сложнее понять, чем с эфиром, даже базовые действия по переводу включают в себя ряд концепций, включая неизрасходованный вывод транзакции (UTXO), скрипт блокировки (также известный как PubKey) и скрипт разблокировки (также известный как Sig). Давайте сначала разберемся с этими основными понятиями.

(Пример кода сценария биткоина, состоящего из операционных кодов, более низкого уровня, чем более высокоуровневые языки программирования)

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

БиткойнUTXO содержит два ключевых поля:

Сумма, измеряемая в единицах “Сатоши” (100 миллионов Сатоши равняются одному BTC);

Скрипт блокировки, также известный как «публичный ключ скрипта (PubKey)», определяет условия разблокировки UTXO.

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

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

(Скрипт разблокировки должен соответствовать заблокированному скрипту)

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

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

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

Биткойн не имеет дизайна мирового состояния, данные активов распределены в прошлых блоках (то есть данные нераспределенных UTXO хранятся отдельно в выходных данных каждой транзакции).

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

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

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

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

Кроме того, блокировочный скрипт UTXO (Locking) может быть настраиваемым: вы можете установить UTXO как “разблокируемый владельцем определенного адреса биткойнов”, при этом владелец адреса должен предоставить цифровую подпись и открытый ключ (P2PKH). В типе транзакции Pay-to-Hash (P2SH) вы можете добавить Хэш в блокировочный скрипт UTXO. Любой, кто может предоставить оригинал сценария, соответствующий этому Хэшу, и выполнить предварительно установленные условия в оригинале сценария, может разблокировать UTXO. Сценарий Taproot, который используется в BitVM, использует функции, аналогичные P2SH.

Как вызвать скрипт Bitcoin

Здесь мы сначала рассмотрим случай P2PKH для объяснения способа активации биткойн-скрипта, только понимая его способ активации, можно понять более сложные Taproot и BitVM. P2PKH полностью расшифровывается как “Pay to Public Key Hash”. В этом сценарии в заблокированном скрипте UTXO будет установлен хеш открытого ключа, для разблокировки необходимо представить соответствующий открытый ключ для этого хеша, что в основном соответствует обычной идее передачи биткойнов.

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

Дополнительно, в схеме P2PKH, когда узел биткойна получает транзакцию, он объединяет подпись Sig, предоставленную пользователем, с заблокированным публичным ключом Pubkey UTXO, который требуется разблокировать, и выполняет их в среде выполнения BTC-скрипта. На рисунке ниже показан результат объединения до выполнения:

Возможно, читатели не знакомы с окружением выполнения сценариев BTC, здесь мы дадим краткое введение. Во-первых, сценарий BTC содержит два элемента:

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

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

Операционные коды DUP, HASH160, EQUALVERIFY и т. д., указанные в скрипте блокировки справа на рисунке, отвечают за хеширование открытого ключа, переданного в разблокировочном скрипте слева, и сравнение его с предопределенным хешем открытого ключа в скрипте блокировки. Если они совпадают, это означает, что загруженный в разблокировочный скрипт открытый ключ соответствует предопределенному хешу открытого ключа в скрипте блокировки, и это проходит первую проверку.

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

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

(Эта картинка является динамической: схема разблокирования биткойна в P2PKH только для приватного ключа)

Источник: **

Конечно, в сети Bitcoin поддерживается несколько типов транзакций, не только Pay to public key/public key hash, но и P2SH (Pay to hash) и т. д., все зависит от того, каким образом настроен пользовательский скрипт блокировки при создании UTXO.

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

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

Здесь нужно объяснить одну вещь: в блокчейне Биткойна (Блок) не записывается прямая связь между UTXO и адресами. Он только записывает то, какой открытый ключ/скрипт хеш может разблокировать UTXO. Но мы можем быстро вычислить соответствующий адрес на основе хеша открытого ключа/скрипта (то, что отображается в кошельке как набор символов).

Мы можем видеть количество биткойнов на адресе xx в интерфейсе проводника блоков и кошельках, потому что проекты проводника блоков и кошельков помогают вам анализировать эти данные, просматривая все блоки и вычисляя соответствующие ‘адреса’ на основе хеша открытого ключа / скрипта, объявленного в блокировочном скрипте, а затем показывая, сколько биткойнов есть на адресе xx.

SegWit против свидетеля

Когда мы понимаем идеи P2SH, мы приближаемся к Taproot, которому полагается BitVM. Однако перед этим мы должны понимать важный концепт: Witness и Segregated Witness.

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

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

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

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

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

Позднее было введено обновление SegWit, которое фактически полностью разъединяет идентификатор транзакции и разблокировочный скрипт, и при вычислении хэша транзакции не требуется включать данные разблокировочного скрипта. Скрипт блокировки UTXO, соответствующий обновлению SegWit, по умолчанию устанавливает операционный код под названием “OP_0” в начале в качестве метки; а соответствующий разблокировочный скрипт был переименован из Sig в Witness (свидетель).

После соблюдения правил segregated witness проблема масштабируемости транзакций будет решена должным образом, вам не нужно беспокоиться о том, что данные транзакций, отправленные узлам биткойн, будут подвергнуты мелкой настройке. Конечно, нам не нужно усложнять ситуацию, функциональность P2WSH и ранее упомянутого P2SH в существенной степени не отличается, вы можете предварительно задать хеш скрипта в блокчейне в блокировочном скрипте UTXO, а затем отправитель разблокировочного скрипта предоставляет содержимое скрипта, соответствующего хешу, на цепочку и выполняет его.

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