"Конвенанти" Bitcoin - це механізми, які встановлюють умови для майбутніх транзакцій Bitcoin. У статті описані основні концепції, сценарії застосування та технічні методи реалізації обмежувальних умов, а також обговорюються принципи їхнього дизайну. Вводяться технічні пропозиції, такі як OP_CAT, OP_CTV та APO, та як вони підвищують програмованість та функції смарт-контрактів Bitcoin. У той же час у статті також згадується застосування обмежувальних умов в мережі Bitcoin, такі як контроль заторів, сховища, канали статусів тощо, та обговорюються ідеї дизайну для реалізації обмежувальних умов та потенційні спори у спільноті.

Спільно написаний Джефрі ХуіHarper Li

Останнім часом в спільноті Bitcoin відбулася хвиля обговорення щодо повторного ввімкнення опкодів, таких як OP_CAT, і маг Wizard Taproot залучив увагу, запустивши NFT котів Квантового, стверджуючи, що отримав присвоєний BIP-420. Прихильники стверджують, що ввімкнення OP_CAT дозволить реалізувати «завіти», і таким чином внести у Bitcoin смарт-контракти або програмованість.

Якщо ви помітите слово «завіти» і трішки пошукати, ви побачите, що це ще одна велика кроляча нора. Розробники говорять вже роками про технології, які реалізують завіти, такі як OP_CTV, APO, OP_VAULT та інші, на додаток до OP_CAT.

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

Так що саме таке «завіти» Bitcoin? Чому він залучив стільки уваги та обговорень від розробників протягом років? Яку програмованість Bitcoin можна досягти? Які принципи дизайну стоять за цим? Ця стаття намагається надати огляд та обговорення.

Що таке "Covenants"?

Союз - це механізм, який може встановлювати умови на майбутні транзакції з Bitcoin.

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

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

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

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

Сценарії застосування

Забезпечення штрафів за утримання

Одним із найбільш інтуїтивних прикладів ковенанту є різання транзакції в процесі стейкінгу Bitcoin у Вавилоні.

Процес ставки Bitcoin в Вавилоні передбачає, що користувачі надсилають свої BTC на спеціальний скрипт головного ланцюжка з двома умовами витрати:

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

Джерело: Біткойн Стейкінг: Розблокування 21M Біткойнів для Забезпечення Економіки Доказу Участі

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

Ця функція, після впровадження таких умов, як OP_CTV, може бути реалізована шляхом додавання опкодів до "поганого завершення" стейкінгового скрипта.

Перед активацією OP_CTV в Вавилоні буде потрібен обхідний шлях для емуляції ефекту виконання умов шляхом спільної роботи користувача та комітету.

Контроль заторів/Масштабування

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

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

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

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

Джерело: https://utxos.org/uses/scaling/

Цей сценарій є одним з більш типових випадків використання, які представлені цим обмеженням OP_CTV. Багато інших випадків використання можна знайти на https://utxos.org/uses.Крім контролю за заторами, зазначеного вище, на сторінці перелічені ставки на м'яке вилучення, децентралізовані опції, приводні ланцюги, пакетні канали, неінтерактивні канали, безпечні безкоштовні майнінг-пули, сховища, обмеження безпеки захешованих часових блокувань контрактів (HTLCS) та інше.

Сховища

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

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

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

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

Процес OP_VAULT, джерело: BIP-345

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

Попередньо обчислені сховища та OP_VAULT, джерело: BIP-345

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

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

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

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

Огляд умовних зобов'язань

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

• Тип: загальний, обмежуючий
• Реалізація: на основі опкодів, на основі підписів
• Рекурсія: рекурсивна, нерекурсивна

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

Деякі з популярних дизайнів обіцянок включають:

Дизайни Завітів

Як видно з попереднього вступу, поточні скрипти Bitcoin в основному обмежують умови розблокування і не обмежують те, як цей UTXO може бути подальше витрачений. Щоб реалізувати завіти, нам потрібно мислити по-іншому: чому поточні скрипти Bitcoin не можуть реалізувати завіти?

Основна причина полягає в тому, що поточні скрипти Bitcoin не можуть читати саму транзакцію, що означає інтроспекцію транзакції.

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

Таким чином, дизайн умов також зосереджений на тому, як впровадити інтроспекцію.

На основі опкодів проти на підписах

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

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

APO

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

Поточний діапазон SIGHASH та його комбінації підписів для входів та виходів транзакцій (джерело: "Освоєння Біткойн", 2-е видання)

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

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

Ця гнучкість є обґрунтуванням впровадження обітовок APO:

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

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

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

Проблема з вищезазначеним процесом полягає в тому, що єdev@lists.linuxfoundation.org/msg08075.html">циклічна залежність у обчисленні, оскільки потрібно знати вхід для попереднього підпису та створення транзакції.

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

OP_CTV

OP_CHECKTEMPLATEVERIFY (CTV), або BIP-119, використовує вдосконалення Opcode. Він приймає хеш зобов'язання як аргумент і вимагає, щоб будь-яка транзакція, яка виконує опкод, містить набір виходів, які відповідають цьому зобов'язанню. За допомогою CTV це дозволило б користувачам Bitcoin обмежувати спосіб використання Bitcoin.

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

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

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

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

Джерело: https://bitcoinops.org/en/newsletters/2019/05/29/#proposed-transaction-output-commitments

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

Джерело: https://twitter.com/OwenKemeys/status/1741575353716326835

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

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

Джерело: https://twitter.com/OwenKemeys/status/1741575353716326835

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

Джерело: https://twitter.com/OwenKemeys/status/1744181234417140076

З моменту свого запропонування CTV пройшов зміну назви з COSHV в 2019 році, був призначений BIP-119 в 2020 році, і поява Sapio, мови програмування, використаної для створення контракту для підтримки CTV, і отримав багато обговорень у спільноті, оновлень та дискусій про його варіанти активації в 2022 та 2023 роках, і все ще є однією з найбільш обговорюваних пропозицій щодо м'якого вилучення в спільноті.

OP_CAT

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

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

Ще однією підставою для реалізації є покращення підписів Schnorr: ви можете встановити умову підпису витрат для сценарію у вигляді конкатенації публічного ключа користувача та публічного випадкового числа; тоді, якщо підписник хоче підписати іншу транзакцію для витрати коштів в іншому місці, він чи вона повинні використовувати те ж саме випадкове число, яке може витікати з приватного ключа. Тобто OP_CAT досягає зобов'язання до випадкового числа та таким чином забезпечує валідність підписаної транзакції.

Інші застосування OP_CAT включають Bistream,деревні підписи, квантовостійкі підписи Лампорта, сховища та інше.

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

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

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

Висновок

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

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

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

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

Спеціальні подяки

Дякую Аджан, Fisher та Бендля перегляду та пропозицій!

References

• https://utxos.org/
• https://bitcoincovenants.com/
• Колекція ресурсів, пов'язаних з завітами: https://gist.github.com/RobinLinus/c96fb7c81430ec6dc92f048687bd3068
• https://anyprevout.xyz/
• BIP 345: пропозиція OP_VAULT: https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
• https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf
• https://maltemoeser.de/paper/covenants.pdf
• https://bitcoinops.org/en/topics/op_cat/
• OP_CAT: https://github.com/bitcoin-inquisition/binana/blob/master/2024/BIN-2024-0001.md
• CAT та Снорр-трюки: https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298

Попередження: Цей матеріал призначений виключно для загальної інформації і не становить, і не слід трактувати як будь-які форми інвестиційних порад, запит на інвестиції або пропозицію будь-яких інвестицій, і жодна відповідальність не приймається HashKey Capital щодо використання або покладанняся на будь-яку таку інформацію.

Залишайтеся в курсі останніх новин від HashKey Capital -

Вебсайт — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

заява:

1. Ця стаття відтворена з [середній], авторське право належить оригінальному авторові [Джеффрі ХуіHarper Li], якщо у вас є будь-які зауваження до перепублікації, будь ласка, зв'яжіться з Gate Learnкоманда, і команда якнайшвидше вирішить це згідно з відповідними процедурами.

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

3. Інші мовні версії статті перекладені командою Gate Learn і не згадуються в Gate.io, перекладений матеріал не може бути відтворений, поширений або плагіатований.