Сценарист: Никцяо, Фауст, Шью Ван, geek web3
Консультант: Исследовательская группа Bitlayer
Аннотация: Delphi Digital недавно опубликовала исследовательский отчет о технологиях, связанных со вторым уровнем биткойнов, под названием «Рассвет программируемости биткойнов: прокладывая путь для накопительных пакетов», в котором систематически разбираются основные концепции, связанные с объединенными пакетами биткойнов, такие как BitVM Family Bucket, OP_CAT. и ограничения Ковенанта, экологический уровень DA Биткойна, мост и четыре основных вторых уровня Биткойна, использующих BitVM, включая Bitlayer, Citrea, Yona и Bob.
Хотя исследовательский отчет в целом показывает общую картину технологии второго уровня Биткойна, он, как правило, относительно общий и не имеет подробного описания, что затрудняет его понимание. Geek web3 провел обширные углубленные раскопки на основе исследовательского отчета Delphi, пытаясь дать возможность большему количеству людей систематически понимать BitVM и другие технологии.
Мы совместно запустим серию колонок под названием «Приближение к BTC» совместно с исследовательской группой Bitlayer и китайским сообществом BitVM, чтобы провести долгосрочную популяризацию науки по таким ключевым темам, как BitVM, OP_CAT и межцепочные мосты Биткойн, и стремимся разочаровать Биткойн для большего числа людей. Технологии, связанные с монетами второго уровня, открывают путь для большего числа энтузиастов.
Несколько месяцев назад Робин Линус, глава ZeroSync, опубликовал статью под названием «BitVM: вычислить что-либо на биткойне», официально предлагая концепцию BitVM и продвигая прогресс технологии второго уровня биткойна. Можно сказать, что это одна из самых революционных инноваций в экосистеме Биткойн. Она взорвала всю экосистему Биткойна второго уровня, привлекла к участию такие звездные проекты, как Bitlayer, Citrea, BOB и т. д., и придала ей жизненную силу. весь рынок.
После этого больше исследователей участвовали в улучшении BitVM и последовательно запускали различные итеративные версии, такие как BitVM1, BitVM2, BitVMX и BitSNARK. Общая ситуация следующая:
Технический документ по реализации BitVM, впервые предложенный Робином Линусом в прошлом году, представляет собой реализацию BitVM, основанную на вымышленных схемах логических вентилей, называемых BitVM0;
В нескольких последующих выступлениях и интервью Робин Линус неофициально представил решение BitVM (названное BitVM1), основанное на вымышленном процессоре, которое похоже на систему защиты от мошенничества Optimism Cannon. Оно может использовать сценарии Биткойн для имитации эффектов общего назначения вне цепочки процессора. .
Робин Линус также предложил BitVM2, не требующий разрешения одношаговый неинтерактивный протокол защиты от мошенничества.
Члены Rootstock Labs и Fairgate Labs опубликовали официальный документ BitVMX, в котором, как и BitVM1, надеются эмулировать эффекты процессора общего назначения (оффчейн) с помощью биткойн-скриптов.
В настоящее время построение экосистемы разработчиков, связанных с BitVM, становится все более ясным, а итеративное улучшение периферийных инструментов также видно невооруженным глазом. По сравнению с прошлым годом сегодняшняя экосистема BitVM стала «смутно видна» с первоначального «замка». в воздухе», что также привлекает все больше и больше людей. Все больше разработчиков и венчурных капиталистов устремляются в экосистему Биткойн.
Но большинству людей нелегко понять технические термины, связанные с BitVM и Bitcoin Layer 2, поскольку вам необходимо иметь систематическое понимание основных знаний, связанных с ним, особенно таких базовых знаний, как сценарии Биткойн и знания Taproot. Справочные материалы, доступные сейчас в Интернете, либо слишком длинные и полны ерунды, либо объяснения недостаточно полны, из-за чего люди кажутся понимающими, но не понимающими. Мы стремимся решить вышеуказанные проблемы и стремимся использовать максимально ясный язык, чтобы помочь большему количеству людей понять окружающие знания о втором уровне Биткойна и обеспечить систематическое понимание системы BitVM.
MATT и приверженность: основная идея BitVM
Прежде всего, мы хотим подчеркнуть, что основная идея BitVM — это MATT, что означает Merkleize All The Things. В основном это относится к использованию древовидной структуры хранения данных, такой как Merkle Tree, для отображения сложного процесса выполнения программы. попытайтесь сделать проверку Bitcoin Native доказательством мошенничества.
Хотя MATT может выражать сложную программу и отслеживать ее обработку данных, он не будет публиковать эти данные напрямую в цепочке BTC, поскольку общий размер этих данных очень велик. Решение, использующее MATT, хранит данные только в дереве Меркла вне цепочки и публикует в цепочке только верхнюю сводку (корень Меркла) дерева Меркла. Это дерево Меркла в основном содержит три основных содержания:
Код сценария смарт-контракта
Данные, необходимые по договору
Следы, оставленные во время выполнения контракта (записи изменений в памяти и регистрах ЦП при выполнении смарт-контрактов на виртуальных машинах, таких как EVM)
(Простая диаграмма дерева Меркла. Корень Меркла рассчитывается на основе 8 фрагментов данных внизу рисунка посредством многоуровневого хеширования)
В соответствии со схемой MATT в цепочке хранится только очень маленький корень Меркла, а полный набор данных, содержащийся в дереве Меркла, хранится вне цепочки. При этом используется идея, называемая «обязательством». Вот объяснение того, что такое «Обязательство».
Обещание похоже на краткое заявление, которое мы можем понимать как «отпечаток пальца», полученный путем сжатия большого объема данных. Вообще говоря, человек, который выдает «обязательство» в цепочке, будет утверждать, что определенные данные, хранящиеся вне цепочки, являются точными. Эти данные вне цепочки должны соответствовать краткому заявлению, и это заявление является «обязательством».
В какой-то момент хэш данных может использоваться в качестве «обязательства» для самих данных. Другие схемы обязательств включают обязательство KZG или дерево Меркла. В обычном протоколе защиты от мошенничества Layer2 издатель данных публикует полный набор данных вне цепочки и обязуется опубликовать набор данных в цепочке. Если кто-то обнаружит неверные данные в наборе данных вне сети, обязательство по передаче данных в сети будет оспорено.
Благодаря Commitment второй уровень может сжимать и обрабатывать большие объемы данных и публиковать только свои «обязательства» в цепочке Биткойн. Конечно, также необходимо обеспечить, чтобы весь набор данных, выпущенный вне сети, мог быть доступен внешнему миру.
В настоящее время несколько основных решений BitVM, таких как BitVM0, BitVM1, BitVM2 и BitVMX, в основном используют схожие абстрактные структуры:
1. Декомпозиция и фиксация программы: сначала разложить сложную программу на большое количество кодов основных операций (компиляция), а затем записать трассировки, генерируемые этими кодами операций во время конкретного выполнения (грубо говоря, программа выполняется на ЦП). и «Когда в памяти» записываются все изменения состояния, называемые «Трассировка»). После этого мы организуем все данные, включая трассировки и коды операций, в набор данных, а затем генерируем обязательство для этого набора данных.
Конкретные схемы обязательств могут принимать разные формы, например: деревья Меркла, PIOP (различные алгоритмы ZK), хэш-функции.
2. Залог активов и предварительное подписание. Издателям и верификаторам данных необходимо заблокировать определенное количество активов в цепочке посредством предварительного подписания, и будут действовать ограничения. Эти условия будут активированы специально для ситуаций, которые могут возникнуть в будущем. Если издатель данных совершит зло, проверяющий может предоставить сертификат для изъятия активов издателя данных.
3. Публикация данных и обязательств: издатель данных публикует обязательство в цепочке, полный набор данных публикуется вне цепочки, а верификатор извлекает набор данных и проверяет наличие каких-либо ошибок. Каждая часть набора данных вне сети коррелирует с обязательствами в сети.
4. Проблемы и штрафы: как только верификатор обнаружит ошибку в данных, предоставленных издателем данных, он перенесет эту часть данных в цепочку для прямой проверки (эту часть данных необходимо предварительно отрезать очень мелко). ). Это логика доказательства мошенничества. Если результаты проверки покажут, что издатель данных действительно предоставил недействительные данные вне сети, его активы будут забраны валидатором, который бросит ему вызов.
Подводя итог, издатель данных Алиса раскрывает все следы, созданные во время выполнения транзакции второго уровня вне цепочки, и публикует соответствующие обязательства в цепочке. Если вы хотите доказать, что определенная часть данных неверна, сначала докажите узлу Биткойн, что эта часть данных связана с коммиттом в цепочке, то есть докажите, что данные раскрыты самой Алисой, и затем позвольте узлу Биткойн подтвердить, что эта часть данных неверна.
Теперь мы примерно понимаем общую идею BitVM, и все варианты BitVM по сути неотделимы от приведенной выше парадигмы. Итак, давайте начнем изучать и понимать некоторые важные технологии, используемые в описанном выше процессе, начиная с самых простых биткойн-скриптов и Taproot и предварительного подписания.
Что такое биткойн-скрипт?
Знания, связанные с биткойнами, сложнее понять, чем Ethereum. Даже самое базовое поведение при передаче включает в себя ряд концепций, включая UTXO (вывод неизрасходованных транзакций), сценарий блокировки (также известный как ScriptPubKey) и сценарий разблокировки (также известный как ScriptSig). Давайте сначала объясним эти основные понятия.
(Пример кода сценария Биткойн, состоящего из кодов операций более низкого уровня, чем язык высокого уровня)
Способ выражения активов в Ethereum больше похож на Alipay или WeChat. Каждый перевод просто добавляет и вычитает балансы разных учетных записей. Этот метод ориентирован на учетную запись, и баланс активов представляет собой просто число под именем учетной записи; Выражение больше похоже на золото. Каждый кусок золота (UTXO) будет отмечен своим владельцем. Передача фактически уничтожает старый UTXO и генерирует новый UTXO (владелец изменится).
Bitcoin UTXO содержит два ключевых поля:
Сумма в «сатоши» (сто миллионов сатоши — это один BTC);
Скрипт блокировки, также известный как «ScriptPubKey», определяет условия разблокировки UTXO.
Следует отметить, что право собственности на биткойн-UTXO выражается через сценарий блокировки. Если вы хотите передать свой UTXO Сэму, вы можете инициировать транзакцию для уничтожения одного из ваших UTXO и записать условия разблокировки вновь сгенерированного UTXO как «. Только Сэм может его разблокировать».
После этого, если Сэм захочет использовать эти биткойны, ему необходимо будет отправить сценарий разблокировки (ScriptSig). В этом сценарии разблокировки Сэму необходимо предоставить свою цифровую подпись, чтобы доказать, что он сам Сэм. Если сценарий разблокировки соответствует вышеупомянутому сценарию блокировки, Сэм может разблокировать и передать биткойны другим.
(Скрипт разблокировки должен совпадать со скриптом блокировки)
С точки зрения выражения, каждая транзакция в цепочке Биткойн соответствует множеству входов и выходов. Каждый вход должен объявить определенный UTXO, который он хочет разблокировать, и отправить сценарий разблокировки для разблокировки и уничтожения UTXO. Выходные данные. Вновь сгенерированная информация UTXO; будет отображаться, и содержимое сценария блокировки будет раскрыто внешнему миру.
Например, при вводе транзакции вы доказываете, что вы Сэм, разблокируете несколько UTXO, предоставленных вам другими, уничтожаете их единообразно, генерируете несколько новых UTXO и заявляете, что xxx будет разблокирован в будущем.
В частности, во входных данных транзакции вам необходимо объявить, какие UTXO вы хотите разблокировать, и указать «место хранения» этих UTXO-данных. Здесь следует отметить, что Биткойн и Эфириум совершенно разные. Ethereum предоставляет две учетные записи: контрактные учетные записи и учетные записи EOA для хранения данных. Баланс активов записывается в виде числа под именем контрактной учетной записи или учетной записи EOA и размещается. в единой базе данных «World State» при переводе денег конкретные счета могут модифицироваться непосредственно из «World State» для облегчения нахождения места хранения данных;
Биткойн не имеет структуры мирового состояния, а данные активов разбросаны и хранятся в прошлых блоках (то есть разблокированные данные UTXO хранятся отдельно в OutPut каждой транзакции).
Если вы хотите разблокировать UTXO, вам необходимо указать, на выходе какой транзакции информация UTXO существовала в прошлом, показать идентификатор транзакции (который является ее хешем) и позволить узлу Биткойн искать ее в записях истории. Если вы хотите запросить биткойн-баланс определенного адреса, вам необходимо пройти все блоки с самого начала и найти разблокированный UTXO, связанный с адресом xx.
Когда вы обычно используете биткойн-кошелек, вы можете быстро проверить баланс биткойнов, принадлежащий определенному адресу. Часто это происходит потому, что служба кошелька сама индексирует все адреса путем сканирования блоков, что упрощает нам быстрый запрос.
(Когда вы создаете отчет о транзакции, чтобы передать свой UTXO другим, вам необходимо отметить позицию UTXO в истории Биткойна на основе хэша/идентификатора транзакции, которому принадлежат эти UTXO)
Интересно, что результаты транзакций Биткойн рассчитываются вне сети. Когда пользователи генерируют транзакции на своих локальных устройствах, они должны напрямую создавать входные и выходные данные, что эквивалентно вычислению выходных результатов транзакции. Транзакции передаются в сеть Биткойн и проверяются узлами перед размещением в цепочке. Эта модель «вычислений вне цепочки и проверки внутри цепочки» полностью отличается от модели Ethereum. В Ethereum вам нужно только предоставить входные параметры транзакции, а результаты транзакции рассчитываются и выводятся узлом Ethereum.
Кроме того, сценарий блокировки UTXO (скрипт блокировки) можно настроить. Вы можете настроить UTXO как «разблокируемый владельцем определенного биткойн-адреса». Владелец адреса должен предоставить цифровую подпись и открытый ключ (P2PKH). . В типе транзакции Pay-to-Script-Hash (P2SH) вы можете добавить хэш сценария в сценарий блокировки UTXO. Кто может отправить исходное изображение сценария, соответствующее этому хэшу, и выполнить заданные условия в исходном изображении сценария? вы можете разблокировать UTXO. Сценарий Taproot, на который опирается BitVM, использует функции, аналогичные P2SH.
Как запустить биткойн-скрипт
Здесь мы сначала используем P2PKH в качестве примера, чтобы представить метод запуска сценария Биткойн. Только поняв его метод запуска, мы сможем понять более сложные Taproot и BitVM. Полное имя P2PKH — «Оплата по хешу открытого ключа». Согласно этой схеме, хеш открытого ключа будет установлен в сценарии блокировки UTXO, и при разблокировке необходимо предоставить открытый ключ, соответствующий хешу. то же, что и традиционная идея перевода биткойнов.
В это время узел Биткойн должен подтвердить, что открытый ключ в сценарии разблокировки соответствует хешу открытого ключа, указанному в сценарии блокировки. Другими словами, он должен подтвердить, что «ключ», предоставленный разблокировщиком, и предустановка «блокировки». по UTXO соответствуют друг другу.
Кроме того, в соответствии со схемой P2PKH, после получения транзакции узел Биткойн объединит сценарий разблокировки ScriptSig, предоставленный пользователем, со сценарием блокировки ScriptPubkey разблокируемого UTXO и выполнит их в среде выполнения сценария BTC. На следующем рисунке показаны результаты сращивания перед выполнением:
Возможно, читатели не знают среду выполнения скриптов BTC, поэтому здесь мы кратко ее представим. Во-первых, скрипт BTC содержит два элемента:
данные и коды операций. Эти данные и коды операций будут помещены в стек по порядку слева направо и выполнены в соответствии с заданной логикой для получения конечного результата (подробности о том, что такое стек, здесь не будут подробно описаны, читатели могут поговорить сами).
Если взять приведенное выше изображение в качестве примера, то слева показан скрипт разблокировки ScriptSig, загруженный кем-то, включая его цифровую подпись и открытый ключ, а скрипт блокировки ScriptPubkey с правой стороны содержит код операции и данные, установленные создателем UTXO при генерации UTXO (здесь нам не нужно понимать значение каждого кода операции, достаточно приблизительного понимания).
DUP, HASH160, EQUALVERIFY и другие коды операций в сценарии блокировки справа на рисунке выше отвечают за хеширование открытого ключа, содержащегося в сценарии разблокировки слева, и сравнение его с предварительно установленным хэшем открытого ключа в сценарии блокировки. Если они равны, это означает, что открытый ключ, загруженный в сценарий разблокировки, соответствует заданному хешу открытого ключа в сценарии блокировки, и первая проверка пройдена.
Однако есть проблема. Содержимое скрипта блокировки UTXO на самом деле является общедоступным в цепочке. Любой может просмотреть содержащийся в нем хэш открытого ключа и ложно заявить, что это именно он. назначаемый императором». » человек. Следовательно, после проверки открытого ключа и хэша открытого ключа необходимо также проверить, действительно ли инициатор транзакции является фактическим контроллером открытого ключа, что требует проверки цифровой подписи. Код операции CHECKSIG в сценарии блокировки отвечает за проверку цифровой подписи.
Подводя итог, в схеме P2PKH сценарий разблокировки, отправленный инициатором транзакции, содержит открытый ключ и цифровую подпись. Открытый ключ должен соответствовать хешу открытого ключа, указанному в сценарии блокировки, и только цифровая подпись транзакции является правильной. когда эти условия соблюдены, разблокировка UTXO может осуществляться плавно.
(Это изображение динамичное: принципиальная схема сценария разблокировки биткойнов по схеме P2PKH.
Источник: https://learnmeabitcoin.com/technical/script)
Конечно, сеть Биткойн поддерживает несколько типов транзакций, не только «оплата по открытому ключу/хеш открытого ключа», но также P2SH (оплата по хэшу сценария) и т. д. Все зависит от того, как установлен пользовательский сценарий блокировки при создании UTXO. .
Здесь следует отметить, что в схеме P2SH хэш сценария может быть предварительно установлен в сценарии блокировки, а сценарий разблокировки должен передать полное содержимое сценария, соответствующее хешу сценария. Узлы Биткойн могут выполнять этот сценарий. Если в этом сценарии определена логика проверки мультиподписей, в цепочке Биткойн может быть достигнут эффект кошелька с несколькими подписями.
Конечно, в соответствии со схемой P2SH создатель UTXO должен сообщить человеку, который разблокирует UTXO в будущем, заранее знать содержимое сценария, соответствующее хэшу сценария. Если обе стороны знают содержимое этого сценария, мы можем его реализовать. более сложная бизнес-логика, чем мультиподпись.
Здесь следует отметить, что цепочка (блок) Биткойна не записывает напрямую, какие UTXO с какими адресами связаны, она только записывает, какой хэш открытого ключа/хеш какого сценария можно разблокировать UTXO, но мы используем хеш/скрипт открытого ключа. чтобы разблокировать его, Hash может быстро вычислить соответствующий адрес (раздел, отображаемый в интерфейсе кошелька, выглядит как искаженные символы).
Причина, по которой мы можем видеть xx количество биткойнов по адресу xx в обозревателе блоков и интерфейсе кошелька, заключается в том, что обозреватель блоков и проект кошелька помогают вам анализировать данные, сканировать все блоки и блокировать скрипт в соответствии с хешем открытого ключа/хешем скрипта. объявленный в, вычисляет соответствующий «адрес», а затем отображает, сколько биткойнов находится под именем адреса xx.
Отдельный свидетель и свидетель
После того, как мы поняли идею P2SH, мы стали на шаг ближе к Taproot, от которого зависит BitVM. Но перед этим нам нужно понять важную концепцию: свидетель и отдельный свидетель.
Просмотрев сценарий разблокировки и сценарий блокировки, упомянутые ранее, а также процесс разблокировки UTXO, вы обнаружите проблему: цифровая подпись транзакции включена в сценарий разблокировки, и сценарий разблокировки не может быть перезаписан при генерации подписи ( параметры, используемые для генерации подписи, не могут включать саму подпись), поэтому цифровая подпись может охватывать только части, отличные от сценария разблокировки, то есть она может быть связана только с основной частью данных транзакции и не может полностью охватывать транзакцию. данные.
Таким образом, даже если посредник слегка манипулирует сценарием разблокировки транзакции, это не повлияет на результат проверки подписи. Например, узлы биткойнов или пулы майнинга могут вставлять другие данные в сценарий разблокировки транзакции, вызывая незначительные изменения в данных транзакции, не влияя на проверку подписи и результаты транзакции. Окончательный рассчитанный хеш/идентификатор транзакции также изменится. Это известно как проблема гибкости транзакций.
Недостаток этого подхода в том, что если вы планируете инициировать несколько транзакций подряд и существуют последовательные зависимости (например, транзакция 3 относится к выходу транзакции 2, а транзакция 2 относится к выходу транзакции 1), то последующие транзакции. Необходимо указать идентификатор (хэш) предыдущей транзакции. Любой посредник, такой как майнинг-пул или биткойн-узел, может точно настроить содержимое сценария разблокировки, чтобы хэш после загрузки транзакции не соответствовал тому, что было. вы ожидали, что тогда несколько транзакций, которые вы создали заранее, имеют последовательно связанные транзакции, станут недействительными.
Фактически в DLC Bridge и решениях BitVM2 транзакции с последовательной корреляцией будут строиться пакетно, поэтому упомянутый выше сценарий не является редкостью.
Проще говоря, проблема масштабируемости транзакций заключается в том, что идентификатор/хеш транзакции при его вычислении будет включать данные сценария разблокировки, а посредники, такие как узлы Биткойн, могут точно настроить содержимое сценария разблокировки, в результате чего идентификатор транзакции будет отличается от того, что ожидал пользователь, несовместимо. Фактически, это исторический багаж, оставленный плохой проработкой Биткойна на ранних этапах его разработки.
Более позднее обновление Segregated Witness/SegWit фактически полностью отделяет идентификатор транзакции и сценарий разблокировки. Нет необходимости включать данные сценария разблокировки при вычислении хеша транзакции. Скрипт блокировки UTXO, который следует за обновлением SegWit, по умолчанию сначала устанавливает код операции с именем «OP_0», который служит меткой, а соответствующий сценарий разблокировки был переименован с SigScript на Witness;
После соблюдения правил SegWit проблема масштабируемости транзакций будет решена должным образом, и вам не нужно беспокоиться о точной настройке данных транзакций, отправляемых на узел Биткойн. Конечно, нам не нужно думать слишком сложно. Функции P2WSH существенно не отличаются от упомянутого ранее P2SH. Вы можете установить хэш сценария в сценарии блокировки UTXO и дождаться, пока отправитель сценария разблокировки отправит его. содержимое сценария, соответствующее хешу, в цепочку и выполняется.
Но если содержимое скрипта, который вы хотите реализовать, очень велико и содержит много кода, полный скрипт невозможно отправить в цепочку Биткойн обычными методами (каждый блок имеет ограничение на размер). Что делать? Это требует использования Taproot для оптимизации содержимого скриптов в цепочке, а BitVM — это сложное решение, созданное на основе Taproot.
В следующей статье «Подход к BTC» мы проведем подробную популяризацию Taproot, pre-signing и других более сложных технологий, связанных с BitVM, так что следите за обновлениями!
