TL;DR

Вступ:

У цій статті надається інтерпретація офіційного документу BitVM, що пояснює підхід BitVM: Дані не обов'язково повинні бути в ланцюжку; вони публікуються і зберігаються поза ланцюжком, а в блокчейні зберігається лише Зобов'язання (Commitment).

Переслано Оригінальна назва статті: Спрощена інтерпретація BitVM: як перевірити докази шахрайства в блокчейні BTC (виконуючи EVM або інші опкоди VM)

Передмова: В даний час, Bitcoin Layer 2 став трендом, з десятками проектів, які самоідентифікують себе як "Bitcoin Layer 2". Багато з них, заявляючи, що вони є "Rollups", стверджують, що використовують підхід, запропонований в технічному документі BitVM, позиціонуючи BitVM як важливу частину екосистеми Біткоїна.

Однак, більшість існуючої літератури про BitVM не пояснює її принципи простими словами. Ця стаття, заснована на нашому прочитанні 8-сторінкового технічного документу BitVM і після консультацій з ресурсами, пов'язаними з Taproot, MAST-деревами і Bitcoin Script, пропонує спрощений підсумок. Щоб полегшити розуміння, ми змінили деякі вирази, наведені в офіційному документі BitVM, припускаючи, що читач має певні знання про рівень 2 і може зрозуміти основну ідею "доказів шахрайства".

Попередню концепцію BitVM можна підсумувати кількома реченнями: вона усуває потребу в даних в ланцюжку, спочатку публікуючи і зберігаючи дані поза ланцюжком, а в блокчейні зберігається тільки зобов'язання. У випадках оскарження або доведення шахрайства, в ланцюжок вносяться лише необхідні дані, щоб продемонструвати його зв'язок із Зобов'язанням в блокчейні. Згодом мейннет BTC перевіряє дані в ланцюжку на наявність будь-яких проблем і перевіряє, чи не займався виробник даних (вузол, що обробляє транзакції) зловмисною діяльністю. Цей підхід дотримується принципу "бритви Оккама" - "Сутності не повинні множитися без потреби" (якщо це можна зробити без ланцюжка, нехай це буде без ланцюжка).

Основний текст: Так звана схема захисту блокчейну BTC від шахрайства, заснована на BitVM, якщо говорити простою мовою:

1.По-перше, комп'ютер/процесор - це система вводу-виводу, що складається з великої кількості логічних схем. Одна з основних ідей BitVM полягає у використанні Bitcoin Script для імітації ефектів вводу-виводу логічних схем вентилів. Якщо схеми логічних вентилів можна змоделювати, то теоретично можна створити машину Тюрінга, яка виконуватиме всі обчислювальні задачі. Це означає, що якщо у вас достатньо ресурсів і робочої сили, ви можете зібрати команду інженерів, щоб спочатку змоделювати схеми логічних вентилів за допомогою елементарного коду Bitcoin Script, а потім використовувати величезну кількість схем логічних вентилів для реалізації функціональних можливостей EVM або WASM.

(Цей скріншот з навчальної гри: "Turing Complete", де основний зміст полягає у створенні повного процесора ЦП, особливо з використанням логічних вентилів, таких як NAND вентилі).

Дехто порівнює підхід BitVM з побудовою процесора M1 в "Minecraft" з використанням схем червоного каменю. Або ж це схоже на будівництво Емпайр Стейт Білдінг у Нью-Йорку з кубиків LEGO.

(Кажуть, що хтось витратив рік на створення "процесора" в "Minecraft").

1. Отже, навіщо використовувати Bitcoin Script для симуляції EVM або WASM? Чи не дуже громіздко? Причина полягає в тому, що більшість рішень другого рівня Біткоін часто підтримують мови високого рівня, такі як Solidity або Move, в той час як єдиною мовою, яка на даний момент може працювати безпосередньо в блокчейні Біткоін, є Bitcoin Script. Ця мова примітивна, складається з купи унікальних опкодів і не є повною мовою Тьюринга.

(Приклад коду Bitcoin Script)

Якщо Біткоін 2 рівня має на меті перевіряти докази шахрайства на 1 рівні, як це роблять рішення 2 рівня Ethereum, такі як Arbitrum, щоб значною мірою успадкувати безпеку BTC, він повинен безпосередньо перевіряти "спірну транзакцію" або "спірний операційний код" в блокчейні BTC. Це означає, що мова Solidity / EVM-опкоди, які використовуються на рівні 2, повинні бути повторно виконані в блокчейні Біткоїн. Виклик зводиться до наступного:

Використання Bitcoin Script, рідної, але рудиментарної мови програмування Bitcoin, для досягнення ефектів EVM або інших віртуальних машин.

Таким чином, з точки зору принципів компіляції, підхід BitVM транслює EVM / WASM / JavaScript коди в Bitcoin Script коди, а логічні схеми вентилів слугують проміжним представленням (IR) між "EVM кодами -> Bitcoin Script кодами".

(У технічному документі BitVM обговорюється загальний підхід до виконання певних "спірних інструкцій" в блокчейні Біткоїн)

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

1. Давайте обговоримо ще одну ключову концепцію, згадану в документі BitVM, а саме "Інтерактивні докази шахрайства", які дуже схожі на ті, що використовуються в Arbitrum.

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

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

Для цієї спірної операційної інструкції (OP Code) необхідно виконати її безпосередньо на рівні 1 разом з вхідними параметрами і перевірити вихідний результат (вузли рівня 1 порівнюють вихідний результат, який вони обчислили, з вихідним результатом, раніше опублікованим заявником). В Arbitrum це називається "Докази шахрайства в один крок". (В інтерактивному протоколі перевірки шахрайства Arbitrum використовується двійковий пошук для швидкого знаходження спірної інструкції та результату її виконання, після чого однокроковий доказ шахрайства надсилається на рівень 1 для остаточної перевірки).

Я продовжую розслідування:

1. Процес інтерактивний, обидві сторони беруть участь по черзі. Одна сторона сегментує історичні дані, що містяться в Rollup Block, а інша сторона вказує, який сегмент даних є проблемним. Це схоже на бінарний метод (насправді це процес поступового звуження діапазону, N/K).

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

3. Контракт ChallengeManager лише перевіряє, чи дійсний "сегмент даних", отриманий в результаті поділу вихідних даних.

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

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

Посилання:

Колишній технічний амбасадор Arbitrum пояснює структуру компонентів Arbitrum (Частина 1)

(Інтерактивна схема перевірки на шахрайство від Arbitrum, пояснення відносно приблизне)

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

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

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

4.Після обговорення "Інтерактивних доказів шахрайства" та "Однокрокових доказів шахрайства" ми поговоримо про MAST-дерева та докази Меркла. Раніше ми згадували, що в рішенні BitVM величезна кількість даних транзакцій і логічних схем вентилів, які обробляються поза ланцюжком на рівні 2, не передаються безпосередньо в ланцюжок. Лише мінімальна кількість схем даних / логічних вентилів включається в ланцюг, коли це необхідно. Однак нам потрібен спосіб довести, що ці дані, які спочатку не були відкриті, а тепер мають бути відкриті, не є сфабрикованими. Саме тут в гру вступає поняття зобов'язання в криптографії, і доказ Меркла є однією з форм такого зобов'язання.

Спочатку поговоримо про дерева MAST. Повна назва MAST - Merkelized Abstract Syntax Trees, що є трансформацією AST (Abstract Syntax Trees) зі сфери принципів компілятора у дерева Меркла. Отже, що таке АСТ? Простіше кажучи, це деревоподібна структура даних, яка розбиває складну команду на кілька базових операційних одиниць за допомогою лексичного аналізу.

(Прикладом дерева AST може бути розбиття простих обчислень, таких як "x=2, y=x*3", на коди операцій і дані, що лежать в їх основі. )

Отже, дерево MAST - це результат застосування мерклеїзації до дерева AST, що підтримує доведення Меркла. Однією з переваг дерев Меркла є їхня здатність ефективно "стискати" дані. Наприклад, якщо ви хочете опублікувати сегмент даних з дерева Меркла в блокчейні BTC, коли це необхідно, і при цьому переконатися, що цей сегмент даних дійсно існує в дереві Меркла, а не вибраний довільно, що ви робите?

Ви просто записуєте корінь дерева Меркла в блокчейн заздалегідь. У майбутньому достатньо буде представити Доведення Меркла, яке доводить, що частина даних існує на дереві Меркла, що відповідає кореню.

(Взаємозв'язок між доказом Меркла/гілкою та коренем)

Таким чином, немає необхідності зберігати повне дерево MAST в блокчейні BTC, достатньо заздалегідь розкрити його корінь в якості зобов'язання. За необхідності, достатньо представити сегмент даних + Merkle Proof/Відгалуження. Це значно зменшує обсяг даних в ланцюжку, гарантуючи, що дані в ланцюжку дійсно існують в дереві MAST. Більше того, розкриття лише невеликої частини сегментів даних + Merkle Proof в блокчейні BTC, а не всіх даних, може значно посилити захист конфіденційності.

Посилання:Приховування даних та захист від шахрайства: Чому Плазма не підтримує смарт-контракти

(приклад дерева MAST)

У рішенні BitVM всі логічні схеми вентилів виражаються за допомогою Bitcoin-скриптів, організованих у велике MAST-дерево. Нижнє листя цього дерева, позначене на діаграмі як Content, відповідає логічним схемам вентилів, реалізованим у скрипті Bitcoin. Пропонент 2-го рівня часто публікує корінь дерева MAST в блокчейні BTC, при цьому кожне дерево MAST асоціюється з транзакцією, що включає всі його вхідні параметри / коди операцій / схеми логічних вентилів. Це дещо схоже на те, як Proposer в Arbitrum публікує Rollup Blocks в блокчейні Ethereum.

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

(Джерело: https://medium.com/crypto-garage/deep-dive-into-bitvm-computing-paradigm-to-express-turing-complete-bitcoin-contracts-1c6cb05edfca)

1. До цього моменту ми розглянули найбільш важливі аспекти рішення BitVM. Хоча деякі деталі все ще можуть бути дещо незрозумілими, ми вважаємо, що читачі можуть зрозуміти суть та основні моменти BitVM. Щодо "зобов'язання щодо бітового значення", згаданого в технічному завданні, воно призначене для того, щоб запобігти присвоєнню Пропонентом як 0, так і 1 вхідним значенням логічного вентилю, коли він буде змушений перевіряти схему логічного вентилю в ланцюзі, тим самим створюючи неоднозначність і плутанину.

Підсумовуючи, схема BitVM починається з використання Bitcoin-скрипту для вираження логічних схем вентилів, потім використовує ці схеми для вираження опкодів EVM/інших віртуальних машин, які, в свою чергу, виражають потік обробки будь-якої заданої інструкції транзакції, і, нарешті, організовує їх в дерево Меркла/MAST-дерево. Якщо потік обробки транзакцій, представлений таким деревом, дуже складний, він може легко перевищити 100 мільйонів листків, тому дуже важливо мінімізувати простір блоку, зайнятий зобов'язаннями, і обсяг, на який впливають докази шахрайства.

Хоча однокроковий доказ шахрайства вимагає лише дуже невеликої кількості даних і скрипт логічних воріт в ланцюжку, повне дерево Меркла має зберігатися поза ланцюжком протягом тривалого часу, щоб до нього можна було отримати доступ в ланцюжку в будь-який час, якщо хтось його оскаржить. Кожна транзакція на рівні 2 генерує велике дерево Меркла, і можна уявити, яке навантаження на вузли припадає на обчислення та зберігання даних. Більшість людей можуть не захотіти запускати вузли (однак, такі історичні дані можна поступово вилучати, і мережа B^2 спеціально вводить zk-докази зберігання, подібні до Filecoin, щоб стимулювати вузли зберігання зберігати історичні дані впродовж тривалого часу).

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

Тим не менш, існує багато проблем при розробці рішень рівня 2 на основі BitVM, таких як:

1) Теоретично, для подальшого стиснення даних не обов'язково перевіряти опкоди безпосередньо на рівні 1. Потік обробки опкодів може бути додатково стиснутий у zk-доказ, що дозволяє оскаржувати кроки перевірки zk-доказу. Це може значно зменшити обсяг даних у ланцюжку. Однак конкретні деталі розробки можуть бути дуже складними.

2) Пропонентам і Челенджерам потрібно постійно генерувати взаємодію поза ланцюжком. Те, як має бути розроблений протокол, і як процес прийняття зобов'язань і оскарження має бути оптимізований в процесі обробки, потребуватиме багато інтелектуальних зусиль.

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

1. Ця стаття передрукована з[Geek Web3], Переслати оригінальну назву "Мінімалістична інтерпретація BitVM: Як перевірити доказ шахрайства в ланцюжку BTC (виконати код операції EVM або іншої ВМ)", авторське право належить оригінальному автору [Faust & Misty Moon].
   . Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.