1 Вступ

Для алгоритму f два недовірливі учасники, Еліс і Боб, можуть встановити довіру наступними способами:

1. Еліс вводить x, запускає алгоритм f і отримує результат y. Боб також запускає алгоритм f з тим самим введенням x, що призводить до y′. Якщо y = y′, то Боб підтверджує введення x і вивід y, зроблені Еліс. Це особливий механізм доказу дійсності, який часто використовується в консенсусі блокчейну, де Еліс - це вузол, який упаковує блок, а Боб - це вузол, який бере участь у консенсусі.
2. Аліса вводить x, запускає програму zk.prove на алгоритмі f, і отримує результат y та доказ proof. Боб запускає програму zk.verify на основі f, y та доказу. Якщо результат є true, то Боб підтверджує результат Аліси y; якщо результат є false, то Боб не підтверджує результат Аліси y. Це доказ дійсності, де Боб може бути контрактом на ланцюжку.
3. Еліс вводить x, запускає алгоритм f і отримує результат y. Боб також запускає алгоритм f з тим самим введенням x, що призводить до y′. Якщо y = y′, тоді нічого не робиться; якщо y ≠ y′, тоді Боб викликає Еліс, причому викликана програма - f. Кількість взаємодій між Еліс та Бобом може бути однією або кількома. Арбітраж досягається через процес виклику-відповідь. Це доказ шахрайства, де Боб - викликач, слухає поза ланцюжком та викликає на ланцюжку.
4. Аліса вводить x, запускає програму zk.prove на алгоритмі f та отримує результат y та доказ proof. Боб запускає програму zk.verify на основі f, y та proof. Якщо результат є правдивим, нічого не робиться; якщо результат є хибним, то Боб ставить Алісі виклик за допомогою програми zk.verify. Кількість взаємодій між Алісою та Бобом може бути однією або кількома. Арбітраж досягається за допомогою процесу виклику-відповіді. Це доказ шахрайства, де Боб є викликачем, прослуховуючи оффлайн та ставлячи виклик на-ланцюгово.

Для вищезазначених 2, 3 та 4, нехай x - це транзакції рівня 2 та початковий стан, f - програма консенсусу рівня 2, а y - кінцевий стан транзакції, що відповідає рішенню масштабування рівня 2 блокчейну. Серед них:

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

Таблиця 1: Способи встановлення довіри

Додатково важливо зауважити:

• Ключем до відмежування доказів шахрайства та доказів дійсності є не те, чи використовуються системи доказу ZK, такі як SNARK/STARK. Система доказу ZK виражає метод доказу, тоді як шахрайство або дійсність представляє зміст, який підтверджується. Тому сценарій 1 в Таблиці 1 вважається доказом дійсності.
• Докази дійсності мають кращу своєчасність, але складність перевірки на ланцюжку є відносно високою; докази шахрайства мають меншу складність перевірки на ланцюжку, але їхня своєчасність є відносно поганою.
• Для випадків 2 і 4 в Таблиці 1, використовуючи рекурсію та комбінаційні техніки ZK, можна обчислити та стиснути кілька f, що значно зменшує вартість перевірки поза ланцюжком обчислень на ланцюжку.

Наразі, користуючись перевагами смарт-контрактів Solidity, повних за Тюрінгом, технології доказів шахрайства та доказу валідності широко використовуються в масштабуванні Ethereum Layer2. Однак, згідно з парадигмою Bitcoin, обмеженою функціональністю коду операції Bitcoin, 1000 елементами стека та іншими обмеженнями, застосування цих технологій все ще знаходиться на стадії дослідження. У цій статті узагальнено обмеження та проривні технології в рамках парадигми Bitcoin в контексті масштабування Bitcoin Layer2, досліджено технології доказу валідності та доказу шахрайства, а також окреслено унікальну технологію сегментації скриптів відповідно до парадигми Bitcoin.

2 Обмеження та Прориви в рамках парадигми Біткойн

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

2.1 Модель UTXO та обмеження сценарію

Біткойн використовує модель UTXO, де кожен UTXO заблокований в замкненому скрипті, який визначає умови, що повинні бути виконані для витрати цього UTXO. Скрипти Біткойн мають наступні обмеження:

1. Скрипти Біткойн не мають стану;
2. Для типів виходів P2TR максимальна кількість опкодів, яку можна розмістити в одній транзакції, становить близько 4 мільйонів, заповнюючи весь блок, тоді як для інших типів виходів є лише 10 000 опкодів;
3. Методи витрат одного UTXO обмежені, відсутність дослідження комбінованих методів витрат;
4. Гнучкі функції контракту не підтримуються;
5. Розмір стека обмежений максимум 1000 елементами (altstack + stack), а максимальний розмір одного елемента становить 520 байт;
6. Арифметичні операції (такі як додавання і віднімання) обмежені 4-байтовими елементами. Їх не можна модифікувати на довгі елементи, такі як 20 байтів або більше, які необхідні для криптографічних операцій;
7. Опкоди, такі як OPMUL і OPCAT, були вимкнені, і їх симуляція за допомогою існуючих опкодів зумовлює надзвичайно великі витрати, наприклад, симуляція хеша BLAKE3 з одним раундом, з розміром скрипта приблизно 75K.

2.2 Біт Зобов'язання: Пробиваючи обмеження без стану UTXO

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

Принцип бітового зобов'язання є відносно простим. Біт відноситься до встановлення двох різних хеш-значень, hash0 і hash1, для кожного біта в повідомленні, що підлягає підпису. Якщо значення біта, яке підлягає підпису, дорівнює 0, відкривається преображення0 хеш0; якщо значення біта, яке підлягає підпису, дорівнює 1, відкривається преображення1 хеш1.

Беручи однобітове повідомлення m ∈{0,1} як приклад, відповідний скрипт розблокування зобов'язання біту - це лише деякі передображення: якщо значення біту - 0, відповідний скрипт розблокування - це передображення0 - '0xfa7fa5b1dea37d71a0b841967f6a3b119dbea140'; якщо значення біту - 1, відповідний скрипт розблокування - це передображення1 - '0x47c31e611a3bd2f3a7a42207613046703fa27496'. Отже, завдяки зобов'язанню біту, можливо прорватися через обмеження безстанційного UTXO та досягти скриптів Bitcoin зі станом, що розвиваються, що робить можливими різноманітні цікаві нові функції.

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Це hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Це hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Тепер значення зобов'язання до біта знаходиться в стеку. Або «0», або «1».

Наразі існує 2 реалізації зобов'язання біта:

• Лампорт одноразовий підпис: Принцип досить простий і вимагає використання лише хеш-функцій, що робить його придатним для Bitcoin. Для кожного біту в повідомленні потрібно зафіксувати два значення хеша, що призводить до досить великих даних підпису. Іншими словами, для повідомлення довжиною в v бітів, довжина відкритого ключа становить 2v бітів, а довжина підпису - v бітів.
• Одноразовий підпис Winternitz: У порівнянні з підписами Lamport, він значно зменшує довжину підписів і відкритих ключів, але збільшує складність підпису та перевірки. Ця схема дозволяє гнучко встановлювати різні довжини хеш-ланцюжка d, таким чином балансуючи довжину та складність. Наприклад, встановлення d = 15 призводить до того, що і довжина відкритого ключа, і довжина підпису будуть приблизно в 4 рази коротшими, але складність перевірки збільшиться в 4 рази. По суті, це компроміс між простором стека Bitcoin і розміром сценарію. Сигнатури Лемпорта можна розглядати як окремий випадок підписів Вінтерніца, коли d = 1.

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

2.3 Taproot: Пробиваючи обмеження простору скриптів

Оновлення м'якого віліціння Bitcoin Taproot, активоване в листопаді 2021 року, включає три пропозиції: підписи Schnorr (BIP 340), Taproot (BIP 341) та TapScript (BIP 342). Воно вводить новий тип транзакцій — транзакції Pay-to-Taproot (P2TR). Транзакції P2TR можуть створювати більш приватний, гнучкий та масштабований формат транзакцій, поєднуючи переваги Taproot, MAST (Merkel Abstract Syntax Tree) та підписи Schnorr.

P2TR підтримує два методи витрат: витрати відповідно до ключового шляху або шляху скрипта.

Згідно з нормами Taproot (BIP 341), при витрачанні через шлях скрипта, відповідний Merkle-шлях не може перевищувати максимальної довжини 128. Це означає, що кількість tapleafs в taptree не може перевищувати 2^128. З моменту оновлення SegWit у 2017 році мережа Bitcoin вимірює розмір блоку в одиницях ваги з максимальною підтримкою 4 мільйони одиниць ваги (приблизно 4 МБ). Коли вивод P2TR витрачається через шлях скрипта, потрібно розкрити лише один скрипт tapleaf, що означає, що блок запакований з одним скриптом tapleaf. Це означає, що для транзакцій P2TR розмір скрипту, що відповідає кожному tapleaf, може бути максимум близько 4 МБ. Однак за політикою за замовчуванням Bitcoin багато вузлів пересилають лише транзакції менше 400K; для великих транзакцій потрібна співпраця з майнерами, щоб їх запакувати.

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

При побудові перевірки обчислень на основі P2TR розмір відповідного скрипта більше не обмежується 4 МБ, але може бути розбитий на кілька підфункцій, розподілених по кількох tapleafs, тим самим прориваючи обмеження 4 МБ на простір скриптів. Фактично, алгоритм перевірки Groth16, реалізований у поточному BitVM2, має розмір до 2 ГБ. Однак його можна розбити та розподілити по близько 1000 tapleafs, а поєднуючи його з бітовим зобов'язанням, можна обмежити узгодженість між входами та виходами кожної підфункції, забезпечуючи цілісність та правильність всього обчислення.

2.4 Виведення конектора: Прорив обмежень методу витрат UTXO

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

Однак Бурак, засновник протоколу Ark, вміло використав прапор SIGHASH для досягнення виходу роз'єму. Зокрема, Аліса може створити підпис, щоб відправити свої BTC Бобу. Однак, оскільки підпис може вносити кілька вхідних даних, Аліса може встановити умовний підпис: підпис дійсний для транзакції Taketx тоді і тільки тоді, коли ця транзакція споживає друге введення. Другий вхід називається роз'ємом, що з'єднує UTXO A і UTXO B. Іншими словами, транзакція Taketx дійсна тоді і тільки тоді, коли UTXO B не був витрачений Challengetx. Тому, знищивши вихід конектора, ефективність транзакції Taketx може бути заблокована.

Рисунок 1: Ілюстрація виводу конектора

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

2.5 Контракти: Прорив обмежень передпідписання

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

Поточні реалізації контрактів можна розділити на дві категорії:

• Попереднє підписання: На основі існуючих можливостей сценарію Біткойн, попередньо визначені контракти з обмеженою функціональністю створюються шляхом попереднього підписання. Це означає розробку та підписання всіх можливих майбутніх транзакцій заздалегідь, блокування учасниками конкретних приватних ключів та ставок комісії. Деякі схеми навіть вимагають, щоб учасники генерували короткострокові приватні ключі для всіх попередньо підписаних транзакцій. Після завершення попереднього підписання ці короткострокові приватні ключі безпечно видаляються, запобігаючи їх отриманню зловмисниками та крадіжці коштів. Однак кожного разу, коли додається новий учасник або оновлюється операція, описаний вище процес потрібно повторювати, що призводить до високих витрат на обслуговування. Наприклад, Lightning Network досягає двосторонніх контрактів шляхом попереднього підписання та використовує технологію Hash Time-Locked Contracts (HTLC) для реалізації функцій маршрутизації для кількох двосторонніх контрактів, таким чином досягаючи стратегії масштабування з мінімізацією довіри. Однак Lightning Network вимагає попереднього підписання кількох транзакцій і обмежена двома сторонами, що робить її дещо громіздкою; в BitVM1 сотні транзакцій повинні бути попередньо підписані при кожній ініціалізації, в той час як в оптимізованому BitVM2 кількість транзакцій, які необхідно попередньо підписати при кожній ініціалізації, також досягає десятків. Як у BitVM1, так і в BitVM2 право на відшкодування мають лише оператори, які беруть участь у попередньому підписанні. Якщо в попередньому підписанні бере участь n учасників, і кожному учаснику необхідно попередньо підписати m транзакцій, то складність попереднього підписання для кожного учасника складе n * m.
• Введення кодів операцій контракту: Введення нових кодів операцій функції контракту може значно знизити складність зв'язку та витрати на обслуговування між учасниками контракту, таким чином вводячи більш гнучкий метод реалізації контракту для Bitcoin. Наприклад, OPCAT: використовується для об'єднання рядків байтів. Незважаючи на те, що його функція дуже проста, він дуже потужний і може значно зменшити складність BitVM; OPTXHASH: дозволяє краще контролювати дії в рамках контракту. При використанні в BitVM він може підтримувати більший набір операторів, тим самим значно покращуючи припущення про безпеку BitVM і мінімізуючи довіру. Крім того, метод попереднього підписання за своєю суттю означає, що оператори в BitVM можуть прийняти лише процес відшкодування, що призводить до зниження ефективності використання капіталу; У той час як за допомогою нових кодів контрактних операцій можна буде безпосередньо виплачувати кошти з прив'язаного фонду вихідним користувачам, що ще більше підвищує ефективність капіталу. Таким чином, гнучка модель контракту дозволить ефективно подолати традиційні обмеження перед підписанням.

3 Біткойн Рівень 2 Масштабування: Докази Дійсності та Докази Шахрайства

Як докази дійсності, так і докази шахрайства можуть використовуватися для масштабування Bitcoin L2, з основними відмінностями, показаними в Таблиці 2.

Таблиця 2: Докази дійсності проти доказів шахрайства

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

Залежно від кількості взаємодій відповідь-виклик між Алісою і Бобом, докази шахрайства можуть бути розбиті на однораундові докази шахрайства та багатораундові докази шахрайства, як показано на рис. 2.

Рис. 2: Однораундові докази шахрайства проти багатораундових доказів шахрайства

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

Таблиця 3: Взаємодія одного раунду проти взаємодії кількох раундів

У парадигмі масштабування Bitcoin Layer2, BitVM1 використовує багатораундовий механізм доказу шахрайства, тоді як BitVM2 використовує однораундовий механізм доказу шахрайства, а bitcoin-circle stark використовує докази дійсності. З цих, BitVM1 та BitVM2 можуть бути реалізовані без внесення будь-яких змін до протоколу Bitcoin, тоді як bitcoin-circle stark вимагає введення нової операції OP_CAT.

Для більшості обчислювальних завдань, signet, testnet та mainnet Біткойну не можуть повністю представляти 4MB скрипт, що вимагає використання технології розбиття скрипту - тобто розбиття повного обчислювального скрипту на частини менші за 4MB, розподілені по різних tapleafs.

3.1 Багатораундові докази шахрайства на Біткойн

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

У ранній білий папер Робіна Лінуса BitVM (зазвичай називається BitVM1) використовував багатораундові докази шахрайства. Припускаючи, що кожний період виклику триває тиждень і використовується метод бінарного пошуку для знаходження проблемних обчислювальних сегментів, період відповіді на виклик на ланцюжку для перевірника Groth16 може тривати до 30 тижнів, що призводить до поганої своєчасності. Незважаючи на те, що в даний час команди досліджують більш ефективні методи n-арного пошуку, ніж бінарний пошук, їхня своєчасність все ще значно нижча порівняно з 2-тижневим циклом в однораундових доказах шахрайства.

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

3.2 Однораундові докази шахрайства на Біткойні

У цій моделі перевірка доказів шахрайства може бути завершена за одну взаємодію між доводчиком та перевіряючим. Перевіряючому потрібно лише ініціювати одне виклик, а доводчику потрібно відповісти лише один раз. У цій відповіді доводчик повинен надати докази того, що їх обчислення є правильними. Якщо перевіряючий виявить неузгодженості в цих доказах, виклик вдалий; в іншому випадку він невдалий. Характеристики одноразових інтерактивних доказів шахрайства показані в Таблиці 3.

Рисунок 3: Доказ шахрайства в один раунд

15 серпня 2024 року Робін Лінус опублікував технічну білу книгу BitVM2: Містить Bitcoin до другого рівня, яка реалізувала міжланцюговий міст за допомогою одноразового методу доказу шахрайства, подібного до показаного на Рис. 3.

3.3 Докази дійсності на Bitcoin з OP_CAT

OPCAT був частиною початкової мови сценаріїв, коли вийшов Bitcoin, але був вимкнений у 2010 році через вразливості безпеки. Однак спільнота Bitcoin обговорює його повторне ввімкнення вже кілька років. OPCAT тепер був призначений номером 347 і був увімкнений на підпису Bitcoin.

Основна функція OP_CAT полягає в поєднанні двох елементів у стеку та вталюванні об'єднаного результату назад у стек. Ця функціональність відкриває можливість для контрактів та перевіряючих STARK на Bitcoin:

• Контракти: Ендрю Поелстра запропонував CAT та Schnorr Tricks I, використовуючи техніки OPCAT та Schnorr для впровадження контрактів на Bitcoin. Алгоритм Schnorr - це цифровий підпис для типів виведення P2TR; для інших типів виведення можна використовувати схожі техніки ECDSA, які були показані в Covenants з CAT та ECDSA. За допомогою контрактів OPCAT алгоритм перевірки STARK може бути розділений на кілька транзакцій, поступово перевіряючи весь доказ STARK.
• STARK Verifier: Верифікатор STARK, по суті, пов'язує дані разом і хешує їх. На відміну від алгебраїчних операцій, хешування є нативною операцією сценарію Bitcoin, яка може заощадити значну кількість накладних витрат. Наприклад, OPSHA256 — це один код операції у власній формі, тоді як змодельована версія вимагає сотень кодів операцій K. Основні операції хешування в STARK включають перевірку шляхів Меркла і трансформації Fiat-Shamir. Тому OPCAT дуже доброзичливо ставиться до алгоритму STARK Verifier.

3.4 Технологія поділу скриптів Bitcoin

Незважаючи на те, що обчислювальне навантаження, необхідне для запуску відповідного алгоритму верифікатора для перевірки доказу після доведення SNARK/STARK, набагато менше, ніж те, яке необхідне для безпосереднього виконання оригінального обчислення f, обсяг скрипту, необхідний при його конвертації для реалізації алгоритму верифікатора в скрипті Bitcoin, все ще величезний. Наразі, виходячи з існуючих кодів операцій Bitcoin, оптимізований розмір сценарію верифікатора Groth16 і розмір скрипта верифікатора Fflonk все ще перевищують 2 ГБ. Однак розмір одного блоку Bitcoin становить лише 4 МБ, що унеможливлює запуск усього сценарію перевірки в межах одного блоку. Однак, починаючи з оновлення Taproot, Bitcoin підтримує виконання скриптів за допомогою tapleaf, що дозволяє розділити скрипт верифікатора на кілька частин, причому кожен фрагмент служить Tapleaf для створення taptree. Узгодженість значень між фрагментами може бути забезпечена за допомогою бітової прив'язки.

За наявності OP_CAT контрактів STARK Verifier можна розділити на кілька стандартних транзакцій розміром менше 400 КБ, що дозволяє завершити всю перевірку валідності STARK без необхідності співпраці з майнерами.

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

Під час виконання розщеплення сценарію необхідно збалансувати наступні аспекти інформації:

• Розмір одного скрипту частини не повинен перевищувати 4 МБ та повинен включати скрипти фіксації бітів введення, підписи транзакцій та інше простір.
• Максимальний розмір стеку одного фрагмента не повинен перевищувати 1000. Тому стек кожного фрагмента повинен містити лише необхідні елементи для збереження достатнього місця в стеці для оптимізації розміру скрипта, оскільки комісії за транзакції Bitcoin не залежать від розміру використаного стеку.
• Бітові зобов'язання щодо біткойнів коштують дорого. Тому кількість бітів на вході та виході між двома сусідніми фрагментами має бути зведено до мінімуму, оскільки наразі 1 біт відповідає 26 байтам.
• Для зручності перевірки функціональність кожного фрагменту повинна бути якнайбільш зрозумілою.

На даний момент методи розділення сценарію можна розділити на наступні три основні категорії:

• Автоматичне розділення: цей метод шукає підхід до розділення, коли розмір сценарію становить близько 3 МБ, а розмір стека мінімізується залежно від розміру стека та розміру сценарію. Переваги цього методу полягають у тому, що він не залежить від конкретних алгоритмів верифікатора і може бути поширений на розбиття скриптів для будь-яких обчислень. До недоліків належать: (1) весь логічний блок повинен бути окремо позначений, наприклад, OP_IF блоки коду, які не можна розділити; в іншому випадку результат виконання розділеного скрипта буде неправильним; (2) результат виконання фрагмента може відповідати декільком елементам у стеку, що вимагає позначення кількості елементів стека, до яких необхідно застосувати бітове зобов'язання на основі фактичної логіки обчислень; (3) читабельність логічної функціональності, реалізованої кожним сценарієм фрагмента, погана, що ускладнює аудит; (4) Стек може містити елементи, які не потрібні для наступного фрагмента, витрачаючи простір стека.
• Функціональне розбиття: Цей метод розділяє на основі різних функціональних підфункцій в обчисленнях, з чіткими вхідними та вихідними значеннями для підфункцій. Розділяючи сценарій, він також реалізує необхідні сценарії бітової прив'язки для кожного фрагмента, гарантуючи, що загальний розмір сценарію фінальних фрагментів менше 4 МБ, а розмір стека менше 1000. Перевагами є: зрозумілий функціонал, зрозуміла логіка для кожного фрагмента, хороша читабельність, простота аудиту. Недоліками є: вираз оригінальної логіки обчислень може не збігатися з логікою на рівні скрипту, а вихідні підфункції обчислень можуть бути оптимальними, але не представляти оптимальність на рівні скрипту.
• Ручне розбиття: У цьому методі точки поділу не базуються на функціональних підфункціях, а встановлюються вручну. Це особливо зручно для випадків, коли розмір однієї підфункції перевищує 4 МБ. Перевагами є: він дозволяє вручну розділяти підфункції великого розміру скрипту, такі як ті, що пов'язані з обчисленнями Fq12; зрозуміла логіка для кожного фрагмента, хороша читабельність і простота аудиту. До недоліків можна віднести: обмежені можливостями ручного налаштування, коли загальний сценарій був оптимізований, раніше встановлені вручну точки поділу можуть бути неоптимальними і потребувати коригування.

Наприклад, після кількох раундів оптимізації розмір скрипта верифікатора Groth16 був зменшений приблизно з 7 ГБ до приблизно 1,26 ГБ. На додаток до цієї загальної обчислювальної оптимізації, кожен фрагмент також може бути оптимізований окремо, щоб повністю використовувати простір стека. Наприклад, впроваджуючи кращі алгоритми на основі таблиць пошуку та динамічно завантажуючи та вивантажуючи таблицю підстановки, можна ще більше зменшити розмір сценарію кожного фрагмента.

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

• Шукайте алгоритми, які оптимізують локальність пам'яті, навіть ціною деякого обчислювального навантаження, щоб зменшити кількість бітів введення/виведення між фрагментами, тим самим зменшуючи обсяг даних, необхідних для зобов'язань у дизайні транзакцій assertTx BitVM2.
• Використовуйте комутативність пов'язаних операцій (наприклад, логічних операцій), таких як x & y = y & x, щоб зекономити майже половину таблиці пошуку.
• На даний момент розмір скрипту, що відповідає операціям Fq12, є великим; розгляньте можливість використання схем Фіата-Шаміра, Шварца-Зіппля та комітмент-схем поліномів для значного зменшення обчислювальної складності операцій розширення Fq12.

4 Резюме

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

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

1. Цю статтю перепринтовано з [aicoin]. Усі авторські права належать оригінальному автору [mutourend & lynndell, Bitlayer Labs]. Якщо є заперечення щодо цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда і вони оперативно цим займуться.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, є виключно думкою автора і не вважаються інвестиційними порадами.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіат перекладених статей заборонені.