Біткойн обмеження: новий напрямок досягнення програмованості

Біткойн спільнота нещодавно активно обговорювала повторне використання OP_CAT та інших операційних кодів. Taproot Wizard привернув велику увагу, запустивши Quantum Cats NFT та заявивши про отримання номера BIP-420. Прихильники стверджують, що активація OP_CAT може реалізувати "обмежувальні умови", що приведе до появи смарт-контрактів та Програмованість для Біткойн.

"Обмежувальні положення"(covenants) ця концепція викликала багаторічні обговорення серед розробників. Окрім OP_CAT, існує багато інших технічних рішень для реалізації обмежувальних положень, таких як OP_CTV, APO, OP_VAULT тощо. Отже, що таке "обмежувальні положення" Біткойна? Чому вони викликають таку широку та тривалу увагу? Яку Програмованість вони можуть принести Біткойну? Які принципи дизайну стоять за цим? У цій статті буде представлено огляд та обговорення цих питань.

Що таке "обмежувальні положення"

"Обмежувальні умови"(kovenants) є механізмом, що дозволяє встановлювати умови для майбутніх Біткойн-транзакцій. Поточний Біткойн-скрипт вже містить деякі обмежувальні умови, такі як необхідність введення дійсного підпису, надання скрипту, що відповідає вимогам тощо. Але, якщо користувач може розблокувати, він може витратити UTXO в будь-якому місці.

А обмежувальні умови на цій основі додали більше обмежень, наприклад, обмеження подальшого використання витрат UTXO, для досягнення ефекту "цільового використання"; або обмеження умов інших входів у транзакції тощо.

Точніше кажучи, нинішній скрипт Біткойн також має певні функції обмеження, такі як таймлоки на основі операційних кодів. Перевіряючи поля nLock або nSequence транзакції, можна реалізувати часові обмеження перед витрачанням транзакції. Але наразі це в основному обмежується часовими аспектами.

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

Отже, обмежувальні умови парадоксально можуть відкрити більше сценаріїв застосування.

Сценарії використання

Забезпечте покарання за Staking

Обмежувальні умови наочним прикладом є транзакція slash Babylon у стейкінгу Біткойн.

Процес стейкінгу Біткойн у Babylon полягає в тому, що користувачі надсилають активи BTC до спеціального скрипту на основному ланцюгу, а умови витрат включають два види:

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

2. Покарання закінчено: якщо користувач має подвійний підпис або інші злочинні дії на PoS ланцюгу безпеки Babylon, то через EOTS( можна отримати одноразовий підпис ), який дозволяє розблокувати активи, а виконавчі ролі в мережі примусово відправлять частину активів на адресу спалювання (slash).

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

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

А до активації OP_CTV Babylon потрібно буде реалізувати ефект примусового виконання обмежувальних положень за допомогою компромісного підходу, виконаного разом користувачами та комітетом.

Контроль заторів

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

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

Коли попит на блок-простір високий, транзакції стають дорогими. Використовуючи OP_CHECKTEMPLATEVERIFY, великі платіжні процесори можуть об'єднати всі платежі в єдину O(1) транзакцію для підтвердження. Після цього, коли попит на блок-простір зменшується, з цього UTXO можна розширити платежі.

Це один із典型них прикладів застосування обмеження, запропонованого OP_CTV.

Сховище

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

На основі технології обмежуючих умов можна відносно легко створювати додатки типу сховища.

В якості прикладу рішення OP_VAULT: при витраті коштів з сховища необхідно спочатку надіслати транзакцію в ланцюг, щоб висловити намір ("trigger") та встановити умови:

• Нормальні обставини: друга транзакція є остаточною транзакцією на виведення. Після очікування N блоків, кошти можна витратити на будь-яку адресу.

• Аномальні ситуації: якщо виявлено, що це крадіжка монета ( або примус ), можна негайно перевести кошти на більш безпечну адресу до надсилання транзакцій на зняття в N блоках.

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

більш надійний і гнучкий стан каналу

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

Eltoo(, також відомий як LN-Symmetry), є типовим прикладом. Він пропонує рівень виконання для мережі Lightning, що дозволяє будь-якому наступному стану каналу замінити попередній стан без механізму покарання, таким чином уникаючи необхідності зберігати кілька попередніх станів для вузлів мережі Lightning на випадок зловмисних дій суперника. Eltoo пропонує спосіб підпису SIGHASH_NOINPUT, тобто APO(BIP-118) для досягнення цього ефекту.

Ark має на меті знизити складність вхідної ліквідності та управління каналами в мережі Lightning. Це протокол у формі joinpool, кілька користувачів можуть протягом певного часу приймати одного постачальника послуг як контрагента, здійснюючи віртуальні UTXO(vUTXO) транзакції поза ланцюгом, але ділячись одним UTXO в ланцюзі для зниження витрат. Подібно до сховища, Ark також може бути реалізований у поточній мережі Біткойн; але після введення обмежувальних умов, Ark може знизити необхідну кількість взаємодій на основі шаблонів транзакцій, забезпечуючи більш децентралізований односторонній вихід.

Огляд технічних умов

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

• Тип: універсальний, спеціалізований
• Спосіб реалізації: на основі коду операцій, на основі підпису
• Рекурсивність: рекурсія, нерекурсія

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

Основні обмеження в дизайні умов включають:

• OP_CTV: універсальний, на основі коду операцій, не рекурсивний
• APO:Універсальний, на основі підпису, нерекурсивний
• OP_VAULT:спеціалізований, на основі коду операції, не рекурсивний
• OP_CAT: Загальний тип, на основі коду операцій, рекурсивно (, якщо поєднати з OP_CAT )

Проектування обмежувальних умов

В даний час скрипти Біткойн в основному обмежують умови розблокування, але не обмежують, як UTXO може бути витрачений далі. Щоб реалізувати обмеження, потрібно переосмислити, чому поточні скрипти не можуть виконати цю функцію.

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

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

Отже, проектування умов обмеження в основному зосереджене на тому, як реалізувати самоаналіз.

Базується на коді операцій vs Базується на підписі

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

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

АПО

SIGHASH_ANYPREVOUT(APO) є запропонованим способом підпису Біткойн. Найпростіший спосіб підпису — це зобов'язання щодо всіх входів і виходів транзакції, але Біткойн має ще більш гнучкий спосіб, а саме SIGHASH, який дозволяє вибірково зобов'язуватися щодо входів або виходів у транзакції.

SIGHASH APO підписує лише виходи, а не входи. Це означає, що транзакції, підписані способом APO, можна пізніше прикріпити до будь-якого UTXO, що відповідає умовам.

Ця гнучкість є теоретичною основою для реалізації обмежувальних умов APO:

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

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

Ми можемо зрозуміти через порівняння зі смарт-контрактами Ethereum: через смарт-контракти ми можемо реалізувати те, що для того, щоб зняти кошти з адреси контракту, необхідно виконати певні умови, а не просто покладатися на підпис EOA для довільних витрат. З цього погляду, Біткойн може досягти такого ефекту, покращивши механізм підпису.

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

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

![Детальний аналіз Ковенантів: як реалізувати програмованість Біткойна?])https://img-cdn.gateio.im/webp-social/moments-302ac02874352e52cf0e80c7ddb193ec.webp(

) OP_CTV

OP_CHECKTEMPLATEVERIFY###CTV(, тобто BIP-119, використовує покращений код операцій