Абстракт

Ця стаття вдягається в практичні методи активації ZK-перевірки в Bitcoin, охоплюючи такі теми, як UTXO-модель Bitcoin, обмеження скриптів, Taproot, OP_CAT, BitVM та доведення стану ланцюга. Вона представляє чіткий аргумент, що інтеграція ZK в протокол Bitcoin є необхідністю. Виділяються два потенційні шляхи: один полягає у повторному введенні опкоду OP_CAT для безпосередньої підтримки перевірки SNARK в скриптах Bitcoin - зміна, яка має високу ймовірність остаточного затвердження. Другий підхід пов'язаний з BitVM, який включає докази шахрайства. Крім того, пропозиція команди ZeroSync щодо доведення стану ланцюга має на меті зменшити витрати на перевірку історичних даних для клієнтів вузлів.

Основний текст: Щоб повністю зрозуміти Біткойн, корисно розглядати його як соціальну систему. У свої початкові дні творці Біткойну визначили програмне забезпечення, яке повинні виконувати вузли, схоже на встановлення правил, що регулюють суспільство. Стабільність Біткойну залежить від широкої згоди щодо його фундаментальної природи, що призводить до питань типу «Що таке Біткойн в його основі?» та «У що повинен перетворитися Біткойн?» Однак досягнення консенсусу щодо цих питань відомо важке, оскільки думки різко відрізняються і постійно еволюціонують.

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

Однак Bitcoin обмежує пропускну здатність даних на рівні проектування продукту. Кількість операцій, які він може обробляти за одиницю часу, обмежена. Якщо кількість операцій, які потрібно обробити, стрімко зростає, користувачі розпочнуть цінову війну, щоб успішно завершити операцію швидко, швидко збільшуючи виплати комісій. Одна операція з найвищою комісією за обробку в мережі Bitcoin відбулася після зменшення винагороди за блок у 2024 році, і вартість обробки операції з середньою пріоритетом в ланцюжку досягла 150 доларів. Можна сказати, що дорогі комісії за операції мережі Bitcoin стали проблемою.

Щоб вирішити проблему комісій за транзакції, люди вклали багато ресурсів у розробку мережі Lightning. Але згідно з дослідженням, опублікованим у 2016 році, мережа Lightning на практиці може підтримувати лише десятки мільйонів користувачів і не може реалізувати свою мрію про глобальну платіжну систему. Крім того, окрім надто високих комісій за транзакції, існує ще одна проблема: Біткойн ніколи не зміг досягти бажаної анонімності, яку він уявляв.

Сатоші Накамото вказав у групі обговорення електронної пошти цифрових панків, що Bitcoin має функцію захисту конфіденційності та ініціатор транзакції може бути абсолютно анонімним. Однак, хоча ініціатор транзакції не потребує KYC, дані транзакцій на ланцюгу Bitcoin витікають багато інформації, великою мірою розкриваючи конфіденційність користувача. Хоча є деякі клієнти гаманця з функціями конфіденційності, які вирішують вищезазначені проблеми до певної міри, розробники цих клієнтів гаманця стикаються з загрозами різного розміру. Наприклад, розробник гаманця Samourai CoinJoin був заарештований ФБР у квітні 2024 року, а через тиждень розробник гаманця Wasabi вимкнув свій компонент координації CoinJoin. Очевидно, ці так звані приватні гаманці не зовсім заслуговують на довіру користувачів.

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

У відповідь на вищезазначені питання в спільноті Bitcoin існує багато пропозицій, і ті, які мають найкращі теоретичні результати, повинні бути пов'язані з ZK та SNARKs. За допомогою ZK та SNARKs можна досягти наступні функції:

1. Значно покращена конфіденційність: використовуйте гомоморфний зобов'язання Пітерсона до суми транзакції та Доказ діапазону, щоб значно покращити конфіденційність користувача (наприклад, як це зроблено в боковому ланцюжку Element Blockstream); використовуйте ланкувальні підписи (наприклад, Monero), щоб приховати сліди транзакції; досягнення справді приватних транзакцій (наприклад, Zcash).

2. Покращити пропускну здатність транзакцій

Багато технічних рішень можуть вирішити існуючі проблеми Bitcoin, але чому ці технології не були інтегровані в протокол Bitcoin? Відповідь полягає в складності модифікації протоколу. На відміну від Ethereum, у Bitcoin немає централізованої організації, подібно Ethereum Foundation. Будь-яка зміна протоколу потребує високого рівня спільності згоди, що включає в себе широкі перемовини та балансування інтересів. В результаті, поки Ethereum регулярно оновлює свої опкоди EVM, протокол Bitcoin практично не зазнав змін з моменту свого заснування.

У певному сенсі ця складність зміни протоколу є корисною. Якщо зміни були б легкими для впровадження, зловмисні зміни або атаки були б більш ймовірними. Це породжує питання: Як можна покращити продуктивність Біткойну без зміни протоколу?

Щоб відповісти на це, нам потрібно повернутися до деяких основних аспектів Біткойну. Коли ви переказуєте Біткойни іншій людині, ви створюєте транзакцію й транслюєте її в мережу Біткойн. Дані виводу транзакції вказують кількість переданих BTC. Отримувач може створити нову транзакцію для витрати отриманих BTC, що призводить до генерації нових виводів даних.

Важливо зауважити, що у Bitcoin немає глобального стану, як у Ethereum, особливо відсутній рахунковий стан; він має лише дані виводу транзакцій. У кожному виводі транзакції є два стани: або його витрачено отримувачем, або залишається невитраченим. Невитрачені виводи транзакцій (UTXO) - це те, з чим ми звикли. Крім пов'язаної суми BTC, у кожному виводі транзакції також є прикріплений скрипт, написаний мовою Bitcoin Script. Хто завгодно може надати правильне підтвердження (Свідок) цьому скрипту, може витратити UTXO.

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

Рекомендоване читання: [Наближається BTC: Основні знання для розуміння BitVM (1)]

Можливості Bitcoin Script

Що може робити Bitcoin Script:

• Переставте стек та виконайте перевірку рівності (для перевірки певних умов та забезпечення безпеки та валідності транзакцій).
• Виконуйте умовні операції, схожі на оператори if-else.
• Виконуйте обмежені арифметичні операції з 32-бітовими числами, такі як додавання та віднімання.
• Хешуйте дані та перевіряйте сигнатури ECDSA та Шнорра.

Що не може робити скрипт Біткойн:

• Без циклів, переходів або рекурсії; він не є повністю Тьюрінг-здатним, має дуже обмежені можливості програмування.
• Не вдається виконати побітові операції.
• Відсутні опкоди для множення та ділення.
• Неможливо конкатенувати елементи в стеку.
• Має дуже обмежену можливість читати та перевіряти дані про транзакції на ланцюжку. Біткойн Скрипт не може безпосередньо отримати доступ до суми кожної транзакції та не може передавати стан (UTXO є одноразовими, і кожен переказ спалює старі та генерує нові).

У ранніх версіях Bitcoin деякі з можливостей, згаданих вище як «неможливі», були можливі, але деякі опкоди були відключені Сатоші Накамото через вразливості безпеки. Наприклад, опкод OP_CAT, який може об'єднувати два елементи стеку, використовувався для віддаленого атакування вузлів Bitcoin та спричинення аварій. Сатоші вимкнув OP_CAT та інші опкоди з причин безпеки.

Теоретично, навіть якщо Bitcoin Script не є повністю Тьюрінг-повним, його основні операції достатньо для перевірки будь-яких обчислень. Однак на практиці перевірка SNARK неможлива, оскільки розмір програми, необхідної для кроків перевірки, перевищує максимальний блоковий ліміт Bitcoin у розмірі 4 МБ. Хоча ми могли б спробувати арифметичні операції великими скінченними полями, вартість була б надто висока. Наприклад, у BitVM, множення двох 254-бітних цілих чисел призвело до розміру Bitcoin script близько 8 КБ. Крім того, без OP_CAT вартість перевірки Merkle доказів також висока, оскільки це вимагає операцій, схожих на цикли.

Отже, чому б просто не змінити протокол Bitcoin, щоб додати більш потужні коди операцій? Як зазначалося раніше, досягти консенсусу більшості щодо нових правил протоколу надзвичайно складно. Біткойн не має централізованої особи, яка приймає рішення, і будь-яка пропозиція щодо покращення Bitcoin Script стикається зі значним опором з боку зацікавлених сторін з різними точками зору. Не існує ефективного способу оцінити консенсус спільноти в мережі Bitcoin, і примусове оновлення без нього може призвести до розколу ланцюга. Звичайно, біткойн не зовсім незмінний. Останніми оновленнями були SegWit у 2017 році та Taproot у 2021 році.

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

Крім того, покращення Taproot для Bitcoin можна розподілити на наступні три аспекти:

Спочатку Taproot зменшує витрати на перевірку скриптів з багатьма умовними гілками, що дозволяє Bitcoin підтримувати більш складні програми.

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

Третій, Taproot також додав інші механізми проектування.

Беручи до уваги прецедент Bitcoin з Taproot для інтеграції більш розширених функцій, можна задатися питанням, чому не був представлений спеціальний код операції для перевірки SNARK. Ключова відмінність полягає в складності та консенсусі, необхідних для OP_SNARK. На відміну від Taproot, який мав чіткий, простий дизайн, який отримав широку підтримку, OP_SNARK пропозиції сильно варіюються, що ускладнює згуртування спільноти навколо єдиного підходу. Якщо це буде реалізовано, кожен вузол Bitcoin повинен буде підтримувати цей специфічний метод верифікації SNARK, що значно підвищить технічні вимоги. Крім того, складність, притаманна OP_SNARK, є серйозною перешкодою — Taproot додав близько 1600 рядків коду, керованого за стандартами спільноти, тоді як OP_SNARK спричинило б набагато складніше кодування. Крім того, визначення того, хто буде оцінювати активізацію OP_SNARK, і досягнення консенсусу, коли мало хто повністю розуміє його тонкощі, додає труднощів. З огляду на ці виклики, оновлення OP_SNARK навряд чи відбудеться найближчим часом.

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

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

Функція OP_CAT проста - вона бере два верхні елементи зі стеку, конкатенує їх, а потім знову тисне результат назад на стек. Хоча це може здатися простим, вона має потенціал розблокувати значні покращення в мові сценаріїв Біткоїна. Наприклад, поточні сценарії Біткоїна не можуть отримати доступ до певних даних про транзакції на ланцюгу, таких як залучені суми, але з OP_CAT ця можливість може бути введена. Крім того, OP_CAT може бути інструментальним у перевірці доказів Меркла.

По суті, OP_CAT — це низькорівневе оновлення коду операції, яке може призвести до широкого спектру нових функцій. Багато хто зазначав, що OP_CAT може мати вирішальне значення для досягнення різних цілей. Ключове питання полягає в тому, чи може OP_CAT допомогти у перевірці SNARK у сценаріях. Відповідь: так. Оскільки перевірка доказів Меркла є кроком до валідації SNARK на основі FRI, OP_CAT було б цінним доповненням. У минулому скрипти, призначені для перевірки SNARK, могли бути занадто великими, щоб поміститися в обмеження розміру блоку Bitcoin, але OP_CAT може допомогти оптимізувати ці скрипти, зробивши їх більш компактними.

OP_CAT обговорювався протягом років, зі зростанням усвідомлення його потенційної ролі у внутрішньому огляді транзакцій. Однією з його основних переваг порівняно з іншими пропозиціями є те, що він колись був невід'ємною частиною Bitcoin Script, що може полегшити досягнення згоди спільноти. Однак, недолік полягає в тому, що активація OP_CAT може негативно вплинути на прибутки MEV (Miner Extractable Value) для деяких, що призвело до тривалих дискусій у спільноті щодо його реактивації.

По суті, Біткойн може зробити крок до можливості перевірки SNARK в скриптах, повторно вводячи прості опкоди, такі як OP_CAT. Крім того, варто зазначити недавню пропозицію під назвою «Відновлення великого скрипта», яка повторно вводить опкод множення і дозволяє виконувати всі арифметичні операції з довільною точністю.

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

Наразі блок Bitcoin може містити до 4 МБ даних, приблизно кожні 10 хвилин добуваються нові блоки. Більшість блоків заповнені скриптами Bitcoin та свідцевими даними (схожими на цифрові підписи). У середньому кожен блок може вміщати від 7 000 до 10 000 перевірок підписів, з максимальним обсягом близько 80 000 перевірок на блок. На контекст, мій процесор Intel CPU 2020 року займає приблизно 3,2 секунди на перевірку блоку Bitcoin. Зрозуміло, що швидкість перевірки блоку залежить від чинників, які впливають не тільки на час перевірки підпису.

Крім того, якщо транзакції Bitcoin у кінцевому рахунку підтримуватимуть Zero-Knowledge (ZK) докази, будь-яке збільшення часу генерації транзакцій може не бути серйозною проблемою. Апаратні гаманці, які використовуються для зберігання активів на довгий термін, зазвичай мають екрани і компактний дизайн, спрямований на зберігання ключів та створення підписів. Ці гаманці зазвичай мають відносно низькопотужні процесори, такі як двоядерний процесор з тактовою частотою 240 МГц, але ефективно обробляють транзакції Bitcoin.

Я провів невелике дослідження, запитавши користувачів про максимальне затримку, яку вони прийняли б для генерації доказування підписування, і багато людей були задоволені більш тривалим очікуванням, особливо якщо мали буті великі вигоди. Так що, якщо ми введемо ZK в транзакції Bitcoin, не виглядає, що виникне багато проблем. Ми витратили багато часу на обговорення потенційних змін у базовому дизайні Bitcoin, але існує багато застосувань, які можуть бути розроблені без змін у самому Bitcoin. Одним з таких застосувань, що варто згадати, є Chain State Proofs, пов'язані з BitVM. Цей підхід використовує докази нульового знання для перевірки правильності хешів блоків.

Який вплив має ця технологія на Біткойн? По-перше, докази стану ланцюга можуть значно зменшити робоче навантаження, пов'язане з синхронізацією та перевіркою історичних даних Біткойн, що в свою чергу знижує витрати на обслуговування вузла. В даний час синхронізація та перевірка даних від блоку генезису до останнього блоку займає близько 5 годин і 30 хвилин на пристрої високого класу, і кілька днів на пристрої рівня Raspberry Pi. Докази стану ланцюга можуть значно скоротити цей процес.

По-друге, докази стану ланцюга відіграють важливу роль у просуванні BitVM. Команда ZeroSync докладно дослідила докази стану ланцюга і розробила спрощену версію під назвою "докази ланцюга заголовків". Цей підхід використовує докази нуль-знань для перевірки заголовків блоків Bitcoin, створюючи "ланцюг заголовків", що охоплює всі 850 000 заголовків блоків у історії Bitcoin. Кожен заголовок блоку хешується для отримання 80-байтового доказу. Для перевірки пов'язаної роботи доказу цей метод потребує подвійних обчислень SHA-256 для кожного заголовка. ZeroSync використовує STARKs для створення цих доказів ланцюга заголовків, витрати на їх виробництво становлять близько 4000 доларів, тоді як перевірка займає лише близько 3 секунд у моєму браузері.

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

Однак, навіть якщо шанси на успіх такої атаки низькі, якщо вона дозволить зловмисникам викрасти значну кількість BTC, докази ланцюжка заголовків не будуть вважатися повністю безпечним рішенням. Щоб перевірити повний стан ланцюжка, нам потрібно переконатися, що всі вміст блоків Bitcoin є дійсними, включаючи перевірки електронно-цифрових підписів ECDSA та Schnorr на основі еліптичної кривої secp256k1. Історичні блоки Bitcoin містять приблизно 30 мільйонів підписів щомісяця, загалом близько 2,5 мільярда підписів історично, разом з численними обчисленнями SHA-256. В результаті, мережа Bitcoin генерує приблизно 7 ГБ даних блоків щомісяця, з історичними даними понад 650 ГБ—і на практиці ця цифра може бути в 2-3 рази вище.

Тепер давайте подивимося на BitVM. BitVM дозволяє Bitcoin перевіряти будь-яке обчислювальне завдання, забезпечуючи оптимальний спосіб виконання перевірки SNARK без зміни протоколу. BitVM долає обмеження розміру скрипта Bitcoin за допомогою двох методів. По-перше, він використовує структуру сценарію Taproot MerkleTree. По-друге, він використовує схему зберігання KV, доступ до якої можна отримати за допомогою окремих сценаріїв, що полегшує підключення до великої кількості скриптових програм. Однак протокол Bitcoin не забезпечує цілісність цієї схеми зберігання KV. BitVM вирішує цю проблему, використовуючи докази шахрайства для виявлення зловмисників. Якщо Prover висуває недійсні претензії або використовує несправне сховище KV, інші можуть ініціювати транзакцію в блокчейні Bitcoin, щоб повідомити про неправомірні дії Prover і конфіскувати активи Prover.

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

Прочитайте оригінальний вміст тут: https://www.youtube.com/watch?v=GrSCZmFuy7U

Disclaimer：

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