Як реалізуються розумні контракти в мережі Bitcoin?
Автор: Simon shieh
Огляд передмови
У попередній статті «Подорож екологічними планами розширення BTC: куди звернутися за написами» ми обговорили технічні принципи та можливі проблеми безпеки популярної екології написів, а також згадали про можливість використання рекурсивних написів для впровадження смарт-контрактів. Однак, через обмеження Люка на скрипти Taproot, рекурсивний запис, здається, має деякі перешкоди.Тож чи є інші можливості для реалізації смарт-контрактів у мережі Bitcoin?
Робін Лінус, співзасновник розробника блокчейну ZeroSync, опублікував статтю під назвою «BitVM: Compute Anything on Bitcoin» 9 жовтня 2023 року, в якій він запропонував запустити план впровадження смарт-контрактів у блокчейн Bitcoin.
У документі пропонується дуже цікава ідея використовувати taproot для виконання майже будь-яких довільних обчислень і використовувати ці обчислення для перевірки того, що відбувається поза ланцюжком біткойн. Хитрість полягає в тому, щоб зберегти всю логіку поза ланцюжком і оскаржити нечесні результати в ланцюжку за допомогою кількох кроків обчислень, коли інші стверджують їх.
Іншими словами, це помістити логіку верифікатора в мережу біткойн, використати сильну консенсусну безпеку біткойна, щоб стати довіреною третьою стороною для будь-якого повного рівня обчислень Тьюрінга, а потім використовувати принцип оптимістичного зведення для реалізації -ланцюгові обчислення Перевірка результатів.
Отже, як розмістити частину логіки Verifier у мережі Bitcoin? Щоб повторити «гравірування» в попередньому розділі, я хотів би назвати це технологією «травлення» ланцюгів у мережі Bitcoin.
Схема логічного вентиля
Усередині вашого комп’ютера чи мобільного телефону електрика виконує всі функції комп’ютера, надаючи ряди одиниць і нулів. Це досягається за допомогою мільйонів крихітних компонентів, які називаються логічними воротами. Ці логічні елементи є основними будівельними блоками комп’ютерних мікросхем.
Кожен логічний вентиль отримує один або два «біти» інформації, і кожен біт є або 1, або 0. Потім логічний вентиль виконує просту логічну операцію відповідно до встановлених правил, таких як операції «І», «АБО» або «НІ». Результатом цих операцій також є біт, або 1, або 0. Після завершення операції результат передається до наступного логічного елемента.
Ця система, заснована на простих логічних операціях, привела до відкриття того, що навіть найскладніші обчислення та функції можна досягти шляхом поєднання великої кількості простих логічних операцій. Ця комбінація та взаємодія логічних вентилів є основою сучасних комп’ютерів та електронних пристроїв для виконання складних завдань. За допомогою цих основних логічних операцій комп’ютери можуть виконувати складні арифметичні операції, зберігати дані, відтворювати зображення та інші функції.
На зображенні нижче зображено дуже особливий логічний вентиль, який називається “NAND-шлюз”. Він може створити будь-який тип схеми логічного вентиля. Звичайно, він не може бути таким же ефективним, як інші спеціалізовані типи вентилів, але це все одно можна зробити. . Схема логічного вентиля BitVM складається з вентилів NAND.
Як Etch NAND Gate на Bitcoin
Створення шлюзу NAND на основі існуючих сценаріїв Bitcoin можна досягти шляхом поєднання хеш-блокування з двома кодами операцій, які можуть бути маловідомими: OP_BOOLAND і OP_NOT.
По-перше, хеш-блокування можна використовувати для створення сценарію розгалуження, який можна використати одним із двох способів: або для задоволення хеш-блокування, або для задоволення хеш-блокування B. Таким чином, шлях A поміщає 1 у стек, а шлях B поміщає 0 у стек.
Задовольнивши спеціальне хеш-блокування, ви можете «розблокувати» біт, який служить одним із входів для воріт NAND, який ми збираємося створити. Оскільки ви можете задовольнити вимоги лише одного зі шляхів, цей підхід дозволяє користувачеві надсилати лише один біт за раз.
Логіка воріт NAND полягає в тому, щоб отримати два біти як вхід і вивести один біт. Якщо обидва вхідні біти дорівнюють 1, вихід дорівнює 0; якщо вхідні дані є іншими комбінаціями, вихід дорівнює 1. Використовуючи два трюки хеш-блокування, ви можете надіслати ці два вхідні дані та перевірити, чи вихід правильний, для чого призначені OP_BOOLAND і OP_NOT.
Робота OP_BOOLAND є протилежністю воріт NAND: якщо обидва входи дорівнюють 1, вихід дорівнює 1; будь-яка інша комбінація входів дає 0. OP_NOT виводить значення, протилежне введеним. Таким чином, об’єднавши ці два коди операції, ви можете взяти два входи та зробити зворотну суму в стеку сценаріїв. Нарешті, ви можете використати OP_EQUALVERIFY і трюк хеш-блокування, щоб перевірити вихід твердження. Якщо фактичні результати операції NAND у стеку несумісні з результатами, заявленими користувачем, сценарій не пройде перевірку.
Таким чином, схема воріт NAND «вигравірувана» в сценарій біткойна, фактично змушуючи операцію віртуального шлюза NAND через сценарій біткойн.
Як травити великомасштабні схеми
Хоча ідея використання сценаріїв Taproot для травлення схем є крутою, не кажучи вже про надвеликі схеми, як-от ПК, навіть для реалізації будь-якого набору обчислень потрібні тисячі схем воріт NAND, які обмежені в біткойнах. складні обчислення в просторі сценаріїв Taproot?
BitVM пропонує метод дерева сценаріїв Taproot (Taproot Tree). Щоб реалізувати складні обчислювальні процеси в сценаріях Bitcoin, можна створювати обчислювальні схеми, з’єднуючи логічні вентилі послідовно. У цій схемі хеш-замки використовуються для зв’язування окремих дверей для досягнення послідовного виконання логічних операцій. Зокрема, якщо сценарій одного шлюзу створює інший вихідний результат C1 або C2 на основі іншого вхідного геш-прообразу (геш-значення відкритого тексту), тоді наступний шлюз використовуватиме відповідне значення хеш-блокування як свій вхід.
Цей метод може реалізовувати механізм штрафів, тобто, якщо ви намагаєтеся збрехати про результат попереднього гейта, ви можете відкрити лише оригінальне зображення іншого хеш-блокування. Цей механізм можна використовувати для інтерактивних обчислень між двома користувачами, коли вони заздалегідь погоджуються брати участь у певному обчислювальному завданні, а потім розкладають обчислювальний процес на схеми, що складаються лише з вентилів NAND. Їм потрібно вибрати відповідний хеш-блокування для кожного воріт у схемі та закодувати його в дерево сценаріїв, яке блокує UTXO.
Потім кілька адрес використовуються для формування матриці адрес Taproot, а потім логічна схема врізається в сценарій Taproot серії транзакцій UTXO, з’єднаних у структуру дерева за допомогою методу Taproot Tree, нарешті формуючи «контрактну» логіку, яка може виконувати певні обчислювальні завдання.
Проблема шахрайства
Проблема шахрайства є основою технології OP (Optimism Rollup) (хоча вона ще не реалізована~). Ідея полягає в тому, що перед тим, як пакет транзакцій надсилається пакетами, претендент запускає перевірку шахрайства (застава чи ставка) на транзакції, які вважаються неправильними. , контракт Verifier у основній мережі визначатиме, чи вчинив заявник зло на основі змін у корені стану після виконання, а потім розподілятиме активи, заставлені обома сторонами.
У bitVM дерево сценаріїв складається з двох ланцюгів.Крім дозволу перевіряючому підпорядковуватися одному ланцюгу, претендент також повинен мати можливість оскаржити заяву перевіряючого. Цього можна досягти шляхом попереднього підписання серії угод. Ці попередньо підписані транзакції підключаються за допомогою «Виклик->Відповідь->Виклик->…». Якщо одна сторона зупиниться на деякий час, інша сторона виграє виклик і відновить депозити обох сторін.
На зображенні вище показано серію попередньо підписаних транзакцій:
- Виклик: Вікі (претендент/верифікатор) випускає попереднє зображення в шляху до сценарію (ці попередні зображення відомі лише претенденту), яке використовується для оскарження доказу;
- Відповідь: Пол (правер) виконує відповідну логіку та надсилає кошти назад до початкового сценарію;
Будь-яке непослідовне твердження можна швидко спростувати після кількох раундів розслідування. Якщо перевірка припиняє співпрацювати з претендентом поза ланцюгом, претендент змусить перевірку співпрацювати в ланцюжку: щоразу, коли претендент розблокує хеш-блокування, кінцевий вузол Taproot, що відповідає кожному шлюзу NAND в UTXO перевірника, матиме лише It може бути витрачено, лише якщо доказувач знає прообраз, який має претендент. Проверювач може довести, що заданий листовий вузол Taproot виконується правильно, показуючи його входи та виходи. Передумова полягає в тому, що претендент відкриває вихідне зображення хешу, що відповідає Tapleaf, відкриваючи його. За допомогою бінарного пошуку претендент може заблокувати помилку перевірника після обмеженого раунду (O(logn)) викликів і відповідей.
Увесь процес передбачає кілька раундів взаємодії, щоб переконатися, що договір укладено правильно. Претендент може продовжувати кидати виклик провереру, доки той не підтвердить правильний результат для кожного воріт, або претендент може зняти кошти через певний час у випадку, якщо проверер не відповість на виклик. В ідеальному світі всі операції відбуваються поза ланцюгом, і обидві сторони співпрацюють для завершення розрахунку, але якщо співпраця порушується, обидві сторони можуть переконатися, що контракт вирішено правильно за допомогою гри викликів у ланцюзі.
Перешкоди при посадці та проблеми безпеки
Ця пропозиція передбачає обробку та створення надзвичайно великих обсягів даних. Дерево сценаріїв Taproot, яке використовується, може містити мільярди листових вузлів, а час обробки пов’язаних попередньо підписаних транзакцій може тривати щонайменше кілька годин, щоб забезпечити точний розрахунок. Виконання попередньо встановлених умов розблокування для кожної адреси Taproot потребує комісії за майнінг, тому чим більше комбінацій адрес, тим більша вартість.
Основним обмеженням цієї схеми є те, що вона працює лише для взаємодії між двома учасниками: один, як перевірник, який засвідчує точність її виконання, а інший, як верифікатор, оскаржує твердження першого. Хоча майбутні дослідження можуть знайти способи залучити більше учасників, наразі, здається, немає чіткого рішення.
У сценарії кооперативного врегулювання всі учасники повинні бути онлайн, що накладає певні обмеження на практичність і зручність протоколу.
З точки зору безпеки, в основному існують такі ризики безпеки:
-
Через обмеження вартості великий обсяг обчислювальної роботи має виконуватися поза ланцюгом. Обчислення поза ланцюгом мають деякі загальні ризики безпеки централізованих служб.
-
Велика кількість даних зберігається поза ланцюгом, а доступність і безпека даних також є факторами ризику, які необхідно враховувати.
-
Чи є логічні лазівки в самій витравленій схемі також є фактором ризику безпеки.Через нерозбірливість схеми потрібно сплатити більше витрат на аудит або формальну перевірку.
Metatrust допоміг Uniswap у проведенні всеосяжної формальної верифікації та має багатий досвід аудиту та формальної верифікації каналів ZK, що може забезпечити гарантію безпечного впровадження екосистеми BitVM.
Рішення в попередніх двох статтях — це технічні рішення, які тільки стали популярними цього року.У наступній статті ми представимо старіше та більш «ортодоксальне» рішення, оновлену версію Lightning Network — Taproott Assets.
