1 Вступ

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

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

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

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

Таблиця 1: Методи побудови довіри

Крім того, слід звернути увагу, що:

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

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

Обмеження та прориви в параґрамі Біткойн 2

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

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

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

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

2.2 Біт承诺: прорив обмежень UTXO без стану

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

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

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

OP_HASH160

OP_DUP

0xf592e757267b7f307324f1e78b34472f8b6f46f3> // Це hash1

OP_EQUAL

OP_DUP

OP_ROT

0x100b9f19ebd537fdc371fa1367d7ccc802dc2524> // Це hash0

OP_EQUAL

OP_BOOLOR

OP_VERIFY

// Значення обіцянки Біт зберігається в стеку. Воно може бути "0" або "1".

Наразі, Біт обіцяє мати два способи реалізації:

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

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

2.3 Taproot: прорив обмежень простору скриптів

Taproot-протокол активовано через форк BTC у листопаді 2021 року і містить три пропозиції: підписи Schnorr (BIP 340), Taproot (BIP 341) та TapScript (BIP 342). Це оновлення вводить новий тип транзакцій - транзакції Pay-to-Taproot (P2TR). Завдяки поєднанню переваг Taproot, MAST (дерево абстракцій Меркла) та підписів Schnorr, транзакції P2TR можуть створювати більш приватний, гнучкий та масштабований формат транзакцій.

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

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

2.4 Вихід конектора: зламання обмежень витрат UTXO

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

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

Зображення 1: Схема виводу конектора

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

2.5 Контракт: злам обмеження попереднього підпису

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

Поточна реалізація контракту може бути поділена на два типи:

• Попередній підпис: на основі існуючих можливостей BTC скриптів будується обмежена функціональність попереднього контракту. Це означає, що учасники повинні заздалегідь розробити та підписати всі можливі майбутні угоди, щоб закріпити їх за конкретним Закритий ключ і ставкою. Деякі схеми навіть вимагають, щоб учасники генерували короткострокові Закритий ключі для всіх попередньо підписаних угод. Після завершення попереднього підпису ці короткострокові Закритий ключі будуть безпечно видалені, щоб запобігти отриманню ними зловмисниками та крадіжці коштів. Однак кожного разу, коли додається новий учасник або оновлюється операція, цей процес потрібно повторювати, що призводить до високих витрат на обслуговування. Наприклад, мережа Lighting через попередній підпис реалізує двосторонній контракт та використовує технологію Хешований контракт TimeLock (HTLC) для забезпечення маршрутизації багатьох двосторонніх контрактів, що реалізує мінімізацію довіри стратегії розширення. Однак мережа Lighting потребує попереднього підпису багатьох угод і обмежена лише до двох сторін, що робить її використання складним; в BitVM1, кожен раз при ініціалізації потрібно попередньо підписати сотні угод, а в оптимізованій версії BitVM2, кількість угод, які потрібно попередньо підписати при кожній ініціалізації, також становить десятки. В BitVM1 та BitVM2 право на відшкодування має лише оператор, що бере участь у попередньому підписанні. Якщо у попередньому підписі бере участь n учасників, і кожен учасник повинен попередньо підписати m угод, то складність попереднього підпису для кожного учасника становить n * m.
• Введення операційного коду контракту: Введення нового операційного коду контракту може значно знизити складність комунікації та вартість підтримки між учасниками контракту, надаючи BTC більш гнучкий спосіб реалізації контракту. Наприклад, операційний код OPCAT використовується для з'єднання байтових рядків. Незважаючи на його просту функціональність, він дуже потужний і може значно знизити складність BitVM; Операційний код OPTXHASH дозволяє більш детально контролювати операції в контракті. Якщо використовується в BitVM, він може підтримувати більший діапазон операторів, що значно підвищує безпеку BitVM та мінімізує довіру. Крім того, метод передпідпису по суті означає, що оператор в BitVM може використовувати лише процес погашення, що призводить до менш ефективного використання капіталу; але за допомогою нового операційного коду контракту, можна безпосередньо сплачувати вихідним користувачам з фонду peg-in, подальше підвищення ефективності капіталу. Тому гнучка модель контракту ефективно прориває традиційні обмеження передпідпису.

3 розширення шару 2 BTC: доказ дійсності та доказ шахрайства

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

表 2：доказ дійсності与доказ шахрайства

На основі обітових зобов'язань Біт, Taproot, попередніх підписів та з'єднувачів ви можете побудувати доказ шахрайства на основі BTC. Також, за допомогою введення операційного коду контракту (наприклад OP_CAT), можна побудувати доказ дійсності на основі Taproot BTC. Крім того, доказ шахрайства може бути розділений на дозволений доказ шахрайства та недозволений доказ шахрайства в залежності від того, чи приєднався Боб до системи. У дозволеному доказі шахрайства лише певна група може викликати Боба на виклик, тоді як у недозволеному доказі шахрайства будь-яка третя сторона може викликати Боба на виклик. Бездозвольна система доказу шахрайства є безпечнішою, ніж дозволена система доказу шахрайства, оскільки вона зменшує ризик змови між учасниками.

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

图 2：单轮доказ шахрайства与多轮доказ шахрайства

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

Таблиця 3: Однокругова взаємодія та багаторазова взаємодія

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

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

3.1 BTC多轮доказ шахрайства

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

Рання Біла книга BitVM Robin Linus (зазвичай відома як BitVM1) використовувала багаторазові докази шахрайства. Якщо припустити, що кожен термін виклику триває тиждень і використовує двійковий пошук для знаходження сегменту обчислень проблеми, терміни виклику викликів у відповідь на виклики у блокчейні Groth16 можуть тривати до 30 тижнів, що призводить до поганої актуальності. Хоча наразі деякі команди досліджують більш ефективні методи пошуку n-ary, ніж двійковий пошук, але їхня актуальність все ще значно менша, ніж цикл доказів шахрайства з однієї ітерації за два тижні.

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

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

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

Рис. 3: Одноколісний доказ шахрайства

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

3.3 Використання OP_CAT для доказу дійсності BTC

OP_CAT - це частина мови сценаріїв, яка була заборонена у 2010 році через вразливість безпеки під час випуску BTC. Незважаючи на це, спільнота BTC протягом багатьох років обговорює можливість повторного включення OP_CAT. Наразі OP_CAT має номер 347 і активований у мережі signet BTC.

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

• Контракт: Андрій Пуелстра запропонував CAT та Schnorr Tricks I, щоб реалізувати контракт на BTC за допомогою OP_CAT та Schnorr Алгоритму. Schnorr Алгоритм є цифровим підписом, який застосовується до типів виведення P2TR; для інших типів виведення можна використовувати схожу технологію ECDSA, як показано у контракті з CAT та ECDSA. За допомогою контракту OP_CAT, STARK Верифікатор може розкласти на кілька транзакцій та поступово перевірити всю STARK доведення.
• Валідатор STARK: Основна функція валідатора STARK полягає в з'єднанні даних та їх хешуванні. На відміну від алгебраїчних операцій, хеш є первинною операцією у скриптах BTC, що дозволяє значно зменшити витрати. Наприклад, OP_SHA256 у первинному вигляді є окремим операційним кодом, тоді як у симуляційній версії він вимагає сотні операційних кодів. Основні операції хешування в STARK включають перевірку шляху Меркле та перетворення Фіата-Шаміра. Тому операція OP_CAT є дуже корисною для валідатора STARK Алгоритм.

3.4 Технологія розбиття BTC-скриптів

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

У разі OP_CAT контракту верифікатор STARK може бути розбитий на кілька стандартних транзакцій менших, ніж 400KB, що дозволяє завершити перевірку всього доказу дійсності STARK без необхідності співпраці з Майнером.

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

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

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

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

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

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

Оскільки вартість обчислення та середовище виконання мов програмування Web2 відрізняються від скриптів BTC, просте перетворення існуючих реалізацій Алгоритму на скрипти BTC неможливе. Тому потрібно розглянути спеціальну оптимізацію для сценаріїв BTC:

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

4 Загальні висновки

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

Заява:

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