1. Вступ

Bitcoin є децентралізованим, безпечним та надійним цифровим активом. Однак він має серйозні обмеження, які перешкоджають йому стати масштабованою мережею для платежів та інших застосувань. Проблема масштабування Bitcoin була проблемою від його створення. Модель UTXO (Unspent Transaction Output) Bitcoin розглядає кожну транзакцію як незалежну подію, що призводить до безстандартної системи, яка не має можливості виконувати складні, станово залежні обчислення. В результаті, хоча Bitcoin може виконувати прості скрипти та транзакції з багатьма підписами, він має проблеми з полегшенням складних та динамічних контрактних взаємодій, що є типовими для платформ стану блокчейну. Це обмеження значно обмежує спектр децентралізованих додатків (dApps) та складних фінансових інструментів, які можна побудувати на Bitcoin, тоді як моделі платформи стану пропонують більш різноманітне середовище для розгортання та виконання функціонально насичених смарт-контрактів.

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

У грудні 2023 року Робін Лінус, керівник проекту ZeroSync, опублікував білу книгу під назвою “БітVM: Обчисліть що завгодно на біткоїні», що викликало значні роздуми про підвищення програмованості біткойна. У документі пропонується рішення для повного контракту Тюрінга, яке може виконувати будь-які складні обчислення на біткойнах, не змінюючи правил консенсусу мережі та не змінюючи фундаментальних принципів біткойна. BitVM використовує скрипти Bitcoin і Taproot для реалізації оптимістичних зведень. Він використовує сигнатури Lamport (також відомі як бітові зобов'язання) для встановлення з'єднань між двома Bitcoin UTXO, що дозволяє використовувати сценарії Bitcoin зі збереженням стану. Велика програма розміщується в адресі Taproot, а оператори та валідатори беруть участь у широких офчейн-взаємодіях, залишаючи мінімальний слід у блокчейні. Якщо обидві сторони співпрацюють, будь-які складні офчейн-обчислення зі збереженням стану можуть бути виконані, не залишаючи жодних слідів у блокчейні. Однак, якщо сторони не співпрацюють, у разі виникнення спору потрібне ончейн-виконання. Таким чином, BitVM значно розширює потенційні варіанти використання біткойна, дозволяючи йому служити не тільки як валюта, але і як платформа верифікації для різних децентралізованих додатків і складних обчислювальних завдань.

Однак, незважаючи на переваги технології BitVM у масштабуванні Bitcoin, вона все ще знаходиться на ранніх стадіях і стикається з деякими проблемами ефективності та безпеки, такими як: (1) Виклики та відповіді вимагають багаторазової взаємодії, що призводить до високих комісій за транзакції та тривалих періодів викликів; (2) одноразові підписи Лемпорта мають велику довжину даних, що вимагає зменшення розміру даних; (3) Висока складність хеш-функції вимагає дружніх до біткойнів хеш-функцій для зниження витрат; (4) Існуючі контракти BitVM великі, а ємність блоків Bitcoin обмежена, тому використання безскриптових скриптів може допомогти досягти BitVM без скриптів, заощаджуючи простір у блоці Bitcoin та підвищуючи ефективність BitVM; (5) Поточна BitVM працює за моделлю дозволів, з проблемами, ініційованими лише членами консорціуму, і обмеженими двома сторонами, яка повинна бути розширена до інклюзивної моделі багатостороннього оскарження, щоб ще більше зменшити припущення про довіру. Щоб вирішити ці проблеми, у статті запропоновано кілька ідей оптимізації для підвищення ефективності та безпеки BitVM.

2. БітVM Принцип

BitVM позиціонується як система контрактів поза ланцюжком для Bitcoin, спрямована на покращення функціоналу контрактів для Bitcoin. На даний момент скрипти Bitcoin цілком безстатеві, що означає, що середовище виконання скидається після кожного скрипта. В Bitcoin scripting немає природного способу забезпечити, що скрипти 1 і 2 мають однакове значення x. Однак можна зробити Bitcoin скрипти зі станом використовуючи наявні опкоди та одноразові підписи Лампорта, забезпечуючи, що x в скрипті 1 і скрипті 2 однакові. Якщо учасники підписують конфліктні значення x, їх можуть покарати.

Обчислення BitVM відбуваються поза ланцюжком, тоді як підтвердження цих обчислень відбувається на ланцюжку. З урахуванням обмеження 1МБ на блоки Bitcoin, коли потрібно підтвердження складних обчислень, технологію OP можна використовувати в режимі виклик-відповідь для підтримки підтвердження обчислень більшої складності.

Подібно до оптимістичного Rollup та пропозиції MATT (Merkelize All The Things), система BitVM ґрунтується на доказах шахрайства та протоколах виклику-відповіді, але не потребує змін у консенсусних правилах Bitcoin. Основні примітиви BitVM прості, переважно ґрунтуються на хеш-замках, часових замках та великих деревах Taproot.

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

Ключові компоненти BitVM включають:

• Зобов'язання ланцюга: Доказувачі та перевіряючі компілюють програму в великий двійковий ланцюг. Доказувач зобов'язується з цим ланцюгом в адресі Taproot, при цьому кожний листковий скрипт під цією адресою відповідає кожній логічній вороті в ланцюзі. Основна мета - досягнути зобов'язання логічних воріт на основі зобов'язання бітів.
• Виклик та відповідь: Доведучі та перевіряючі попередньо підписують серію транзакцій для виконання гри "виклик-відповідь". Ідеально, ця взаємодія відбувається поза ланцюжком, але її також можна виконати на ланцюжку, якщо доведучий не співпрацює.
• Неоднозначне покарання: Якщо доказуючий вносить будь-які невірні твердження, перевіряючий може забрати депозит доказуючого після успішного виклику та перешкодження злочинним діям доказуючого.

3. БітVM Оптимізації

3.1 Зменшити кількість операцій взаємодії OP на основі ZK

Існує два основних типи Rollups: ZK Rollups та Оптимістичні Rollups (OP Rollups). ZK Rollups базуються на перевірці достовірності доказів з нульовим доказом (ZK), які є криптографічними доказами правильного виконання. Їхній захист залежить від припущень про обчислювальну складність. Оптимістичні Rollups базуються на доказах шахрайства, припускаючи, що всі подані стани є правильними і зазвичай встановлюють викликовий період близько семи днів. Їхня безпека передбачає, що принаймні одна чесна сторона в системі може виявити неправильний стан і подати доказ шахрайства.

Припускаючи, що максимальна кількість кроків для програми виклику BitVM становить 2^{32}, для неї знадобиться приблизно 17 ГБ пам'яті (2^{32}×4 байти). У найгіршому випадку приблизно 40 раундів викликів та відповідей можуть зайняти близько шести місяців, з загальним розміром сценарію приблизно 150 КБ. Такий сценарій надасть недостатні стимули, але в практиці це мало трапляється.

Використання доказів нульового знання для зменшення кількості викликів у BitVM може підвищити його ефективність. Згідно з теорією доказів нульового знання, якщо дані задовольняють алгоритм F, то доказ задовольняє алгоритм перевірки Verify, виводячи значення True. Навпаки, якщо дані не задовольняють F, то доказ не буде задовольняти перевірку Verify, виводячи значення False. У системі BitVM, якщо викликач не приймає дані доказувальника, ініціюється виклик.

Для алгоритму F, використовуючи підхід бінарного пошуку, припускаючи, що потрібно 2^n ітерацій для знаходження точки помилки. Якщо складність алгоритму занадто велика, n велике, і на завершення витрачається довгий час. Однак складність алгоритму перевірки доказу в нульовому знанні Verify фіксована. Публічно розкриваючи доказ та процес верифікації Verify, можна побачити вихід False. Перевага доказів в нульовому знанні полягає в меншій обчислювальній складності, необхідній для відкриття алгоритму верифікації Verify порівняно з відкриттям початкового алгоритму F за допомогою бінарного пошуку. Таким чином, за допомогою доказів в нульовому знанні BitVM більше не викликає початковий алгоритм F, але верифікаційний алгоритм Verify, зменшуючи кількість раундів виклику та скорочуючи період виклику.

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

3.2 Біткоін-дружні підписи одноразового використання

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

Згідно з правилами консенсусу, максимальний розмір для спадкових (не-Segwit) транзакцій становить 1MB, що може заповнити весь блок. Однак обмеження стандартності для спадкових транзакцій встановлено на рівні 100kB. Для Segwit транзакцій максимальний розмір, дозволений правилами консенсусу, становить 4MB, відомий як обмеження ваги, але їх обмеження стандартності складає 400kB.

Підписи Lamport є основним компонентом BitVM, і зменшення довжини підписів і публічних ключів допомагає зменшити розмір даних транзакцій, тим самим знижуючи комісію за транзакції. Одноразові сигнатури Lamport вимагають хеш-функції (наприклад, одностороння функція перестановки f). У схемі одноразового підпису Lamport довжина повідомлення становить v біт, а відкритий ключ і довжина сигнатури — 2v біт. Ці довгі підписи та публічні ключі споживають значну кількість газу для зберігання. Тому необхідно вивчити схеми підпису, які можуть зменшити довжину підписів і відкритих ключів. У порівнянні з одноразовими підписами Лемпорта, одноразові підписи Вінтерніца значно зменшують довжину підписів і відкритих ключів, але вони збільшують обчислювальну складність підписання та перевірки.

У схемі підпису одноразового використання Вінтернітца спеціальна функція P відображає повідомлення довжиною v-біт у вектор s довжиною n, при цьому кожен елемент s приймає значення в {0,…,d}. Схема підпису одноразового використання Лампорта є особливим випадком схеми Вінтернітца, де d=1. У схемі Вінтернітца відношення між n, d та v становить приблизно n≈v/log2(d+1). Коли d=15, n≈(v/4)+1. Для підпису Вінтернітца з n елементами довжина відкритого ключа та підпису в чотири рази коротша, ніж у схемі підпису одноразового використання Лампорта, але складність перевірки в чотири рази вища. Використання d=15,v=160,f=ripemd160(x) в BitVM для підписів одноразового використання Вінтернітца може зменшити розмір бітового зобов'язання на 50%, тим самим зменшивши вартість транзакцій BitVM принаймні на 50%. У майбутньому, оптимізуючи існуючу реалізацію скрипту Bitcoin Вінтернітца, можна досліджувати більш компактні схеми підпису одноразового використання, які можна виразити в скрипті Bitcoin.

3.3 Біткоїн-дружні функції хешування

Згідно з правилами консенсусу, максимальний розмір для сценарію P2TR становить 10 кБ, а максимальний розмір для свідка сценарію P2TR такий самий, як максимальний розмір транзакції Segwit, який становить 4 МБ. Однак обмеження стандартності для свідка сценарію P2TR становить 400 кБ.

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

BLAKE3 - це оптимізована версія хеш-функції BLAKE2 та вводить режим дерева Bao. Порівняно з BLAKE2s-based, кількість раундів у функції стиснення BLAKE3 зменшилася з 10 до 7. Хеш-функція BLAKE3 розбиває вхідні дані на шматки по 1024 байти, при цьому останній шматок може бути коротшим, але не порожнім. Якщо є лише один шматок, він служить кореневим вузлом та єдиним вузлом дерева. Ці шматки розташовані як листкові вузли бінарного дерева, та кожен шматок стискається незалежно.

Коли BitVM використовується для перевірки доказів включення Меркла, вхід для хеш-операції складається з двох конкатенованих значень хешу по 256 біт, загалом 64 байтів. З функцією хешування BLAKE3 ці 64 байти можуть поміститися в одному фрагменті, що означає, що операції хешування BLAKE3 потрібно застосувати тільки один раз до цього одного фрагменту. Для функції стиснення BLAKE3 потрібно сім раундових функцій і шість функцій перестановки.

BitVM вже реалізував базові операції, такі як XOR, модулярне додавання та зсув праворуч на основі значень u32, що дозволяє легко зібрати хеш-функцію BLAKE3 за допомогою скрипту Bitcoin. Стек використовує чотири окремих байти для представлення слів u32, що сприяє додаванню u32, побітовому XOR для u32 та побітовим обертанням, необхідним для BLAKE3. Хеш-функція BLAKE3 у скрипті Bitcoin наразі становить приблизно 100 кБ, що достатньо для створення іграшкової версії BitVM.

Крім того, розділяючи ці коди BLAKE3, Верифікатор та Довідник можуть значно знизити вимоги до даних на ланцюжку, розділяючи виконання на виклик-відповідь гру замість повного виконання. Нарешті, впровадження хеш-функцій, таких як Keccak-256 та Grøstl у скрипт Bitcoin, ідентифікує найбільш дружню до Bitcoin хеш-функцію та досліджує інші нові дружні до Bitcoin хеш-функції.

3.4 Scriptless Scripts БітVM

Scriptless Scripts - це метод виконання розумних контрактів поза ланцюжком за допомогою підписів Шнорра. Концепція безскриптових скриптів виникла з Mimblewimble, де, окрім ядра та його підпису, не зберігається жодні постійні дані.

Переваги безскриптових скриптів включають функціональність, конфіденційність та ефективність:

• Функціональність: Безскриптові Скрипти можуть розширити обсяг та складність смарт-контрактів. Можливості Bitcoin скрипту обмежені кількістю активованих OP_CODES в мережі. Натомість, Безскриптові Скрипти переносять специфікацію та виконання смарт-контрактів офлайн для обговорень лише між сторонами контракту, без очікування на вилучення нових опкодів в мережі Bitcoin.
• Приватність: Перенесення специфікації та виконання смарт-контрактів з on-chain на off-chain підвищує конфіденційність. На on-chain багато деталей контракту діляться з усією мережею, включаючи кількість учасників, адреси та суму, яка передається. Переміщення смарт-контрактів з off-chain означає, що мережа знає лише те, що учасники погодилися, що умови контракту виконані, і пов'язані транзакції є дійсними.
• Ефективність: Scriptless Scripts мінімізують кількість даних, які потрібно перевірити та зберегти on-chain. Переміщуючи смарт-контракти off-chain, адміністративні витрати для повноцінних вузлів зменшуються, а також знижуються транзакційні витрати для користувачів.

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

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

3.5 Бездозвільні Багатосторонні Виклики

Поточне завдання BitVM вимагає дозволу, оскільки Bitcoin UTXO може бути виконаний лише один раз, що призводить до ситуації, коли зловмисний верифікатор може «витратити» контракт, кинувши виклик чесному доказу. В даний час BitVM обмежена двосторонньою моделлю виклику. Зловмисник може використовувати верифікатор під своїм контролем, щоб ініціювати оскарження та «змарнувати» контракт, таким чином гарантуючи, що його зловмисна дія буде успішною, тоді як інші верифікатори не можуть запобігти такій поведінці. Тому, крім Bitcoin, необхідно досліджувати інклюзивний багатосторонній протокол виклику OP, який міг би розширити існуючу модель довіри BitVM 1 з n до 1 з N, де N набагато більше, ніж n. Крім того, важливо вирішити проблеми змови між претендентами та доказами або зловмисних викликів, які «витрачають» контракти для досягнення більш мінімізованого до довіри протоколу BitVM.

Дозвіл на багатосторонній виклик без списку дозволених дозволяє будь-кому брати участь без білого списку, що означає, що користувачі можуть виводити кошти з L2 без участі будь-якого надійного третього суб'єкта. Крім того, будь-який користувач, який хоче взяти участь в протоколі виклику OP, може ставити під сумнів та видаляти недійсні виводи коштів.

Розширення BitVM до моделі виклику багатопосередницької бездозвільної участі передбачає вирішення наступних атак:

• Атаки Сибіли: Навіть якщо зловмисник створює кілька ідентичностей для участі в оскарженні суперечки, один чесний учасник все одно повинен мати можливість виграти суперечку. Якщо витрати чесного учасника на захист правильного результату лінійно зростають зі збільшенням кількості нападників, то ціна для чесного учасника за перемогу в суперечці стає непрактичною і вразливою для атак Сибіл при залученні великої кількості нападників. Стаття "Турніри без дозволу арбітра” пропонує алгоритм вирішення суперечок, що змінює правила гри, де витрати для одного чесного учасника на перемогу в суперечці зростають логарифмічно, а не лінійно, з кількістю опонентів.
• Атаки із затримкою: Окрема особа або група зловмисників дотримуються стратегії, щоб запобігти або затримати підтвердження правильного результату (наприклад, виведення активів на L1) на L1, змушуючи чесного виконавця витрачати комісію за транзакцію L1. Щоб пом'якшити цю проблему, претенденти можуть бути зобов'язані зробити попередню ставку. Якщо претендент здійснить атаку із затримкою, його ставка буде втрачена. Однак, якщо зловмисники готові певною мірою пожертвувати своєю часткою заради атак із затримкою, повинні існувати стратегії зменшення впливу цих атак. Алгоритм, запропонований у статті «BoLD: Bounded Liquidity Delay in a Rollup Challenge Protocol” гарантує, що гірший варіант затримки, спричинений атакувальником, буде обмежений, незалежно від того, наскільки багато стейку атакувальник готовий втратити.

У майбутньому буде дослідження моделі виклику багатосторонньої дозволеної BitVM, яка стійка до цих атак і відповідна характеристикам біткоїна.

4. Висновок

Дослідження технології БітVM тільки починається, і у майбутньому буде досліджено більше оптимізацій, які дозволять досягти масштабування для Bitcoin та збагатити екосистему Bitcoin.

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

1. Ця стаття переписана з [@Bitlayer/bitvm-and-its-optimization-considerations-007da599d8ac">Bitlayer], Всі авторські права належать оригінальному автору [Ліннделл та Мутуренд]. Якщо є зауваження до цього повторного друку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.