Автор: Nickqiao & Faust & Shew Wang, geek web3

Консультант: дослідницька група Bitlayer

Резюме:

Нещодавно компанія Delphi Digital випустила звіт про технічні дослідження другого рівня біткойнів під назвою «Світанок програмування біткойнів: прокладаючи шлях для зведених пакетів», у якому систематично відсортовано основні концепції, пов’язані з зведеними біткойнами, такі як BitVM Family Bucket, OP_CAT і Обмеження угоди, екологічний рівень DA Bitcoin, міст і чотири основні другі рівні Bitcoin, що використовують BitVM, включаючи Bitlayer, Citrea, Yona та Bob.

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

Ми разом із дослідницькою групою Bitlayer і китайською спільнотою BitVM запустимо серію колонок під назвою «Наближення до BTC», щоб довгостроково популяризувати науку навколо таких ключових тем, як BitVM, OP_CAT і міжланцюгові мости Bitcoin, і прагнемо розчарувати Біткойн для більшої кількості людей. Технології, пов’язані з Coin Layer 2, допомагають прокласти шлях для більшої кількості ентузіастів.

текст:

Кілька місяців тому Робін Лінус, керівник ZeroSync, опублікував статтю під назвою «BitVM: Compute Anything on Bitcoin», офіційно запропонувавши концепцію BitVM і сприяючи прогресу технології другого рівня Bitcoin. Можна сказати, що це одне з найбільш революційних нововведень в екосистемі біткойн. Воно підірвало всю екосистему другого рівня біткойнів, залучило до участі такі зіркові проекти, як 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 і Bitcoin Layer 2, тому що ви повинні спочатку мати систематичне розуміння базових знань, що їх оточують, особливо таких базових знань, як сценарії Bitcoin і Taproot. Довідкові матеріали, доступні зараз в Інтернеті, або занадто довгі та повні нісенітниці, або пояснення недостатньо ретельні, через що люди здається, що розуміють, але не розуміють. Ми прагнемо вирішити вищезазначені проблеми та прагнемо використовувати якомога зрозумілішу мову, щоб допомогти більшій кількості людей зрозуміти навколишні знання про другий рівень біткойна та встановити систематичне розуміння системи BitVM.

MATT і відданість: основна ідея BitVM

Перш за все, ми хочемо підкреслити, що основною ідеєю BitVM є MATT, що означає Merkleize All The Things. Це в основному стосується використання деревоподібної структури зберігання даних, такої як Merkle Tree, для відображення процесу виконання складної програми. спробуйте зробити верифікацію Bitcoin Native доказом шахрайства.

Хоча MATT може виражати складну програму та її сліди обробки даних, він не публікуватиме ці дані безпосередньо в ланцюжку BTC, оскільки загальний масштаб цих даних дуже великий. Рішення, що використовує MATT, зберігає дані лише в дереві Merkle поза ланцюжком і публікує лише верхній підсумок (корінь Merkle) дерева Merkle у ланцюжку. Це дерево Merkle в основному містить три основних вмісту:

  • Код сценарію смарт-контракту

  • Дані, необхідні за договором

  • Сліди, залишені під час виконання контракту (записи змін пам’яті та регістрів процесора, коли смарт-контракти виконуються у віртуальних машинах, таких як EVM)

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

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

У певний момент хеш даних може використовуватися як «зобов’язання» для самих даних. Інші схеми зобов’язань включають зобов’язання KZG або Merkle Tree. У звичайному протоколі рівня 2, захищеному від шахрайства, видавець даних публікує повний набір даних поза ланцюжком і зобов’язується опублікувати набір даних у ланцюжку. Якщо хтось виявить недійсні дані в наборі даних поза ланцюгом, зобов’язання щодо даних у ланцюзі буде оскаржено.

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

На даний момент кілька основних рішень BitVM, таких як BitVM0, BitVM1, BitVM2 і BitVMX, в основному використовують схожі абстрактні структури:

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

Конкретні схеми зобов’язань можуть приймати різні форми, наприклад: дерева Меркла, PIOP (різні алгоритми ZK), хеш-функції

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

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

4. Проблеми та покарання: як тільки верифікатор виявляє помилку в даних, наданих видавцем даних, він передає цю частину даних у ланцюжок для прямої перевірки (цю частину даних спочатку потрібно дуже дрібно обрізати логіка шахрайства. Якщо результати перевірки покажуть, що видавець даних дійсно надав недійсні дані поза мережею, його активи будуть вилучені валідатором, який оскаржує його.

Підводячи підсумок, Аліса, видавець даних, розкриває всі траси, згенеровані під час виконання транзакцій другого рівня поза ланцюжком, і публікує відповідні зобов’язання для ланцюжка. Якщо ви хочете довести, що певна частина даних є неправильною, спочатку доведіть біткойн-вузлу, що ця частина даних пов’язана із зобов’язаннями в ланцюжку, тобто доведіть, що дані розкриває сама Аліса, і потім нехай вузол Bitcoin підтвердить, що ця частина даних неправильна.

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

Що таке Bitcoin Script?

Знання, пов’язані з біткойнами, складніше зрозуміти, ніж Ethereum. Навіть найпростіша поведінка переказу включає низку понять, у тому числі UTXO (виведення невитрачених транзакцій), сценарій блокування (також відомий як ScriptPubKey) і сценарій розблокування (також відомий як ScriptSig). Давайте спочатку пояснимо ці основні поняття.

(Приклад коду сценарію Bitcoin, що складається з кодів операцій нижчого рівня, ніж мова високого рівня)

Спосіб відображення активів в Ethereum більше схожий на те, що кожен переказ додає та віднімає баланси різних рахунків, а баланс активів – це лише число під назвою біткойна Вираз більше схожий на золото (UTXO) буде позначено його власником. Передача фактично знищує старий UTXO і генерує новий UTXO (власник зміниться).

Bitcoin UTXO містить два ключових поля:

Сума в «сатоші» (сто мільйонів сатоші — це один BTC);

Сценарій блокування, також відомий як "ScriptPubKey", визначає умови розблокування UTXO.

Слід зазначити, що право власності на біткойн UTXO виражається через сценарій блокування. Якщо ви хочете передати свій UTXO Сему, ви можете ініціювати транзакцію для знищення одного з ваших UTXO та записати умови розблокування щойно згенерованого UTXO як ". Тільки Сем може його розблокувати».

Після цього, якщо Сем хоче використовувати ці біткойни, йому потрібно надіслати сценарій розблокування (ScriptSig). У цьому сценарії розблокування Сем повинен представити свій цифровий підпис, щоб підтвердити, що він сам Сем. Якщо сценарій розблокування збігається зі згаданим вище сценарієм блокування, Сем може розблокувати та передати біткойни іншим.

(Сценарій розблокування має збігатися зі сценарієм блокування)

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

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

Зокрема, у вхідних даних транзакції ви повинні вказати, які UTXO ви хочете розблокувати, і вказати «місце зберігання» цих даних UTXO. Тут слід зазначити, що Bitcoin і Ethereum надають два типи облікових записів: облікові записи контракту та облікові записи EOA розміщено в уніфікованому файлі під назвою «Світ». У базі даних «Світовий стан» під час переказу грошей окремі рахунки можна змінювати безпосередньо з «Світового стану», щоб полегшити визначення місця зберігання даних;

Біткойн не має дизайну світового стану, а дані про активи розкидані та зберігаються в минулих блоках (тобто розблоковані дані UTXO зберігаються окремо у OutPut кожної транзакції).

Якщо ви хочете розблокувати UTXO, ви повинні вказати, у вихідних даних якої транзакції інформація UTXO існує в минулому, показати ідентифікатор транзакції (який є її хешем) і дозволити вузлу Bitcoin шукати його в записах історії. Якщо ви хочете запитати баланс Bitcoin певної адреси, вам потрібно пройти всі блоки з самого початку, щоб знайти розблокований UTXO, пов’язаний з адресою xx.

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

(Коли ви створюєте заяву про транзакцію, щоб надати свій UTXO іншим, вам потрібно позначити позицію UTXO в історії Bitcoin на основі хешу/ідентифікатора транзакції, до якого належать ці UTXO)

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

Крім того, сценарій блокування UTXO (Locking Script) можна налаштувати так, щоб UTXO був "розблокований власником певної адреси Bitcoin". Власник адреси повинен надати цифровий підпис і відкритий ключ (P2PKH). . У типі транзакцій Pay-to-Script-Hash (P2SH) ви можете додати хеш сценарію в сценарій блокування UTXO, який відповідає цьому хешу, і відповідає заданим умовам у вихідному образі сценарію? ви можете розблокувати UTXO. Сценарій Taproot, на якому покладається BitVM, використовує функції, подібні до P2SH.

Як запустити скрипт Bitcoin

Тут ми спочатку використовуємо P2PKH як приклад, щоб представити метод запуску Bitcoin-скрипту. Тільки зрозумівши його метод запуску, ми зможемо зрозуміти більш складні Taproot і BitVM. Повна назва P2PKH – «Оплата відкритого ключа». Згідно з цією схемою, відкритий ключ буде встановлено в сценарії блокування UTXO, і відкритий ключ, відповідний цьому хешу, потрібно надіслати під час розблокування те саме, що і звичайна ідея переказу біткойнів.

У цей час біткойн-вузол повинен підтвердити, що відкритий ключ у сценарії розблокування відповідає хешу відкритого ключа, зазначеному в сценарії блокування за UTXO відповідають один одному.

Крім того, за схемою P2PKH після того, як вузол Bitcoin отримає транзакцію, він поєднає сценарій розблокування ScriptSig, наданий користувачем, зі сценарієм блокування ScriptPubkey UTXO, який потрібно розблокувати, і виконає його в середовищі виконання сценарію BTC. На наступному малюнку показано результати зварювання перед виконанням:

Можливо, читачі не знають середовища виконання сценаріїв BTC, тому тут ми коротко представимо його. По-перше, скрипт BTC містить два елементи:

дані та коди операцій. Ці дані та коди операцій надсилатимуться в стек у порядку зліва направо та виконуватимуться відповідно до вказаної логіки для отримання кінцевого результату (подробиці того, що таке стек, тут не пояснюватимуться. Читачі можуть спілкуватися в чаті самостійно).

Беручи наведене вище зображення як приклад, ліворуч зображено сценарій розблокування ScriptSig, завантажений кимось, включаючи його цифровий підпис і відкритий ключ, а сценарій блокування ScriptPubkey праворуч містить код операції та набір даних творцем UTXO під час генерації UTXO (нам не потрібно розуміти значення кожного коду операції тут, лише приблизне розуміння).

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

Однак існує проблема. Будь-хто може завантажувати відповідний відкритий ключ і помилково стверджувати, що він є тим, хто є ". призначений імператором". "Нар. Тому після перевірки відкритого ключа та хешу відкритого ключа також необхідно перевірити, чи справді ініціатор транзакції є фактичним контролером відкритого ключа, який вимагає перевірки цифрового підпису. Код операції CHECKSIG у сценарії блокування відповідає за перевірку цифрового підпису.

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

(Це зображення є динамічним: схема сценарію розблокування Bitcoin за схемою P2PKH

Джерело: https://learnmeabitcoin.com/technical/script)

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

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

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

Тут слід зауважити, що ланцюжок біткойн (блок) безпосередньо не записує, які UTXO пов’язані з якими адресами, він лише записує, який хеш відкритого ключа/який хеш сценарію можна розблокувати, але ми базуємося на хеші відкритого ключа. /script Hash може швидко обчислити відповідну адресу (розділ, що відображається в інтерфейсі гаманця, виглядає як спотворені символи).

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

Окремо свідок і свідок

Після того як ми зрозуміли ідею​​P2SH, ми стали на крок ближче до Taproot, на який покладається BitVM. Але перед цим нам потрібно зрозуміти важливу концепцію: Свідок і Сегрегований Свідок.

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

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

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

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

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

Пізніше оновлення Segregated Witness/SegWit фактично повністю роз’єднує ідентифікатор транзакції та сценарій розблокування. Під час обчислення хешу транзакції немає необхідності включати дані сценарію розблокування. Сценарій блокування UTXO, який слідує за оновленням SegWit, спочатку встановить код операції під назвою "OP_0", який служить позначкою, а відповідний сценарій розблокування було перейменовано з SigScript на Witness.

Після виконання правил SegWit проблема масштабованості транзакцій буде належним чином вирішена, і вам не потрібно турбуватися про точне налаштування даних транзакцій, які надсилаються на вузол Bitcoin. Звичайно, нам не потрібно думати, що P2WSH принципово не відрізняється від згаданого раніше хешу сценарію в сценарії блокування UTXO і чекає відправки сценарію розблокування. вміст сценарію, що відповідає хешу, передається в ланцюжок і виконується.

Але якщо вміст сценарію, який ви хочете реалізувати, є особливо великим і містить багато коду, повний сценарій не можна надіслати в ланцюжок біткойн за допомогою звичайних методів (кожен блок має обмеження розміру). Що робити? Це вимагає використання Taproot для оптимізації вмісту сценарію в ланцюжку, а BitVM — це складне рішення, створене на основі Taproot.