Op_Cat: Ідеальне рішення для ковенантів?

OP_CAT дали зелене світло? Пропозиції нещодавно було присвоєно номер BIP 347. Але перш ніж ми заглибимося в цю тему, з'ясуймо, що таке ковенанти та чому вони можуть знадобитися біткоїнерам.

Чи можна назвати Біткоїн ідеальним варіантом цифрових електронних грошей, чи ми хочемо більшого від наших монет у ланцюжку?

Обмеження Біткоїн-скриптів

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

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

Ця простота, яка є основою моделі безпеки Біткоїна, накладає суттєві обмеження на здатність мови сценаріїв підтримувати навіть базові смарт-контракти.

Лінійна модель виконання

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

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

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

Відсутність базової арифметики

Bitcoin Script має трохи менш як 100 нетривіальних кодів операцій, і, що дивно, в ньому немає можливості множити, ділити або комбінувати об'єкти в стеку. Як відомо багатьом користувачам, які цікавляться OP_CAT, Сатоші відключив кілька кодів операцій у Біткоїні у 2010 році, у тому числі OP_OR, OP_MUL (множення), OP_DIV (розподіл) та OP_CAT (об'єднання). Ці коди операцій були відключені, оскільки їхні початкові реалізації містили вразливості, які могли поставити під загрозу безпеку мережі. Але відсутність цих кодів операцій ускладнює виконання базових математичних розрахунків, які можуть бути корисними у простих сценаріях, таких як розрахунок комісій за транзакції у контракті.

Відсутність видимості даних транзакцій

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

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

Що з цим робити?

Ми знаємо, що Біткоїн має ці обмеження, і протягом багатьох років обговорювалося безліч різних пропозицій щодо впровадження (або, в деяких випадках, повторного введення) цієї функціональності. Більші експерименти з Bitcoin Script, такі як Simplicity та інші, спрямовані на надання альтернативи обмеженням на основі стека. Такі коди операцій, як OP_MULTISHA256, OP_LESS та OP_LE32TOLE64, спрямовані на покращення арифметичних можливостей Біткоїна. Пропозиції, такі як OP_CTV та OP_CAT, що стосуються кодів операцій інтроспекції, згруповані під терміном «ковенанти».

То в чому ж різниця між смарт-контрактами та ковенантами?

Смарт-контракти та ковенанти

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

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

Це лише деякі з найцікавіших опкодів інтроспекції функціональності ковенантів:

1. OP_TXHASH: надає хеш вхідних (або вихідних даних) транзакції та дає скрипту можливість перевіряти та забезпечувати дотримання умов на основі даних транзакції.
2. OP_CSFS + OP_CAT: разом вони дозволяють скриптам перевіряти підписи щодо будь-яких даних, а не лише щодо транзакції. Це означає, що скрипт може перевіряти умови на основі даних транзакцій чи зовнішньої інформації, розширюючи можливості перевірки у скриптах Біткоїна.

Ці два коди операцій мають навмисно широке застосування, що забезпечує складні процеси перевірки та можливості інтроспекції. Інші мають вужчу сферу застосування і створені як більш обмежена форма ковенантів.

1. OP_CHECKTEMPLATEVERIFY (CTV): дозволяє вставляти у вихідні дані транзакції шаблон майбутньої транзакції витрат, уможливлюючи ковенанти більш обмеженим способом.
2. OP_VAULT: особлива форма ковенанта, яка використовується для «сховища» і дозволяє користувачам вказувати місце призначення транзакції, але не переміщувати монети фактично, крім як після затримки.

Крім того, існує окремий OP_CAT, який не є безпосередньо опкодом інтроспекції.

1. OP_CAT: дозволяє Script об'єднувати два елементи в стеку, що корисно для об’єднання різних фрагментів інформації всередині скрипту.

У OP_CAT, схоже, немає можливостей для інтроспекції, то що тоді відбувається?

Всі можливості OP_CAT

Інтроспекція транзакцій

У 2021 році Ендрю Поельстра написав у своєму блозі про прийоми інтроспекції OP_CAT. Він навів конкретні приклади, але припустив, що читачі вже знайомі з такими методами. Тут я намагатимусь спростити це пояснення для кращого розуміння.

У Bitcoin Script є лише три основні коди операцій, які дозволяють аналізувати дані транзакції: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY та CHECKSIG. Крім того, існують такі варіанти, як CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG та CHECKMULTISIGVERIFY, які по суті є другорядними варіаціями CHECKSIG. Перші два дозволяють лише побачити, чи підтверджено перевірку, забезпечуючи досить вузький функціонал. CHECKSIG схожий, але різниця в тому, що він дозволяє отримати підпис та відкритий ключ у стеку. Цікаво.

Традиційно ми говоримо про конкатенацію як про функцію, яка з'єднує два елементи, але ми також можемо використовувати її для відокремлення або поділу елемента, в цьому випадку – підпису на пару (r, s).

Як отримати функціональність OP_SPLIT в OP_CAT?

«Можна розділити якийсь великий об'єкт, попросивши користувача надати дві частини. Ви об'єднуєте їх разом та перевіряєте рівність. Таким чином, ви завжди можете інвертувати кожну операцію. За допомогою CAT можна розділяти підпис на частини». - Ендрю Поельстра, TABConf 2021

Що це означає? Вимагаючи від користувача надати підпис, відкритий ключ і транзакцію, можна розділити підпис на частини, а потім перевіряти кожну частину окремо на відповідність даним транзакції. Цей метод можна розглядати як форму поділу або об'єднання, оскільки він підтверджує, що підпис і відкритий ключ є компонентами дійсної транзакції.

Який стосунок це має до інтроспекції?

«У Taproot, де є підписи Шнорра з використанням OP_CAT та опкоду перевірки підпису Шнорра, виявляється можна отримати форму нерекурсивного ковенанту, коли ви буквально отримуєте хеш транзакції. Це не просто спотворений хеш транзакції, а справжній SHA2-хеш усіх даних транзакції в стеку». – Ендрю Поельстра, TABConf 2021

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

Сховища

Використання тих самих методів надає інтроспекцію транзакцій та базову версію сховищ. Слідуючи логіці, викладеній в блозі Поельстри, розробник під ніком Rijndael довів, що ми можемо зробити це за допомогою OP_CAT у своїй реалізації Purrfect Vaults.

«Відновлення TXID у стеку для аналізу попередніх транзакцій виявилося насправді простішим, ніж я очікував». – Rijndael

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

Дерева Меркла

Сьогодні в Біткоїні дерева Меркла – це структура даних, яка використовується для перевірки даних, синхронізації та певного «з'єднання» транзакцій та блоків блокчейну. Код операції OP_CAT, який дозволяє об'єднати два змінні стеки під час спільного використання разом з хешами відкритих ключів SHA256, спрощує процес перевірки дерева Меркла для скриптів. Цей підхід, спочатку запропонований Пітером Уіллем у 2015 році, був успішно реалізований у мережі Liquid.

Уявіть собі деревоподібну структуру, наповнену різними умовами витрат, такими як прообрази хешей, блокування за часом та відкриті ключі, відомі як Tree Signatures.

Tree Signatures

OP_CAT дозволяє створювати Tree Signatures, які:

«...Надають скрипт мультипідпису, розмір якого може бути логарифмічним за кількістю відкритих ключів і який може кодувати умови витрат, які виходять за межі n-з-m. Наприклад, транзакція розміром менше ніж 1 КБ може підтримувати Tree Signatures із тисячею відкритих ключів. Це також забезпечує узагальнені логічні умови витрат». – Автор BIP Ітан Хейлман, у списку розсилки bitcoin-dev

Це дозволить перевіряти будь-який хешований контент у дереві, забезпечуючи цілісність та надійність даних без збільшення об'єму або роздування блокчейна.

Чому це цікаво?

Рекурсивні угоди (ковенанти)

Якщо існуватиме можливість перевірити транзакцію та застосувати обмеження до певних її частин, можна також налаштувати умови, які будуть поширюватися на кілька транзакцій, ефективно створюючи ланцюжок постійних обмежень. Ця концепція називається рекурсивною угодою. OP_CAT – унікальна пропозиція, оскільки вона дає нам стільки можливостей лише у 10 нових рядках коду. Вона здатна усунути всі три початкові обмеження, про які ми говорили на початку статті: видимість даних транзакцій, покращені математичні функції та лінійну модель виконання.

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

Чи безпечно це?

До того, як OP_CAT було видалено, у поєднанні з OP_DUP (дублікат) і повторному використанні для дублювання початково 1-байтового значення в стеку використання пам'яті могло різко зрости. Це могло бути використано як атака типу «відмова в обслуговуванні» (DoS) через підвищене споживання пам'яті. Нова пропозиція тривіально запобігає цій атаці, накладаючи обмеження на елементи стека у розмірі 520 байтів.

Чи існує загроза того, що контракт буде продовжуватися вічно?

Якщо під цим мається на увазі, чи змінює OP_CAT модель виконання Script таким чином, що він більше статично не обмежує використання ресурсів (як лінійну функцію розміру сценарію) – ні.

Чи зможуть ковенанти створити ринок для інших монет, крім Біткоїна?

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

Чи можна назавжди зіпсувати монети використовуючи CAT?

У випадку кольорових монет і NFT, випускаючи ці активи, користувач маркує сатоші таким чином, що це означає володіння активом другого рівня. Цей процес відомий як «позначення» монет. Але тільки власник монети може позначити свою монету, і біткоїн-гаманці більше не розпізнаватимуть її (хіба що їхні автори додадуть код, який дозволятиме це зробити). Отримані монети не прийматимуться біткоїн-гаманцями. Ймовірно, їх прийматимуть гаманці Cryptocat або подібні, але для більшості користувачів біткоїна це не має значення.

Чи створить це проблему MEV для Біткоїна?

Ключовою різницею між Біткоїном та Ethereum є видимість транзакцій. На відміну від Ethereum, не всі аспекти контракту обов'язково прозорі, а це означає, що майнери біткоїна не мають такої самої можливості бачити внутрішній стан контракту і керувати ним.

Основна проблема OP_CAT для біткоїнерів, що мислять з економічного погляду, – це потенційна цінність для майнерів (MEV). Багато користувачів стурбовані тим, що якщо контракти другого рівня стануть технічно можливими, MEV стане неминучим. Але чи так це? Зокрема, чи передбачає технічна здійсненність монет другого рівня в Біткоїні їхнє неминуче створення та впровадження?

Можна уявити створення простих своп-контрактів чи порівняно неефективних NFT, але створення чогось складного, як DEX з автоматичними маркет-мейкерами, здається вкрай малоймовірним і навіть близько не схоже на те, що ми бачили на Liquid, попри «технічну можливість» цього.

Чи ідеальний Op_Cat?

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

Група «закоренілих» біткоїнерів виступає за збереження Біткоїна в його нинішньому стані і ставиться до будь-яких оновлень протоколу зі скептицизмом. Вони особливо стурбовані тим, що значні зміни, такі як запровадження ковенантів, можуть підірвати децентралізацію мережі. Їхні аргументи ґрунтуються на переконанні, що найкраще дотримуватися початкового бачення Біткоїна. Іронія того, що OP_CAT спочатку був частиною Біткоїна, підживлює контраргумент. Дехто вважає, що повернення OP_CAT може фактично зробити Біткоїн відповідним до початкового бачення Сатоші.

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

Або, можливо, хтось надає перевагу простоті нерекурсивних методів, таких як OP_CTV або OP_VAULT. Нерекурсивні ковенанти простіше та легше обговорювати без ризику створення неконтрольованого ланцюжка обмежень.

Що, якщо певна версія рекурсивних ковенантів була б неминуча?

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

У світі Script є дві сфери, залежно від розміру елементів стека. Для елементів стека розміром більше ніж 4 байти можна здійснювати перевірку на рівність, інтерпретувати як ключ підпис чи хешувати. Елементи стека розміром менш як 4 байти чи рівні їм можна розглядати як об'єкти до виконання арифметичних операцій чи розгалуження. З процесором RISC-V, який працює на BitVM, можна робити буквально все. Все, що дозволяє вам емулювати OP_CAT, розбивати елементи стека або об'єднувати їх разом, об'єднує ці дві області, то ж ви можете робити що завгодно за допомогою Script.

Такі дослідники, як Ендрю Поельстра, вважають, що ми зможемо створювати рекурсивні ковенанти практично з будь-яким новим кодом операції. Якщо це так, то це було б виправданням для роботи над тим, щоб удосконалити їх.

Чи є OP_CAT вірогідним шляхом для ковенантів?

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

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

Це гостьовий пост Кіари Бікерс. Висловлені погляди є її власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.