Біткойн — це децентралізований, безпечний і надійний цифровий актив. Однак вона має значні обмеження, які не дозволяють їй стати масштабованою мережею для платежів та інших програм. Проблема масштабування біткойна викликає занепокоєння з моменту його створення. Модель Bitcoin UTXO розглядає кожну транзакцію як незалежну подію, що призводить до системи без стану, яка не має можливості виконувати складні, залежні від стану обчислення. Тому, хоча біткойн може виконувати прості сценарії та транзакції з декількома підписами, йому важко сприяти складним і динамічним контрактним взаємодіям, поширеним на платформах блокчейну з підтримкою стану. Ця проблема значно обмежує сферу застосування децентралізованих додатків (dApps) і складних фінансових інструментів, які можна створювати на біткойнах, тоді як платформи державної моделі забезпечують більш різноманітне середовище для розгортання та виконання багатофункціональних смарт-контрактів.
Для розширення біткойна в основному існують такі технології, як державні канали, сторонні ланцюги та перевірка клієнтів. Серед них державні канали надають безпечні та різноманітні платіжні рішення, але вони обмежені у своїй здатності перевіряти довільно складні розрахунки. Це обмеження зменшує його використання в різноманітних сценаріях, які потребують складної умовної логіки та взаємодії. Сайдчейни, хоча й підтримують широкий спектр додатків і забезпечують різноманітні функції, окрім біткойнів, мають нижчий рівень безпеки. Ця різниця в безпеці пов’язана з тим фактом, що сайдчейни використовують незалежні механізми консенсусу, які набагато менш надійні, ніж механізм консенсусу біткойнів. Перевірка на стороні клієнта за допомогою моделі Bitcoin UTXO може обробляти складніші транзакції, але вона не має можливості двостороннього обмеження контрольної суми з Bitcoin, що робить її безпеку нижчою, ніж Bitcoin. Дизайн протоколів перевірки клієнта поза мережею базується на серверній або хмарній інфраструктурі, що може призвести до централізації або потенційної цензури через скомпрометовані сервери. Дизайн перевірки на стороні клієнта поза мережею також ускладнює інфраструктуру блокчейну, що потенційно може призвести до проблем масштабованості.
У грудні 2023 року керівник проекту ZeroSync Робін Лінус опублікував білий документ під назвою «BitVM: Compute Anything On Bitcoin», який спонукав усіх задуматися про покращення програмованості Bitcoin. У цьому документі пропонується контрактне рішення Bitcoin, яке може досягти повноти Тьюринга без зміни консенсусу мережі Bitcoin, так що будь-які складні розрахунки можна перевірити на Bitcoin без зміни основних правил Bitcoin. BitVM повністю використовує Bitcoin Script і Taproot для досягнення оптимістичного зведення. На основі підпису Лампорта (також відомого як зобов’язання бітів) між двома біткойн UTXO встановлюється з’єднання для реалізації сценаріїв біткойн із збереженням стану. Здійснюючи велику програму на адресу Taproot, оператори та валідатори беруть участь у широкій взаємодії поза ланцюгом, що призводить до невеликого сліду ланцюга. Якщо обидві сторони співпрацюють, довільно складні обчислення поза ланцюгом із збереженням стану можна виконувати, не залишаючи жодних слідів у ланцюзі. Якщо обидві сторони не співпрацюють, коли виникає суперечка, потрібне виконання в ланцюжку. В результаті BitVM значно розширює потенційні варіанти використання біткойна, дозволяючи біткойну служити не тільки як валюта, але й як платформа перевірки для різноманітних децентралізованих програм і складних обчислювальних завдань.
Однак, незважаючи на те, що технологія BitVM має великі переваги в розширенні біткойнів, вона все ще перебуває на ранніх стадіях і все ще є деякі проблеми з точки зору ефективності та безпеки. Наприклад: (1) виклики та відповіді вимагають кількох взаємодій, що призводить до дорогих зборів за обробку та тривалих циклів викликів; (2) одноразові дані підпису Лампорта великі, і довжину даних потрібно зменшити; (3) хеш-функція є складний і вимагає хеш-функції, зрозумілої для біткойнів, щоб зменшити витрати; (4) Існуючий контракт BitVM величезний, а ємність блоків Bitcoin обмежена. Less s можна використовувати для реалізації меншої кількості BitVM, заощаджуючи простір блоків Bitcoin і покращуючи ефективність BitVM; (5 ) Існуюча BitVM приймає модель дозволів. Лише учасники альянсу можуть ініціювати виклики, і це обмежено лише двома сторонами. Її слід розширити до моделі багатосторонніх викликів без дозволу, щоб ще більше зменшити припущення про довіру. З цією метою ця стаття пропонує деякі ідеї оптимізації для подальшого підвищення ефективності та безпеки BitVM.
2. Принцип BitVM
BitVM позиціонується як оф-чейн-контракт біткойнів і прагне просувати функції контракту біткойн. Наразі сценарії біткойн повністю не мають стану, тому, коли виконується сценарій біткойн, його середовище виконання скидається після кожного сценарію. Не існує власного способу, щоб сценарій 1 і сценарій 2 мали однакове значення x, і Bitcoin Script не підтримує це нативно. Однак ви все ще можете використовувати існуючі коди операцій, щоб зробити сценарій біткойна станом за допомогою одноразового підпису Лампорта. Наприклад, ви можете змусити x в 1 і 2 бути однаковими значеннями. Учасники можуть бути покарані, якщо вони підпишуть суперечливі значення x. Обчислення програми BitVM відбуваються поза ланцюгом, тоді як перевірка результатів розрахунку відбувається в ланцюзі. Поточний блок біткойн має обмеження в 1 МБ. Якщо обчислення перевірки надто складне, технологію OP можна використовувати для адаптації режиму відповіді на виклик для підтримки верифікації обчислення більшої складності.
Подібно до Optimistic Rollup і пропозиції MATT (Merkelize All The Things), система BitVM базується на протоколах захисту від шахрайства та виклику-відповіді, але не потребує модифікації правил консенсусу Bitcoin. Базові примітиви BitVM прості, в основному базуються на хеш-блокуваннях, блокуваннях часу та великих деревах Taproot.
Пристрій перевірки фіксує байт за байтом, але перевірка всіх обчислень у ланцюжку буде занадто дорогою. Отже, верифікатор виконує серію ретельно розроблених викликів, щоб коротко спростувати хибні твердження прувера. Провери та валідатори спільно попередньо підписують низку транзакцій запиту та відповіді, які використовуються для вирішення суперечок, що забезпечує універсальну обчислювальну перевірку біткойнів.
Ключовими компонентами BitVM є:
Зобов’язання щодо схем: Перевірювачі та верифікатори компілюють програми у великі двійкові схеми. Проверювач фіксує схему за адресою Taproot, і кожен кінцевий сценарій під цією адресою відповідає кожному логічному вентилю в схемі. Ядро базується на бітовому зобов’язанні для реалізації зобов’язання логічного вентиля та зобов’язання схеми.
Виклик і відповідь: Перевірювачі та верифікатори попередньо підписують серію транзакцій для реалізації гри виклик-відповідь. В ідеалі ця взаємодія виконується поза ланцюгом, але також може виконуватися в ланцюзі, коли прувер не співпрацює.
Неоднозначне покарання: Якщо перевіряючий робить будь-яке неправильне твердження, верифікатор може забрати депозит перевіряючого після успішного виклику, щоб перешкодити злій поведінці перевіряючого.
3. Оптимізація BitVM
3.1 Зменшіть кількість взаємодій OP на основі ZK
Наразі існує 2 основні зведені пакети: ZK Rollups і OP Rollups. Серед них ZK Rollups покладається на перевірку дійсності ZK Proof, тобто криптографічний доказ правильності виконання, а його безпека покладається на припущення обчислювальної складності; OP Rollups покладається на Fraud Proof, припускаючи, що подані стани правильні, встановлюючи Період виклику зазвичай становить 7 днів, і його безпека передбачає, що принаймні одна чесна сторона в системі може виявити неправильний стан і надати докази шахрайства. Припустімо, що максимальна кількість кроків програми перевірки BitVM становить 2 ^{ 32 }, а необхідна пам’ять — 2 ^{ 32 }* 4 байти, що становить приблизно 17 ГБ. У гіршому випадку це займає близько 40 раундів виклику та відповіді, близько півроку, а загальний скрипт становить близько 150 Кб. У цій ситуації відчувається серйозна нестача стимулів, але на практиці цього майже ніколи не буває.
Розгляньте можливість використання доказів із нульовим знанням, щоб зменшити кількість викликів BitVM, тим самим підвищивши ефективність BitVM. Відповідно до теорії доказу з нульовим знанням, якщо дані Data задовольняють алгоритму F, доведено, що доказ задовольняє алгоритм перевірки Verify, тобто алгоритм перевірки видає True; якщо дані Data не задовольняють алгоритм F, доведено, що доказ не задовольняє алгоритм перевірки Verify, тобто алгоритм перевірки видає False. У системі BitVM, якщо претендент не розпізнає дані, надані прувером, ініціюється виклик.
Для алгоритму F використовуйте метод дихотомії, щоб його розділити. Припустімо, що знадобиться 2^n разів, щоб знайти точку помилки; якщо складність алгоритму надто велика, n буде великим, і це займе багато часу. Однак складність алгоритму перевірки Verify для доказу з нульовим знанням виправлена. Весь процес перевірки та перевірки алгоритму Verify є загальнодоступним, а вихідні дані виявляються False. Перевага доказу з нульовим знанням полягає в тому, що обчислювальна складність, необхідна для відкриття алгоритму перевірки Verify, набагато нижча, ніж у бінарного методу для відкриття оригінального алгоритму F. Таким чином, за допомогою підтвердження з нульовим знанням BitVM більше не оскаржує оригінальний алгоритм F, а перевіряє алгоритм Verify, зменшуючи кількість раундів перевірки та скорочуючи цикл перевірки.
Нарешті, хоча ефективність захисту від нульових знань і захисту від шахрайства залежить від різних припущень щодо безпеки, їх можна об’єднати, щоб створити ZK Fraud Proof і реалізувати ZK Proof на вимогу. На відміну від повного ZK Rollup, якому більше не потрібно генерувати ZK-доказ для кожного окремого переходу стану, модель On-Demand робить ZK-доказ потрібним лише за наявності проблем, тоді як уся зведена конструкція залишається оптимістичною. Таким чином, отриманий стан все ще дійсний за замовчуванням, доки хтось його не оскаржить. Якщо в певному стані немає виклику, немає потреби генерувати доказ ZK. Однак, якщо учасник ініціює виклик, для коректності всіх транзакцій у блоці виклику необхідно створити ZK Proof. У майбутньому ми можемо вивчити можливість створення ZK Fraud Proof для однієї суперечливої інструкції, щоб уникнути обчислювальних витрат на генерацію ZK Proof постійно.
3.2 Одноразовий підпис, зручний для біткойнів
У мережі Bitcoin транзакції, які відповідають правилам консенсусу, є дійсними транзакціями, але крім правил консенсусу також вводяться правила стандартності. Біткойн-вузли передають лише трансляцію стандартних транзакцій, єдиний спосіб пакетувати дійсні, але нестандартні транзакції – це безпосередньо працювати з майнерами.
Згідно з правилами консенсусу, максимальний розмір успадкованих (не Segwit) транзакцій становить 1 МБ, який займає весь блок. Але ліміт стандартності для успадкованих транзакцій становить 100 Кб. Згідно з правилами консенсусу, максимальний розмір транзакції Segwit становить 4 МБ, що є обмеженням ваги. Однак обмеження стандартності транзакцій Segwit становить 400 КБ.
Підпис Lamport є основним компонентом BitVM. Він зменшує довжину підпису та відкритого ключа, що допомагає зменшити дані транзакцій і, таким чином, зменшити комісію за обробку. Одноразовий підпис Лампорта вимагає використання хеш-функції (наприклад, функції односторонньої перестановки f). У схемі одноразового підпису Лампорта довжина повідомлення становить v біт, довжина відкритого ключа — 2 v біт, а довжина підпису також 2 v біт. Підпис і відкритий ключ довгі і потребують великої кількості газу для зберігання. Тому існує потреба знайти схеми підпису з подібними функціями, щоб зменшити довжину підпису та відкритого ключа. У порівнянні з одноразовим підписом Lamport, одноразовий підпис Winternitz значно зменшив довжину підпису та відкритого ключа, але збільшив обчислювальну складність підпису та перевірки підпису.
У схемі одноразового підпису Winternitz спеціальна функція P використовується для відображення v-бітового повідомлення у вектор s довжини n. Значення кожного елемента в s дорівнює {0,..., d}. Схема одноразового підпису Лампорта є схемою одноразового підпису Вінтерніца в окремому випадку d=1. У схемі одноразового підпису Вінтерніца співвідношення між n, d, v задовольняє: n≈v/log 2(d+ 1). Коли d= 15, є n≈(v/4)+ 1. Для підпису Вінтерніца, що містить n елементів, довжина відкритого ключа та довжина підпису в 4 рази коротші, ніж у схемі одноразового підпису Лампорта. Однак складність перевірки підпису зростає в 4 рази. Використання d= 15, v= 160, f=ripemd 160(x) у BitVM для впровадження одноразового підпису Winternitz може зменшити розмір бітового зобов’язання на 50%, таким чином зменшивши комісію за транзакції BitVM принаймні на 50%. У майбутньому під час оптимізації існуючої реалізації сценарію біткойн Winternitz можна досліджувати більш компактні схеми одноразового підпису, виражені в сценарії біткойн.
3.3 Хеш-функції, зручні для біткойнів
Згідно з правилами консенсусу, максимальний розмір P 2 TR становить 10 КБ, а максимальний розмір P 2 TR-свідка такий самий, як максимальний розмір транзакції Segwit, який становить 4 МБ. Однак верхня межа стандартності свідка P 2 TR становить 400 кБ.
Наразі мережа біткойн не підтримує OP_CAT, і рядки не можуть бути з’єднані для перевірки шляху Merkle. Таким чином, необхідно використовувати існуючі сценарії Bitcoin для реалізації хеш-функції, зручної для Bitcoin, з оптимальним розміром і розміром свідка для підтримки функції перевірки підтвердження включення Merkle.
BLAKE 3 є оптимізованою версією хеш-функції BLAKE 2 і представляє режим дерева Bao. У порівнянні з BLAKE 2 на базі s, кількість раундів його функції стиснення зменшено з 10 до 7. Хеш-функція BLAKE 3 розбиває вхідні дані на послідовні фрагменти розміром 1024 байти, останній фрагмент може бути коротшим, але не порожнім. Якщо є лише один фрагмент, цей фрагмент є кореневим вузлом і єдиним вузлом дерева. Розташуйте ці фрагменти як листкові вузли бінарного дерева, а потім стискайте кожен фрагмент незалежно.
Коли BitVM використовується для перевірки сценарію перевірки включення Merkle, вхідні дані хеш-операції складаються з двох 256-бітових хеш-значень, тобто вхідні дані хеш-операції становлять 64 байти. Під час використання хеш-функції BLAKE 3 ці 64 байти можна розподілити в одному фрагменті, і вся хеш-операція BLAKE 3 потребує лише одного разу застосувати функцію стиснення до окремого фрагменту. У функції стиснення BLAKE 3 необхідно запустити функцію округлення 7 разів і функцію перестановки 6 разів.
Наразі базові операції, такі як XOR, модульне додавання та зсув біта вправо на основі значень u 32, завершено в BitVM, і хеш-функцію BLAKE 3, реалізовану сценарієм Bitcoin, можна легко зібрати. Використовуйте 4 окремі байти в стеку, щоб представити u 32 слова для реалізації u 32 додавання, u 32 порозрядного XOR і u 32 побітового повороту, необхідних для BLAKE 3. Поточний сценарій хеш-функції BLAKE 3 Bitcoin має загальний розмір близько 100 КБ, цього достатньо для створення іграшкової версії BitVM.
Крім того, ці коди BLAKE 3 можна розділити, дозволяючи Verifier і Prover значно скоротити необхідні дані в ланцюжку, розділивши виконання гри виклик-відповідь навпіл замість того, щоб виконувати її повністю. Нарешті, скористайтеся сценарієм Bitcoin для реалізації хеш-функцій, таких як Keccak-256 і Grøstl, виберіть найбільш зручну для Bitcoin хеш-функцію та досліджуйте інші нові хеш-функції для Bitcoin.
3.4 менше s BitVM
less s — це метод виконання смарт-контрактів поза мережею за допомогою підписів Шнорра. Концепція Scripless s народилася з Mimblewimble, яка не зберігає постійних даних, крім ядра та його підпису.
Перевагами less s є функціональність, конфіденційність та ефективність.
**Функції: **less s може збільшити обсяг і складність смарт-контрактів. Можливості біткойн-скриптів обмежені кількістю OP_CODES, увімкнених у мережі, а менше s переміщує специфікацію та виконання смарт-контрактів із ланцюжка на обговорення лише між учасниками проектного контракту, не чекаючи, поки ввімкнеться форк мережі біткойн. Новий код операції.
**Конфіденційність: **Перенесення специфікації та виконання смарт-контрактів із внутрішнього ланцюга в інший підвищує конфіденційність. У ланцюжку багато деталей контракту будуть передані всій мережі, включаючи кількість та адреси учасників і суму переказу. Переміщуючи смарт-контракти за межі ланцюга, мережа знає лише те, що учасники погоджуються з тим, що умови їхніх контрактів виконано, а базові транзакції дійсні.
**Ефективність: **менше s мінімізує кількість даних, які перевіряються та зберігаються в мережі. Завдяки переміщенню смарт-контрактів за межі ланцюга комісія за управління повними вузлами буде зменшена, а комісія за транзакції для користувачів також зменшиться.
less s — це підхід до розробки криптографічних протоколів для біткойнів, який уникає виконання явних смарт-контрактів. Основна ідея полягає в тому, щоб використовувати криптографічні алгоритми для досягнення бажаної функціональності, а не використовувати сценарії для досягнення функціональності. Підписи адаптерів і мультипідписи є оригінальними будівельними блоками менших s. Використовуючи менше s, ви можете досягти менших транзакцій, ніж звичайні транзакції, і зменшити комісію за транзакції.
За допомогою менше s можна використовувати мультипідпис Schnorr і підпис адаптера, який більше не забезпечує хеш-значення та хеш-прообрази, як рішення BitVM, а також може реалізувати зобов’язання логічного вентиля в схемі BitVM, тим самим зберігаючи BitVM простір сценарію та підвищення ефективності BitVM. Хоча існуюча схема less s може зменшити простір сценарію BitVM, для об’єднання відкритого ключа потрібна велика кількість взаємодії між перевіряючим і претендентом. У майбутньому ми вдосконалимо це рішення та спробуємо впровадити Scripless у окремі функціональні модулі BitVM.
3.5 Багатоучасникний виклик без дозволу
Причина, чому поточні виклики BitVM вимагають дозволу за замовчуванням, полягає в тому, що UTXO Bitcoin може бути виконано лише один раз, що дозволяє зловмисному верифікатору «марнувати» контракт, кидаючи виклик чесному перевіряльнику. Зараз BitVM обмежено двостороннім режимом виклику. Достовірник, який намагається вчинити зло, може одночасно запустити виклик із верифікатором, яким він керує, таким чином «марнуючи» контракт, роблячи зловмисну дію успішною, а інші верифікатори не можуть запобігти цій поведінці. Тому, базуючись на біткойнах, необхідно вивчити багатосторонній протокол виклику OP без дозволу, який може розширити існуючу модель довіри BitVM 1-of-n до 1-of-N. Серед них N набагато більше n. Крім того, існує потреба вивчити та вирішити проблему претендентів, які вступають у змову з перевіряючими або злісно оскаржують «змарні» контракти. Зрештою, впровадження протоколу BitVM з меншою довірою.
Завдання для кількох учасників без дозволу, що дозволяє будь-кому брати участь без списку дозволів. Це означає, що користувачі можуть виводити монети з L2 без залучення довіреної третьої сторони. Крім того, будь-який користувач, який хоче брати участь у протоколі виклику OP, може оскаржити та видалити недійсні зняття.
Розширення BitVM до моделі багатостороннього виклику без дозволу вимагає вирішення таких атак:
Атака Sybil: Навіть якщо зловмисник підробляє кілька ідентифікацій для участі в суперечці, одна чесна сторона може виграти суперечку. Якщо вартість чесної сторони захисту правильного результату лінійно пов’язана з кількістю зловмисників, тоді, коли залучено велику кількість зловмисників, вартість виграшу суперечки стає нереальною та вразливою для атаки відьми. У статті Permissionless Refereed Tournaments пропонується кардинальний алгоритм вирішення суперечок. Вартість перемоги одного чесного учасника в суперечці зростає логарифмічно з кількістю опонентів, а не лінійно.
Атака із затримкою: зловмисна сторона або група зловмисних сторін дотримується певної стратегії, щоб запобігти або затримати підтвердження правильних результатів (наприклад, виведення активів на L1) на L1 і змусити чесних перевірників витрачати комісію L1. Цю проблему можна вирішити, вимагаючи від претендентів робити ставки заздалегідь. Якщо претендент розпочинає відкладену атаку, його ставка втрачається. Однак, якщо зловмисник готовий пожертвувати ставками в певних межах, щоб провести атаку із затримкою, повинні бути контрзаходи, щоб зменшити вплив атаки із затримкою. Алгоритм, запропонований у статті BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol, робить так, що незалежно від того, скільки застави зловмисник готовий втратити, найгірша атака може спричинити лише певну верхню межу затримки.
У майбутньому ми досліджуватимемо модель багатостороннього виклику BitVM без дозволу, яка підходить для характеристик біткойнів і може протистояти вищезазначеним проблемам атаки.
4 Висновок
Вивчення технології BitVM тільки почалося. У майбутньому буде досліджено та впроваджено більше напрямків оптимізації, щоб досягти розширення Bitcoin та процвітання екосистеми Bitcoin.
посилання
BitVM: обчислюйте все на біткойнах
BitVM: позаланцюгові біткойн-контракти
Робін Лінус на BitVM
[bitcoin-dev] BitVM: будь-що обчислюйте на біткойнах
Дивна пара: ZK і оптимістичні зведені пакети на дату масштабованості
Рішення для відстрочення атак на зведені пакети - Arbitrum Research
Інтерактивні обчислювальні ігри для кількох гравців. Примітки
Жирний шрифт: Обмежена затримка ліквідності в протоколі перевірки зведених даних
Реферовані турніри без дозволу
Оригінальне посилання
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Аналіз принципів BitVM та міркування щодо оптимізації
Джерело: Bitlayer Research Group
Автор оригіналу: lynndell, mutourend.
1. Введення
Біткойн — це децентралізований, безпечний і надійний цифровий актив. Однак вона має значні обмеження, які не дозволяють їй стати масштабованою мережею для платежів та інших програм. Проблема масштабування біткойна викликає занепокоєння з моменту його створення. Модель Bitcoin UTXO розглядає кожну транзакцію як незалежну подію, що призводить до системи без стану, яка не має можливості виконувати складні, залежні від стану обчислення. Тому, хоча біткойн може виконувати прості сценарії та транзакції з декількома підписами, йому важко сприяти складним і динамічним контрактним взаємодіям, поширеним на платформах блокчейну з підтримкою стану. Ця проблема значно обмежує сферу застосування децентралізованих додатків (dApps) і складних фінансових інструментів, які можна створювати на біткойнах, тоді як платформи державної моделі забезпечують більш різноманітне середовище для розгортання та виконання багатофункціональних смарт-контрактів.
Для розширення біткойна в основному існують такі технології, як державні канали, сторонні ланцюги та перевірка клієнтів. Серед них державні канали надають безпечні та різноманітні платіжні рішення, але вони обмежені у своїй здатності перевіряти довільно складні розрахунки. Це обмеження зменшує його використання в різноманітних сценаріях, які потребують складної умовної логіки та взаємодії. Сайдчейни, хоча й підтримують широкий спектр додатків і забезпечують різноманітні функції, окрім біткойнів, мають нижчий рівень безпеки. Ця різниця в безпеці пов’язана з тим фактом, що сайдчейни використовують незалежні механізми консенсусу, які набагато менш надійні, ніж механізм консенсусу біткойнів. Перевірка на стороні клієнта за допомогою моделі Bitcoin UTXO може обробляти складніші транзакції, але вона не має можливості двостороннього обмеження контрольної суми з Bitcoin, що робить її безпеку нижчою, ніж Bitcoin. Дизайн протоколів перевірки клієнта поза мережею базується на серверній або хмарній інфраструктурі, що може призвести до централізації або потенційної цензури через скомпрометовані сервери. Дизайн перевірки на стороні клієнта поза мережею також ускладнює інфраструктуру блокчейну, що потенційно може призвести до проблем масштабованості.
У грудні 2023 року керівник проекту ZeroSync Робін Лінус опублікував білий документ під назвою «BitVM: Compute Anything On Bitcoin», який спонукав усіх задуматися про покращення програмованості Bitcoin. У цьому документі пропонується контрактне рішення Bitcoin, яке може досягти повноти Тьюринга без зміни консенсусу мережі Bitcoin, так що будь-які складні розрахунки можна перевірити на Bitcoin без зміни основних правил Bitcoin. BitVM повністю використовує Bitcoin Script і Taproot для досягнення оптимістичного зведення. На основі підпису Лампорта (також відомого як зобов’язання бітів) між двома біткойн UTXO встановлюється з’єднання для реалізації сценаріїв біткойн із збереженням стану. Здійснюючи велику програму на адресу Taproot, оператори та валідатори беруть участь у широкій взаємодії поза ланцюгом, що призводить до невеликого сліду ланцюга. Якщо обидві сторони співпрацюють, довільно складні обчислення поза ланцюгом із збереженням стану можна виконувати, не залишаючи жодних слідів у ланцюзі. Якщо обидві сторони не співпрацюють, коли виникає суперечка, потрібне виконання в ланцюжку. В результаті BitVM значно розширює потенційні варіанти використання біткойна, дозволяючи біткойну служити не тільки як валюта, але й як платформа перевірки для різноманітних децентралізованих програм і складних обчислювальних завдань.
Однак, незважаючи на те, що технологія BitVM має великі переваги в розширенні біткойнів, вона все ще перебуває на ранніх стадіях і все ще є деякі проблеми з точки зору ефективності та безпеки. Наприклад: (1) виклики та відповіді вимагають кількох взаємодій, що призводить до дорогих зборів за обробку та тривалих циклів викликів; (2) одноразові дані підпису Лампорта великі, і довжину даних потрібно зменшити; (3) хеш-функція є складний і вимагає хеш-функції, зрозумілої для біткойнів, щоб зменшити витрати; (4) Існуючий контракт BitVM величезний, а ємність блоків Bitcoin обмежена. Less s можна використовувати для реалізації меншої кількості BitVM, заощаджуючи простір блоків Bitcoin і покращуючи ефективність BitVM; (5 ) Існуюча BitVM приймає модель дозволів. Лише учасники альянсу можуть ініціювати виклики, і це обмежено лише двома сторонами. Її слід розширити до моделі багатосторонніх викликів без дозволу, щоб ще більше зменшити припущення про довіру. З цією метою ця стаття пропонує деякі ідеї оптимізації для подальшого підвищення ефективності та безпеки BitVM.
2. Принцип BitVM
BitVM позиціонується як оф-чейн-контракт біткойнів і прагне просувати функції контракту біткойн. Наразі сценарії біткойн повністю не мають стану, тому, коли виконується сценарій біткойн, його середовище виконання скидається після кожного сценарію. Не існує власного способу, щоб сценарій 1 і сценарій 2 мали однакове значення x, і Bitcoin Script не підтримує це нативно. Однак ви все ще можете використовувати існуючі коди операцій, щоб зробити сценарій біткойна станом за допомогою одноразового підпису Лампорта. Наприклад, ви можете змусити x в 1 і 2 бути однаковими значеннями. Учасники можуть бути покарані, якщо вони підпишуть суперечливі значення x. Обчислення програми BitVM відбуваються поза ланцюгом, тоді як перевірка результатів розрахунку відбувається в ланцюзі. Поточний блок біткойн має обмеження в 1 МБ. Якщо обчислення перевірки надто складне, технологію OP можна використовувати для адаптації режиму відповіді на виклик для підтримки верифікації обчислення більшої складності.
Подібно до Optimistic Rollup і пропозиції MATT (Merkelize All The Things), система BitVM базується на протоколах захисту від шахрайства та виклику-відповіді, але не потребує модифікації правил консенсусу Bitcoin. Базові примітиви BitVM прості, в основному базуються на хеш-блокуваннях, блокуваннях часу та великих деревах Taproot.
Пристрій перевірки фіксує байт за байтом, але перевірка всіх обчислень у ланцюжку буде занадто дорогою. Отже, верифікатор виконує серію ретельно розроблених викликів, щоб коротко спростувати хибні твердження прувера. Провери та валідатори спільно попередньо підписують низку транзакцій запиту та відповіді, які використовуються для вирішення суперечок, що забезпечує універсальну обчислювальну перевірку біткойнів.
Ключовими компонентами BitVM є:
3. Оптимізація BitVM
3.1 Зменшіть кількість взаємодій OP на основі ZK
Наразі існує 2 основні зведені пакети: ZK Rollups і OP Rollups. Серед них ZK Rollups покладається на перевірку дійсності ZK Proof, тобто криптографічний доказ правильності виконання, а його безпека покладається на припущення обчислювальної складності; OP Rollups покладається на Fraud Proof, припускаючи, що подані стани правильні, встановлюючи Період виклику зазвичай становить 7 днів, і його безпека передбачає, що принаймні одна чесна сторона в системі може виявити неправильний стан і надати докази шахрайства. Припустімо, що максимальна кількість кроків програми перевірки BitVM становить 2 ^{ 32 }, а необхідна пам’ять — 2 ^{ 32 }* 4 байти, що становить приблизно 17 ГБ. У гіршому випадку це займає близько 40 раундів виклику та відповіді, близько півроку, а загальний скрипт становить близько 150 Кб. У цій ситуації відчувається серйозна нестача стимулів, але на практиці цього майже ніколи не буває.
Розгляньте можливість використання доказів із нульовим знанням, щоб зменшити кількість викликів BitVM, тим самим підвищивши ефективність BitVM. Відповідно до теорії доказу з нульовим знанням, якщо дані Data задовольняють алгоритму F, доведено, що доказ задовольняє алгоритм перевірки Verify, тобто алгоритм перевірки видає True; якщо дані Data не задовольняють алгоритм F, доведено, що доказ не задовольняє алгоритм перевірки Verify, тобто алгоритм перевірки видає False. У системі BitVM, якщо претендент не розпізнає дані, надані прувером, ініціюється виклик.
Для алгоритму F використовуйте метод дихотомії, щоб його розділити. Припустімо, що знадобиться 2^n разів, щоб знайти точку помилки; якщо складність алгоритму надто велика, n буде великим, і це займе багато часу. Однак складність алгоритму перевірки Verify для доказу з нульовим знанням виправлена. Весь процес перевірки та перевірки алгоритму Verify є загальнодоступним, а вихідні дані виявляються False. Перевага доказу з нульовим знанням полягає в тому, що обчислювальна складність, необхідна для відкриття алгоритму перевірки Verify, набагато нижча, ніж у бінарного методу для відкриття оригінального алгоритму F. Таким чином, за допомогою підтвердження з нульовим знанням BitVM більше не оскаржує оригінальний алгоритм F, а перевіряє алгоритм Verify, зменшуючи кількість раундів перевірки та скорочуючи цикл перевірки.
Нарешті, хоча ефективність захисту від нульових знань і захисту від шахрайства залежить від різних припущень щодо безпеки, їх можна об’єднати, щоб створити ZK Fraud Proof і реалізувати ZK Proof на вимогу. На відміну від повного ZK Rollup, якому більше не потрібно генерувати ZK-доказ для кожного окремого переходу стану, модель On-Demand робить ZK-доказ потрібним лише за наявності проблем, тоді як уся зведена конструкція залишається оптимістичною. Таким чином, отриманий стан все ще дійсний за замовчуванням, доки хтось його не оскаржить. Якщо в певному стані немає виклику, немає потреби генерувати доказ ZK. Однак, якщо учасник ініціює виклик, для коректності всіх транзакцій у блоці виклику необхідно створити ZK Proof. У майбутньому ми можемо вивчити можливість створення ZK Fraud Proof для однієї суперечливої інструкції, щоб уникнути обчислювальних витрат на генерацію ZK Proof постійно.
3.2 Одноразовий підпис, зручний для біткойнів
У мережі Bitcoin транзакції, які відповідають правилам консенсусу, є дійсними транзакціями, але крім правил консенсусу також вводяться правила стандартності. Біткойн-вузли передають лише трансляцію стандартних транзакцій, єдиний спосіб пакетувати дійсні, але нестандартні транзакції – це безпосередньо працювати з майнерами.
Згідно з правилами консенсусу, максимальний розмір успадкованих (не Segwit) транзакцій становить 1 МБ, який займає весь блок. Але ліміт стандартності для успадкованих транзакцій становить 100 Кб. Згідно з правилами консенсусу, максимальний розмір транзакції Segwit становить 4 МБ, що є обмеженням ваги. Однак обмеження стандартності транзакцій Segwit становить 400 КБ.
Підпис Lamport є основним компонентом BitVM. Він зменшує довжину підпису та відкритого ключа, що допомагає зменшити дані транзакцій і, таким чином, зменшити комісію за обробку. Одноразовий підпис Лампорта вимагає використання хеш-функції (наприклад, функції односторонньої перестановки f). У схемі одноразового підпису Лампорта довжина повідомлення становить v біт, довжина відкритого ключа — 2 v біт, а довжина підпису також 2 v біт. Підпис і відкритий ключ довгі і потребують великої кількості газу для зберігання. Тому існує потреба знайти схеми підпису з подібними функціями, щоб зменшити довжину підпису та відкритого ключа. У порівнянні з одноразовим підписом Lamport, одноразовий підпис Winternitz значно зменшив довжину підпису та відкритого ключа, але збільшив обчислювальну складність підпису та перевірки підпису.
У схемі одноразового підпису Winternitz спеціальна функція P використовується для відображення v-бітового повідомлення у вектор s довжини n. Значення кожного елемента в s дорівнює {0,..., d}. Схема одноразового підпису Лампорта є схемою одноразового підпису Вінтерніца в окремому випадку d=1. У схемі одноразового підпису Вінтерніца співвідношення між n, d, v задовольняє: n≈v/log 2(d+ 1). Коли d= 15, є n≈(v/4)+ 1. Для підпису Вінтерніца, що містить n елементів, довжина відкритого ключа та довжина підпису в 4 рази коротші, ніж у схемі одноразового підпису Лампорта. Однак складність перевірки підпису зростає в 4 рази. Використання d= 15, v= 160, f=ripemd 160(x) у BitVM для впровадження одноразового підпису Winternitz може зменшити розмір бітового зобов’язання на 50%, таким чином зменшивши комісію за транзакції BitVM принаймні на 50%. У майбутньому під час оптимізації існуючої реалізації сценарію біткойн Winternitz можна досліджувати більш компактні схеми одноразового підпису, виражені в сценарії біткойн.
3.3 Хеш-функції, зручні для біткойнів
Згідно з правилами консенсусу, максимальний розмір P 2 TR становить 10 КБ, а максимальний розмір P 2 TR-свідка такий самий, як максимальний розмір транзакції Segwit, який становить 4 МБ. Однак верхня межа стандартності свідка P 2 TR становить 400 кБ.
Наразі мережа біткойн не підтримує OP_CAT, і рядки не можуть бути з’єднані для перевірки шляху Merkle. Таким чином, необхідно використовувати існуючі сценарії Bitcoin для реалізації хеш-функції, зручної для Bitcoin, з оптимальним розміром і розміром свідка для підтримки функції перевірки підтвердження включення Merkle.
BLAKE 3 є оптимізованою версією хеш-функції BLAKE 2 і представляє режим дерева Bao. У порівнянні з BLAKE 2 на базі s, кількість раундів його функції стиснення зменшено з 10 до 7. Хеш-функція BLAKE 3 розбиває вхідні дані на послідовні фрагменти розміром 1024 байти, останній фрагмент може бути коротшим, але не порожнім. Якщо є лише один фрагмент, цей фрагмент є кореневим вузлом і єдиним вузлом дерева. Розташуйте ці фрагменти як листкові вузли бінарного дерева, а потім стискайте кожен фрагмент незалежно.
Коли BitVM використовується для перевірки сценарію перевірки включення Merkle, вхідні дані хеш-операції складаються з двох 256-бітових хеш-значень, тобто вхідні дані хеш-операції становлять 64 байти. Під час використання хеш-функції BLAKE 3 ці 64 байти можна розподілити в одному фрагменті, і вся хеш-операція BLAKE 3 потребує лише одного разу застосувати функцію стиснення до окремого фрагменту. У функції стиснення BLAKE 3 необхідно запустити функцію округлення 7 разів і функцію перестановки 6 разів.
Наразі базові операції, такі як XOR, модульне додавання та зсув біта вправо на основі значень u 32, завершено в BitVM, і хеш-функцію BLAKE 3, реалізовану сценарієм Bitcoin, можна легко зібрати. Використовуйте 4 окремі байти в стеку, щоб представити u 32 слова для реалізації u 32 додавання, u 32 порозрядного XOR і u 32 побітового повороту, необхідних для BLAKE 3. Поточний сценарій хеш-функції BLAKE 3 Bitcoin має загальний розмір близько 100 КБ, цього достатньо для створення іграшкової версії BitVM.
Крім того, ці коди BLAKE 3 можна розділити, дозволяючи Verifier і Prover значно скоротити необхідні дані в ланцюжку, розділивши виконання гри виклик-відповідь навпіл замість того, щоб виконувати її повністю. Нарешті, скористайтеся сценарієм Bitcoin для реалізації хеш-функцій, таких як Keccak-256 і Grøstl, виберіть найбільш зручну для Bitcoin хеш-функцію та досліджуйте інші нові хеш-функції для Bitcoin.
3.4 менше s BitVM
less s — це метод виконання смарт-контрактів поза мережею за допомогою підписів Шнорра. Концепція Scripless s народилася з Mimblewimble, яка не зберігає постійних даних, крім ядра та його підпису.
Перевагами less s є функціональність, конфіденційність та ефективність.
less s — це підхід до розробки криптографічних протоколів для біткойнів, який уникає виконання явних смарт-контрактів. Основна ідея полягає в тому, щоб використовувати криптографічні алгоритми для досягнення бажаної функціональності, а не використовувати сценарії для досягнення функціональності. Підписи адаптерів і мультипідписи є оригінальними будівельними блоками менших s. Використовуючи менше s, ви можете досягти менших транзакцій, ніж звичайні транзакції, і зменшити комісію за транзакції.
За допомогою менше s можна використовувати мультипідпис Schnorr і підпис адаптера, який більше не забезпечує хеш-значення та хеш-прообрази, як рішення BitVM, а також може реалізувати зобов’язання логічного вентиля в схемі BitVM, тим самим зберігаючи BitVM простір сценарію та підвищення ефективності BitVM. Хоча існуюча схема less s може зменшити простір сценарію BitVM, для об’єднання відкритого ключа потрібна велика кількість взаємодії між перевіряючим і претендентом. У майбутньому ми вдосконалимо це рішення та спробуємо впровадити Scripless у окремі функціональні модулі BitVM.
3.5 Багатоучасникний виклик без дозволу
Причина, чому поточні виклики BitVM вимагають дозволу за замовчуванням, полягає в тому, що UTXO Bitcoin може бути виконано лише один раз, що дозволяє зловмисному верифікатору «марнувати» контракт, кидаючи виклик чесному перевіряльнику. Зараз BitVM обмежено двостороннім режимом виклику. Достовірник, який намагається вчинити зло, може одночасно запустити виклик із верифікатором, яким він керує, таким чином «марнуючи» контракт, роблячи зловмисну дію успішною, а інші верифікатори не можуть запобігти цій поведінці. Тому, базуючись на біткойнах, необхідно вивчити багатосторонній протокол виклику OP без дозволу, який може розширити існуючу модель довіри BitVM 1-of-n до 1-of-N. Серед них N набагато більше n. Крім того, існує потреба вивчити та вирішити проблему претендентів, які вступають у змову з перевіряючими або злісно оскаржують «змарні» контракти. Зрештою, впровадження протоколу BitVM з меншою довірою.
Завдання для кількох учасників без дозволу, що дозволяє будь-кому брати участь без списку дозволів. Це означає, що користувачі можуть виводити монети з L2 без залучення довіреної третьої сторони. Крім того, будь-який користувач, який хоче брати участь у протоколі виклику OP, може оскаржити та видалити недійсні зняття.
Розширення BitVM до моделі багатостороннього виклику без дозволу вимагає вирішення таких атак:
У майбутньому ми досліджуватимемо модель багатостороннього виклику BitVM без дозволу, яка підходить для характеристик біткойнів і може протистояти вищезазначеним проблемам атаки.
4 Висновок
Вивчення технології BitVM тільки почалося. У майбутньому буде досліджено та впроваджено більше напрямків оптимізації, щоб досягти розширення Bitcoin та процвітання екосистеми Bitcoin.
посилання
Оригінальне посилання