Ознайомлення з BTC: детальний опис необхідних знань для BitVM

Автори: Нікцяо & Фауст & Шоу Ван, Geek Web3

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

Анотація:

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

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

Ми спільно з командою дослідників Bitlayer та китайською спільнотою BitVM запускаємо серію розділів під назвою “Підходіть до BTC”, що буде орієнтована на BitVM, OP \ _CAT та крос-ланцюжковий міст Bitcoin. Серія присвячена популяризації цих ключових тем і призначена допомогти більшій кількості осіб зрозуміти технології пов’язані з біткоїном другого рівня та відкрити дорогу для більшої кількості прихильників.

Основний текст:

Кілька місяців тому керівник ZeroSync Робін Лінус опублікував статтю під назвою “BitVM: Обчислюйте все на Bitcoin”, в якій офіційно висунув концепцію BitVM і сприяв розвитку технології другого рівня Bitcoin. Можна сказати, що це одна з найбільш революційних інновацій в екосистемі Bitcoin, яка спричинила вибух на другому рівні Bitcoin, привернула увагу таких проектів, як Bitlayer, Citrea, BOB та інших відомих учасників, та надала ринку енергію.

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

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

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

Але для більшості людей розуміння технічних термінів, пов’язаних з BitVM та другим рівнем біткойну, виявляється складною задачею, оскільки спочатку потрібно системно зрозуміти основні знання, особливо фонові знання, такі як біткойн-скрипт та Taproot. Наразі доступні в Інтернеті посилання або занадто довгі та нудні, або пояснення не настільки глибокі, щоб зрозуміти. Ми прагнемо вирішити ці проблеми та допомогти більшій кількості людей зрозуміти фонові знання другого рівня біткойну, створити системне уявлення про систему BitVM за можливо найбільш зрозумілою мовою.

MATT та обіцянка: основна ідея BitVM

Спочатку ми хочемо наголосити, що основна ідея BitVM - це MATT (Merkleize All The Things), що означає Merkleize All The Things, тобто показувати складний процес виконання програми за допомогою структури даних у вигляді дерева Меркля і намагатися забезпечити підтвердження обману для нативної перевірки біткойну.

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

• Код скрипта смарт-контракту
• Дані, необхідні для угоди
• Сліди виконання контракту (записи про зміни пам’яті, реєстрів CPU, які виникають при виконанні смарт-контракту в віртуальній машині EVM тощо)

У рамках MATT, тільки дуже малі розміри кореня Меркл зберігаються на ланцюгу, а повний набір даних, що міститься в дереві Меркла, зберігається поза блокчейном, що використовує підхід, що називається ‘зобов’язанням’ (Commitment). Тут пояснюється, що таке ‘зобов’язання’ (Commitment).

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

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

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

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

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

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

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

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

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

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

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

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

Знання, пов’язані з Bitcoin, складніше для розуміння, ніж Ethereum, навіть базові операції з переказом включають в себе ряд понять, таких як UTXO (невитрачений вихід транзакції), замок-скрипт (також відомий як PubKey) та розблоковувальний скрипт (також відомий як Sig). Давайте спочатку розглянемо ці основні поняття.

(приклад коду скрипта Bitcoin, що складається з опкодів на більш високому рівні від операційних кодів)

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

Біткойн UTXO містить два ключові поля:

сума, в одиницях «Сатоші (сатоші)» (100 млн. Сатоші - це один BTC);

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

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

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

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

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

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

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

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

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

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

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

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

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

Скрипт Bitcoin, як активувати

Тут ми спочатку розглянемо приклад використання P2PKH для пояснення способу активації скрипту Bitcoin, оскільки тільки розуміння способу активації дозволяє зрозуміти більш складні Taproot та BitVM. P2PKH повністю називається «Pay to Public Key Hash», у цій схемі скрипт блокування UTXO містить хеш публічного ключа, для розблокування потрібно надіслати відповідний публічний ключ для цього хешу, що в основному відповідає звичайному підходу до переказу Bitcoin.

Наразі вузли Bitcoin повинні переконатися, що публічний ключ у розблокованому скрипті відповідає хешу публічного ключа, вказаному у замкнутому скрипті, тобто переконатися, що ключ, представлений розблокованою стороною, відповідає заданому ‘замку’ в UTXO.

Додатково, за схемою P2PKH, коли вузол Bitcoin отримує транзакцію, він об’єднує підпис розблокування, наданий користувачем, зі скриптом блокування UTXO Pubkey, який потрібно розблокувати, та виконує це в середовищі виконання BTC-скрипта. Нижче наведено результат об’єднання перед виконанням на наступному малюнку:

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

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

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

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

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

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

Це анімоване зображення: схема розблокування Bitcoin у P2PKH скрипті

Джерело: ** )

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

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

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

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

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

SegWit проти свідка

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

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

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

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

Фактично, в схемі DLC Bridge та BitVM2 будуть пакетно побудовані транзакції з послідовною залежністю, тому згадані раніше сценарії не рідкість.

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

Пізніше було введено оновлення SegWit (Segregated Witness), яке насправді повністю розширює ідентифікатор транзакції та розблоковує сценарій. При обчисленні хешу транзакції не потрібно включати дані розблокування сценарію. Замок UTXO, який відповідає оновленню SegWit, за замовчуванням має операційний код під назвою “OP_0” в першому положенні, що виступає як маркер. Відповідний розблокувальний сценарій був перейменований з Sig на Witness (Свідок).

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

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