Про:

Компанія Delphi Digital недавно опублікувала звіт під назвою "Настання програмованості Bitcoin: відкриття шляху для Rollups", в якому висвітлені ключові концепції, пов'язані з 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 та містки міжланцюжкові мости Bitcoin, з метою розкриття та роз'яснення технологій другого рівня Bitcoin для широкої аудиторії та підготовки шляху для більшої кількості ентузіастів.

Декілька місяців тому Робін Лінус, лідер ZeroSync, опублікував статтю під назвою «BitVM: Обчислюйте що завгодно на Bitcoin», офіційно вводячи поняття BitVM і рухаючи вперед технологію Bitcoin Layer 2. Це вважається одним з найбільш революційних інновацій в екосистемі Bitcoin, спонукаючи значний інтерес та активність в просторі Bitcoin Layer 2. Він привернув відомі проекти, такі як Bitlayer, Citrea та BOB, приносячи нову енергію на ринок. З того часу до проекту приєдналися більше дослідників, які прагнуть поліпшити BitVM, що призвело до кількох ітеративних версій, таких як BitVM1, BitVM2, BitVMX та BitSNARK. Загальний огляд виглядає наступним чином:

1. Робін Лінус (Robin Linus) в минулому році представив офіційний документ про реалізацію BitVM, який заснований на концептуальній логічній схемі вентиля і відомий як BitVM0.
2. У подальших презентаціях та інтерв'ю Робін Лінус неформально представив концепцію BitVM на основі теоретичного ЦП, відомого як BitVM1. Це схоже на систему підтвердження шахрайства Cannon від Optimism, і воно може симулювати ефект універсального ЦП поза ланцюжком за допомогою скриптів Bitcoin.
3. Робін Лінус також запропонував BitVM2, протокол бездозвільного одноетапного неінтерактивного протоколу доведення шахрайства.
4. Члени Rootstock Labs та Fairgate Labs опублікували білий папір про BitVMX. Схоже на BitVM1, вони мають на меті симулювати ефект загальнопризначеного процесора off-chain з використанням Bitcoin-скриптів.

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

Для більшості людей розуміння БітVM та технічних термінів, пов'язаних з Bitcoin Layer 2, не є простим завданням. Це вимагає систематичного засвоєння фундаментальних знань, особливо Bitcoin scripts та Taproot. Існуючі онлайн-ресурси часто або занадто обширні та переповнені непотрібними подробицями, або занадто стислі, щоб бути зрозумілими. Ми маємо за мету вирішити ці питання, використовуючи чітку та стислу мову, щоб допомогти більшій кількості людей зрозуміти фундаментальні концепції Bitcoin Layer 2 та побудувати всебічне розуміння системи БітVM.

MATT та Зобов'язання: Основна концепція БітVM

Основна концепція BitVM ґрунтується на MATT, що означає Merkleize All The Things. Цей підхід використовує дерево Меркля, ієрархічну структуру зберігання даних, щоб представляти виконання складних програм. Це спрямовано на забезпечення можливості нативної перевірки доказів шахрайства в мережі Bitcoin. MATT може зафіксувати деталі складної програми та її діяльності з обробки даних, але не публікує ці обширні дані безпосередньо на блокчейні Bitcoin через їхній великий розмір. Замість цього підхід MATT зберігає ці дані в позаланцюжковому дереві Меркля та публікує на блокчейні тільки кореневий Меркл (верхнє резюме дерева Меркля). Дерево Меркля в основному містить три ключові компоненти:

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

(Проста схематична діаграма Дерева Меркла. Його Корінь Меркла обчислюється з 8 фрагментів даних унизу малюнка за допомогою багаторівневого хешування)

За схемою MATT на ланцюжку зберігається лише надзвичайно малий корінь Меркла, а повний набір даних, що міститься у дереві Меркла, зберігається поза ланцюжком. Це використовує ідею, яку називають "зобов'язанням". Ось пояснення, що таке "зобов'язання".

Обіцянка схожа на стисле твердження, ми можемо розуміти її як «відбиток пальця», отриманий після стиснення великої кількості даних. Загалом, людина, яка видає "зобов'язання" на ланцюгу, стверджуватиме, що певні дані, збережені поза ланцюгом, є точними. Ці дані поза ланцюгом повинні відповідати стислому твердженню, і це твердження є "зобов'язанням."

У певний момент хеш даних може бути використаний як "зобов'язання" перед самими даними. Інші схеми зобов'язання включають зобов'язання KZG або дерево Меркла. У звичайному протоколі доказу шахрайства Layer2, видавець даних опублікує повний набір даних поза ланцюжком та зобов'язання опублікувати набір даних на ланцюжку. Якщо хтось виявляє недійсні дані у позаланцюжковому наборі даних, зобов'язання на ланцюжку буде оспорене.

Через зобов'язання другий шар може стиснути велику кількість даних і опублікувати лише своє “commitment” на ланцюжку Bitcoin. Звісно, також потрібно забезпечити можливість спостереження зовнішнім світом повного набору даних, випущеного поза ланцюжком.

Наразі основні схеми 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?

Розуміння Bitcoin може бути складнішим, ніж Ethereum, оскільки навіть найпростіші операції включають кілька ключових концепцій. Серед них UTXO (Unspent Transaction Output), блокуючі скрипти (також відомі як ScriptPubKey) та розблокувальні скрипти (також відомі як ScriptSig). Давайте спочатку розберемо ці фундаментальні концепції.

(Зразок коду скрипта Bitcoin складається з кодів операцій нижчого рівня в порівнянні з мовами високого рівня) Метод представлення активів Ethereum схожий на такі системи, як Alipay або WeChat, де кожна транзакція просто коригує баланси різних рахунків. Цей підхід, заснований на рахунках, розглядає залишки активів як просто цифри, пов'язані з рахунками. На противагу цьому, представлення активів Bitcoin більше схоже на роботу із золотом, де кожна одиниця золота (UTXO) позначена власником. Біткойн-транзакція по суті знищує старий 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, вам потрібно вказати, в якому виводі транзакції інформація про UTXO існує у минулому, та показати ідентифікатор транзакції (який є її хешем). Нехай вузол Bitcoin шукає його в історії. Якщо ви хочете запитати баланс Bitcoin певної адреси, вам потрібно пройти всі блоки з початку, щоб знайти розблокований UTXO, пов'язаний із адресою xx.

Коли ви зазвичай використовуєте гаманець Bitcoin, ви можете швидко перевірити баланс Bitcoin, що належить певній адресі. Це часто тому, що сам сервіс гаманця індексує всі адреси, скануючи блоки, що ускладнює нам швидко запитувати.

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

Як викликати Bitcoin сценарій

Для розуміння механізму спрацювання скриптів Bitcoin ми розпочнемо з прикладу P2PKH, що означає «Платіть на публічний ключ хеш». У цій ​​настройці блокувальний скрипт UTXO містить хеш публічного ключа, і для розблокування його потрібно надати відповідний публічний ключ. Цей механізм відповідає стандартному процесу транзакцій Bitcoin. У цьому контексті вузол Bitcoin повинен перевірити, що публічний ключ у скрипті розблокування відповідає хешу публічного ключа, вказаному в блокувальному скрипті. Зазвичай, він перевіряє, що «ключ», наданий користувачем, відповідає «замку», встановленому UTXO. Докладніше, за схемою P2PKH, коли вузол Bitcoin отримує транзакцію, він поєднує скрипт розблокування користувача (ScriptSig) з блокувальним скриптом (ScriptPubKey) UTXO, який потрібно розблокувати, і потім виконує цей об'єднаний скрипт в середовищі виконання скриптів Bitcoin. Нижче наведено зображення з'єднаного результату перед виконанням:

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

(Це динамічна ілюстрація: діаграма розблокування біткоїн-скриптів за схемою P2PKH
Джерело:https://learnmeabitcoin.com/technical/script)

Важливо зауважити, що мережа Bitcoin підтримує різноманітні типи транзакцій поза Pay to Public Key/Public Key Hash, такі як P2SH (Pay to Script Hash). Конкретний тип транзакції залежить від того, як налаштований блокуючий скрипт при створенні UTXO.

Важливо розуміти, що за схемою P2SH скрипт блокування може попередньо встановити хеш сценарію, а скрипт розблокування повинен надавати повний вміст сценарію, який відповідає цьому хешу сценарію. Потім вузол Bitcoin може виконати цей сценарій, і якщо він включає логіку перевірки з мультипідписом, він фактично вмикає гаманці з мультипідписом у блокчейні Bitcoin. У схемі P2SH творець UTXO повинен повідомити особу, яка буде розблоковувати UTXO в майбутньому, про вміст скрипта, що відповідає хешу скрипта. Поки обидві сторони знають про зміст сценарію, ми можемо реалізувати навіть більш складну бізнес-логіку, ніж просто мультипідпис. Також варто зазначити, що блокчейн Bitcoin безпосередньо не записує, які UTXO пов'язані з якими адресами. Замість цього він записує, які UTXO можуть бути розблоковані за допомогою хешу відкритого ключа або хешу сценарію. Однак ми можемо швидко отримати відповідну адресу (рядок символів, який виглядає як тарабарщина, що відображається в інтерфейсах гаманця) з хешу відкритого ключа або хешу скрипта.

Причина, чому ви можете бачити кількість біткоїнів, пов'язаних з певною адресою на блок-дослідниках та інтерфейсах гаманця, полягає в тому, що ці служби розбирають та інтерпретують дані блокчейну для вас. Вони сканують всі блоки і, на основі хешу публічного ключа або хешу сценарію, заявленого в блокувальних сценаріях, обчислюють відповідну «адресу». Це дозволяє їм відображати, скільки біткоїнів пов'язано з цією адресою.

Поділений свідок та свідок

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

Отже, цифровий підпис може охоплювати лише частини даних операції поза розблокувальним скриптом, що означає, що він не може повністю захистити всі дані операції. Це призводить до вразливості, де посередник може незначно змінити розблокувальний скрипт без впливу на перевірку підпису. Наприклад, вузли Bitcoin або майнінгові пули можуть вставляти додаткові дані в розблокувальний скрипт. Хоча ця зміна не впливає на перевірку та результат операції, вона незначно змінює дані операції, що змінює обчислений хеш/ID операції. Ця проблема відома як маніпулювання операцією.

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

Ця розбіжність може анулювати ваш попередньо заплановану послідовність взаємозалежних операцій. Це питання особливо актуальне в контексті мостів DLC та BitVM2, де формуються партії послідовно пов'язаних транзакцій, що робить такі сценарії досить поширеними.

У простих термінах проблема модифікації транзакції виникає через те, що обчислення ідентифікатора/хешу транзакції включає дані з розблокувального скрипта. Посередники, такі як вузли Bitcoin, можуть вносити незначні зміни в розблокувальний скрипт, що призводить до того, що ідентифікатор транзакції не відповідає очікуванням користувача. Ця проблема виникає з ранніх обмежень у дизайні Bitcoin. Оновлення Segregated Witness (SegWit) вирішує цю проблему, відокремлюючи ідентифікатор транзакції від розблокувального скрипта. З SegWit обчислення хешу транзакції виключає дані розблокувального скрипта. Розблокувальні скрипти UTXO під SegWit починаються з опкоду "OP_0" як маркера, а відповідний розблокувальний скрипт перейменовується з SigScript на Witness.

Дотримуючись правил Segregated Witness (SegWit), проблема гнучкості транзакцій ефективно вирішується, усуваючи занепокоєння з приводу того, що дані транзакцій можуть бути підроблені вузлами Bitcoin. Функціонал P2WSH (Pay to Witness Script Hash) по суті такий же, як і P2SH (Pay to Script Hash). Ви можете попередньо встановити хеш сценарію в сценарії блокування UTXO, і особа, яка надсилає сценарій розблокування, надасть відповідний вміст сценарію ланцюжку для виконання. Однак, якщо контент скрипта, який вам потрібен, дуже великий і містить багато коду, звичайні методи можуть не дозволити вам відправити весь скрипт в блокчейн Bitcoin (через обмеження розміру блоку). У таких випадках у гру вступає Taproot. Taproot дозволяє стискати вміст ончейн-скриптів, що дозволяє обробляти більші сценарії. BitVM використовує Taproot для створення більш складних рішень. У наступній статті нашої серії "Наближення до BTC" ми надамо детальні пояснення Taproot, pre-signature та інших передових технологій, пов'язаних з BitVM. Слідкуйте за новинами!

Відмова від відповідальності:

1. Ця стаття розміщена з [ Гік Веб3], авторські права належать оригінальним авторам [Nickqiao & Faust & Shew Wang]. Якщо є які-небудь зауваження до перепублікації, будь ласка, зв'яжіться з Gate Learnкоманда, і команда негайно обробить це відповідно до відповідних процедур.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, є виключно поглядами авторів і не становлять жодних інвестиційних порад.
3. Інші мовні версії статті були перекладені командою Gate Learn. Без згадуванняGate.io, перекладені статті не повинні бути скопійовані, поширені або плагіатовані.