Нещодавно в спільноті Біткойн почалася дискусія щодо повторного використання операційних кодів, таких як OP_CAT. Taproot Wizard привернув увагу багатьох завдяки запуску Quantum Cats NFT та заяві про отримання номера BIP-420. Прихильники стверджують, що активування OP_CAT може здійснити "обмежувальні умови", що дозволить реалізувати смарт-контракти або Програмованість Біткойн.
Якщо ви звернете увагу на слово "обмежувальні умови" і трохи пошукаєте, ви виявите, що це ще одна велика кроляча нора. Розробники обговорюють це вже багато років, крім OP_CAT, також є OP_CTV, APO, OP_VAULT та інші технології для реалізації обмежувальних умов.
Отже, що таке "обмежувальні умови" Біткойна? Чому це привертає так багато уваги та обговорень з боку розробників протягом кількох років? Яка програмованість може бути реалізована за допомогою Біткойна? Які принципи дизайну стоять за цим? У цій статті буде представлений огляд та обговорення.
Що таке "обмежувальні положення"
Обмеження ( Ковенанти ) є механізмом, який може встановлювати умови для майбутніх Біткойн транзакцій.
Поточний скрипт Біткойн також містить обмежувальні умови, наприклад, при витрачанні потрібно ввести законний підпис, надати відповідний скрипт тощо. Але як тільки користувач зможе розблокувати, він може витратити цей UTXO куди завгодно.
А обмежувальні умови полягають у тому, що на основі цих обмежень, що стосуються розблокування, вводяться додаткові обмеження, наприклад, обмеження витрат після UTXO, що забезпечує ефект, подібний до "спеціального використання"; або інші умови входів, введених у транзакцію тощо.
Більш точно кажучи, поточний скрипт Біткойн також має певні обмежуючі умови, наприклад, таймер на основі операційного коду, який реалізується через поля nLock або nSequence транзакції для встановлення часових обмежень перед витрачанням, але в основному обмежується лише часовими аспектами.
Тож, чому розробники та дослідники створюють ці перевірки обмежень? Бо умови обмеження не лише для обмеження заради обмеження, а й для встановлення правил виконання транзакцій. Таким чином, користувачі можуть виконувати транзакції лише відповідно до заздалегідь визначених правил, щоб завершити заплановані бізнес-процеси.
Тому, на перший погляд, це може розблокувати більше застосувань.
Сценарії використання
Забезпечте покарання за Staking
Найочевидніший приклад обмежувальних умов - це транзакція slash у процесі стейкінгу Біткойн від Babylon.
Процес стейкінгу Біткойн у Babylon полягає в тому, що користувачі відправляють свої BTC активи на основному ланцюгу до спеціального скрипту, умови витрат включають два типи:
Нормальна ситуація: через певний час користувач може розблокувати за допомогою свого підпису, завершуючи процес unstake.
Аномальні ситуації: якщо користувач має подвійні підписи або інші злісні дії на PoS ланцюзі, орендованому Babylon, то через EOTS(extractable one-time signatures, одноразові доступні підписи), можна розблокувати цю частину активів, і частина активів буде примусово надіслана на адресу знищення(slash).
Зверніть увагу на "примусове надсилання". Це означає, що навіть якщо цей UTXO можна розблокувати, але цей актив не може бути відправлений куди-небудь, його можна лише спалити. Це гарантує, що злісні користувачі не зможуть швидше повернути активи собі, використовуючи свої відомі підписи, щоб уникнути покарання.
Цю функцію, якщо вона буде реалізована після впровадження обмежувальних умов, таких як OP_CTV, можна додати до гілки "виключних ситуацій" сценарію стейкингу, щоб реалізувати обмеження за допомогою opcode, таких як OP_CTV.
Але перед увімкненням OP_CTV, Babylon повинен знайти обхідний шлях, щоб користувачі та комітет спільно виконували його для імітації ефекту примусового виконання обмежувальних умов.
Контроль заторів
Загалом, затори означають, що коли комісії в мережі Біткойн дуже високі, у пулі транзакцій накопичується досить багато транзакцій, що чекають на упаковку, тому якщо користувач хоче швидко підтвердити транзакцію, йому потрібно підвищити комісію.
А в цей час, якщо користувачеві потрібно надіслати кілька транзакцій кільком отримувачам, йому доводиться підвищувати комісії, нести досить високі витрати. Це також відповідно призводитиме до подальшого зростання комісій в усій мережі.
Якщо є обмежувальні умови, одним із рішень є те, що відправник може спочатку зобов'язатися до однієї великої транзакції. Це зобов'язання може дати всім одержувачам впевненість, що фінальна транзакція відбудеться, і можна почекати, поки комісійні ставки стануть нижчими, перш ніж надсилати конкретну транзакцію.
Коли попит на блок-простір дуже високий, здійснення транзакцій стає дуже дорогим. Використовуючи OP_CHECKTEMPLATEVERIFY, великі платіжні процесори можуть агрегувати всі свої платежі в одну транзакцію O(1) для підтвердження. Потім, через деякий час, коли попит на блок-простір зменшується, платежі можуть бути розширені з цього UTXO.
Ця сцена є досить типовим прикладом застосування обмежувальної умови OP_CTV.
Сховище
Сховище (vault) є одним із широко обговорюваних сценаріїв застосування в Біткойн-додатках, особливо в області обмежувальних умов. Оскільки щоденні операції неминуче повинні балансувати між потребами зберігання коштів і використанням коштів, люди сподіваються на існування певних додатків для зберігання капіталу: які можуть гарантувати безпеку коштів, навіть якщо обліковий запис буде зламано ( і приватний ключ ) буде розкрито, також можна обмежити використання коштів.
На основі технології реалізації обмежувальних умов, застосування типу сховища може бути відносно легко побудовано.
Як приклад дизайну OP_VAULT: при витраті коштів з сховища необхідно спочатку надіслати транзакцію в мережу. Ця транзакція вказує на намір витратити сховище, тобто "trigger", і в ній встановлюються умови:
Якщо все в порядку, тоді друга транзакція є остаточною транзакцією на виведення. Після очікування N блоків, кошти можна буде витратити в будь-якому місці.
Якщо виявлено, що ця угода була вкрадена ( або була отримана під примусом "гаечного ключа" ), до відправлення транзакцій на зняття коштів в N блоках, можна негайно надіслати на іншу безпечну адресу ( для більш безпечного зберігання користувача ).
Необхідно звернути увагу на те, що без обмежувальних умов можна створити застосування для зберігання, одним із можливих способів є підготовка підпису для витрат за допомогою приватного ключа, а потім знищення цього приватного ключа. Але обмежень все ще досить багато, наприклад, необхідно забезпечити, щоб цей приватний ключ вже був знищений ( подібно до процесу trusted setup у нульових знаннях ), суми та комісії мають бути визначені заздалегідь (, оскільки потрібно попередньо підписати ), що призводить до нестачі гнучкості тощо.
Більш надійний і гнучкий канал стану
Зазвичай можна вважати, що канали стану, включаючи мережу Lightning, мають безпеку, яка майже дорівнює безпеці основного ланцюга ( за умови, що вузли можуть спостерігати за останнім станом і нормально публікувати останній стан у ланцюг ). Однак після введення обмежувальних умов деякі нові ідеї дизайну каналів стану можуть бути більш надійними або гнучкими, ніж мережа Lightning. Серед них найбільш відомими є Eltoo, Ark тощо.
Eltoo (, також відомий як LN-Symmetry), є одним із типових прикладів. Ця технологічна пропозиція використовує звукосполучення "L2" та пропонує рівень виконання для мережі Lightning, який дозволяє будь-якому наступному стану каналу замінювати попередній стан без необхідності механізму покарання, а отже, також уникати необхідності зберігати кілька попередніх станів, як це роблять вузли Lightning, щоб запобігти зловживанням з боку суперника. Для досягнення вищезгаданого ефекту Eltoo запропонував підписний метод SIGHASH_NOINPUT, тобто APO(BIP-118).
А Ark має на меті знизити складність, пов'язану з вхідною ліквідністю та управлінням каналами в мережі Lightning. Це протокол у формі joinpool, в якому кілька користувачів можуть протягом певного часу приймати одного постачальника послуг як контрагента, здійснюючи угоди з віртуальними UTXO(vUTXO) поза мережею, але ділячись одним UTXO в мережі, щоб знизити витрати. Подібно до сховища, Ark також можна реалізувати в поточній мережі Біткойн; але після введення обмежувальних умов Ark може на основі шаблонів угод знизити обсяги необхідних взаємодій, досягти більшої децентралізації одностороннього виходу.
Огляд технічних обмежень
З наведеного вище застосування можна побачити, що обмежувальні умови більше схожі на ефект, а не на якусь технологію, тому існує багато різних технічних способів реалізації. Якщо проводити класифікацію, можна включити:
Тип: універсальний, спеціалізований
Спосіб реалізації: на основі Opcode, на основі підпису
Рекурсія: рекурсія, нерекурсія
А серед них, рекурсія означає: реалізація деяких обмежувальних умов може також обмежити наступний вихід, обмежуючи таким чином вихід наступного, що дозволяє реалізувати додаткові обмеження, які можуть перевищувати одну транзакцію, досягаючи більшої глибини торгівлі.
Деякі основні проекти умов обмеження включають:
OP_CTV: універсальний, на основі Opcode, не рекурсивний
OP_VAULT: спеціалізований, на основі Opcode, нерекурсивний
APO:Універсальний, на основі підпису, нерекурсивний
OP_CAT:Універсальний, на основі Opcode, рекурсивний*
OP_CSFS: універсальний, на основі підпису, рекурсивний
*Якщо об'єднати OP_CAT
Проектування обмежувальних положень
З попереднього викладу можна зрозуміти, що поточний скрипт Біткойн в основному обмежує умови розблокування, не обмежуючи, як цей UTXO може бути витрачений далі. Щоб реалізувати обмежувальні умови, ми повинні подумати навпаки: чому поточний скрипт Біткойн не може реалізувати обмежувальні умови?
Причина в основному полягає в тому, що на даний момент скрипт Біткойн не може читати вміст самої угоди, тобто "інтроспекцію" (introspection).
Якщо ми зможемо реалізувати самоаналіз транзакцій — перевірку будь-якого вмісту транзакції (, включаючи вихід ), тоді можна буде реалізувати обмежувальні умови.
Отже, концепція обмежувальних умов також в основному зосереджена на тому, як реалізувати самоаналіз.
на основі операційного коду vs на основі підпису
Найпростіша ідея полягає в тому, щоб додати один або кілька операційних кодів (, тобто один операційний код + кілька параметрів, або кілька різних функціональних операційних кодів ), які безпосередньо зчитують вміст транзакції. Це є ідея, заснована на операційних кодах.
Інший підхід полягає в тому, що можна не читати та не перевіряти вміст транзакції безпосередньо в скрипті, а скористатися хешем вмісту транзакції — якщо цей хеш вже підписано, то достатньо модифікувати, наприклад, OP_CHECKSIG тощо, щоб реалізувати перевірку цієї підпису, що дозволяє непрямо реалізувати самоаналіз транзакції та обмеження умов. Цей підхід базується на дизайні, заснованому на підписі. Основні елементи включають APO та OP_CSFS тощо.
АПО
SIGHASH_ANYPREVOUT(APO) є запропонованим способом підпису Біткойн. Найпростіший спосіб підпису - це зобов'язатися за всіма входами та виходами угоди, але Біткойн також має більш гнучкі способи, тобто SIGHASH, що вибірково зобов'язує за входами або виходами угоди.
А SIGHASH в APO підписує лише виходи, а не входи. Це означає, що транзакції, підписані за допомогою APO, можуть бути в
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Детальний аналіз обмежень Біткойна: початок нової ери Програмованості
Детальний розгляд обмежувальних умов: реалізація програмованості Біткойна
Нещодавно в спільноті Біткойн почалася дискусія щодо повторного використання операційних кодів, таких як OP_CAT. Taproot Wizard привернув увагу багатьох завдяки запуску Quantum Cats NFT та заяві про отримання номера BIP-420. Прихильники стверджують, що активування OP_CAT може здійснити "обмежувальні умови", що дозволить реалізувати смарт-контракти або Програмованість Біткойн.
Якщо ви звернете увагу на слово "обмежувальні умови" і трохи пошукаєте, ви виявите, що це ще одна велика кроляча нора. Розробники обговорюють це вже багато років, крім OP_CAT, також є OP_CTV, APO, OP_VAULT та інші технології для реалізації обмежувальних умов.
Отже, що таке "обмежувальні умови" Біткойна? Чому це привертає так багато уваги та обговорень з боку розробників протягом кількох років? Яка програмованість може бути реалізована за допомогою Біткойна? Які принципи дизайну стоять за цим? У цій статті буде представлений огляд та обговорення.
Що таке "обмежувальні положення"
Обмеження ( Ковенанти ) є механізмом, який може встановлювати умови для майбутніх Біткойн транзакцій.
Поточний скрипт Біткойн також містить обмежувальні умови, наприклад, при витрачанні потрібно ввести законний підпис, надати відповідний скрипт тощо. Але як тільки користувач зможе розблокувати, він може витратити цей UTXO куди завгодно.
А обмежувальні умови полягають у тому, що на основі цих обмежень, що стосуються розблокування, вводяться додаткові обмеження, наприклад, обмеження витрат після UTXO, що забезпечує ефект, подібний до "спеціального використання"; або інші умови входів, введених у транзакцію тощо.
Більш точно кажучи, поточний скрипт Біткойн також має певні обмежуючі умови, наприклад, таймер на основі операційного коду, який реалізується через поля nLock або nSequence транзакції для встановлення часових обмежень перед витрачанням, але в основному обмежується лише часовими аспектами.
Тож, чому розробники та дослідники створюють ці перевірки обмежень? Бо умови обмеження не лише для обмеження заради обмеження, а й для встановлення правил виконання транзакцій. Таким чином, користувачі можуть виконувати транзакції лише відповідно до заздалегідь визначених правил, щоб завершити заплановані бізнес-процеси.
Тому, на перший погляд, це може розблокувати більше застосувань.
Сценарії використання
Забезпечте покарання за Staking
Найочевидніший приклад обмежувальних умов - це транзакція slash у процесі стейкінгу Біткойн від Babylon.
Процес стейкінгу Біткойн у Babylon полягає в тому, що користувачі відправляють свої BTC активи на основному ланцюгу до спеціального скрипту, умови витрат включають два типи:
Зверніть увагу на "примусове надсилання". Це означає, що навіть якщо цей UTXO можна розблокувати, але цей актив не може бути відправлений куди-небудь, його можна лише спалити. Це гарантує, що злісні користувачі не зможуть швидше повернути активи собі, використовуючи свої відомі підписи, щоб уникнути покарання.
Цю функцію, якщо вона буде реалізована після впровадження обмежувальних умов, таких як OP_CTV, можна додати до гілки "виключних ситуацій" сценарію стейкингу, щоб реалізувати обмеження за допомогою opcode, таких як OP_CTV.
Але перед увімкненням OP_CTV, Babylon повинен знайти обхідний шлях, щоб користувачі та комітет спільно виконували його для імітації ефекту примусового виконання обмежувальних умов.
Контроль заторів
Загалом, затори означають, що коли комісії в мережі Біткойн дуже високі, у пулі транзакцій накопичується досить багато транзакцій, що чекають на упаковку, тому якщо користувач хоче швидко підтвердити транзакцію, йому потрібно підвищити комісію.
А в цей час, якщо користувачеві потрібно надіслати кілька транзакцій кільком отримувачам, йому доводиться підвищувати комісії, нести досить високі витрати. Це також відповідно призводитиме до подальшого зростання комісій в усій мережі.
Якщо є обмежувальні умови, одним із рішень є те, що відправник може спочатку зобов'язатися до однієї великої транзакції. Це зобов'язання може дати всім одержувачам впевненість, що фінальна транзакція відбудеться, і можна почекати, поки комісійні ставки стануть нижчими, перш ніж надсилати конкретну транзакцію.
Коли попит на блок-простір дуже високий, здійснення транзакцій стає дуже дорогим. Використовуючи OP_CHECKTEMPLATEVERIFY, великі платіжні процесори можуть агрегувати всі свої платежі в одну транзакцію O(1) для підтвердження. Потім, через деякий час, коли попит на блок-простір зменшується, платежі можуть бути розширені з цього UTXO.
Ця сцена є досить типовим прикладом застосування обмежувальної умови OP_CTV.
Сховище
Сховище (vault) є одним із широко обговорюваних сценаріїв застосування в Біткойн-додатках, особливо в області обмежувальних умов. Оскільки щоденні операції неминуче повинні балансувати між потребами зберігання коштів і використанням коштів, люди сподіваються на існування певних додатків для зберігання капіталу: які можуть гарантувати безпеку коштів, навіть якщо обліковий запис буде зламано ( і приватний ключ ) буде розкрито, також можна обмежити використання коштів.
На основі технології реалізації обмежувальних умов, застосування типу сховища може бути відносно легко побудовано.
Як приклад дизайну OP_VAULT: при витраті коштів з сховища необхідно спочатку надіслати транзакцію в мережу. Ця транзакція вказує на намір витратити сховище, тобто "trigger", і в ній встановлюються умови:
Необхідно звернути увагу на те, що без обмежувальних умов можна створити застосування для зберігання, одним із можливих способів є підготовка підпису для витрат за допомогою приватного ключа, а потім знищення цього приватного ключа. Але обмежень все ще досить багато, наприклад, необхідно забезпечити, щоб цей приватний ключ вже був знищений ( подібно до процесу trusted setup у нульових знаннях ), суми та комісії мають бути визначені заздалегідь (, оскільки потрібно попередньо підписати ), що призводить до нестачі гнучкості тощо.
Більш надійний і гнучкий канал стану
Зазвичай можна вважати, що канали стану, включаючи мережу Lightning, мають безпеку, яка майже дорівнює безпеці основного ланцюга ( за умови, що вузли можуть спостерігати за останнім станом і нормально публікувати останній стан у ланцюг ). Однак після введення обмежувальних умов деякі нові ідеї дизайну каналів стану можуть бути більш надійними або гнучкими, ніж мережа Lightning. Серед них найбільш відомими є Eltoo, Ark тощо.
Eltoo (, також відомий як LN-Symmetry), є одним із типових прикладів. Ця технологічна пропозиція використовує звукосполучення "L2" та пропонує рівень виконання для мережі Lightning, який дозволяє будь-якому наступному стану каналу замінювати попередній стан без необхідності механізму покарання, а отже, також уникати необхідності зберігати кілька попередніх станів, як це роблять вузли Lightning, щоб запобігти зловживанням з боку суперника. Для досягнення вищезгаданого ефекту Eltoo запропонував підписний метод SIGHASH_NOINPUT, тобто APO(BIP-118).
А Ark має на меті знизити складність, пов'язану з вхідною ліквідністю та управлінням каналами в мережі Lightning. Це протокол у формі joinpool, в якому кілька користувачів можуть протягом певного часу приймати одного постачальника послуг як контрагента, здійснюючи угоди з віртуальними UTXO(vUTXO) поза мережею, але ділячись одним UTXO в мережі, щоб знизити витрати. Подібно до сховища, Ark також можна реалізувати в поточній мережі Біткойн; але після введення обмежувальних умов Ark може на основі шаблонів угод знизити обсяги необхідних взаємодій, досягти більшої децентралізації одностороннього виходу.
Огляд технічних обмежень
З наведеного вище застосування можна побачити, що обмежувальні умови більше схожі на ефект, а не на якусь технологію, тому існує багато різних технічних способів реалізації. Якщо проводити класифікацію, можна включити:
А серед них, рекурсія означає: реалізація деяких обмежувальних умов може також обмежити наступний вихід, обмежуючи таким чином вихід наступного, що дозволяє реалізувати додаткові обмеження, які можуть перевищувати одну транзакцію, досягаючи більшої глибини торгівлі.
Деякі основні проекти умов обмеження включають:
*Якщо об'єднати OP_CAT
Проектування обмежувальних положень
З попереднього викладу можна зрозуміти, що поточний скрипт Біткойн в основному обмежує умови розблокування, не обмежуючи, як цей UTXO може бути витрачений далі. Щоб реалізувати обмежувальні умови, ми повинні подумати навпаки: чому поточний скрипт Біткойн не може реалізувати обмежувальні умови?
Причина в основному полягає в тому, що на даний момент скрипт Біткойн не може читати вміст самої угоди, тобто "інтроспекцію" (introspection).
Якщо ми зможемо реалізувати самоаналіз транзакцій — перевірку будь-якого вмісту транзакції (, включаючи вихід ), тоді можна буде реалізувати обмежувальні умови.
Отже, концепція обмежувальних умов також в основному зосереджена на тому, як реалізувати самоаналіз.
на основі операційного коду vs на основі підпису
Найпростіша ідея полягає в тому, щоб додати один або кілька операційних кодів (, тобто один операційний код + кілька параметрів, або кілька різних функціональних операційних кодів ), які безпосередньо зчитують вміст транзакції. Це є ідея, заснована на операційних кодах.
Інший підхід полягає в тому, що можна не читати та не перевіряти вміст транзакції безпосередньо в скрипті, а скористатися хешем вмісту транзакції — якщо цей хеш вже підписано, то достатньо модифікувати, наприклад, OP_CHECKSIG тощо, щоб реалізувати перевірку цієї підпису, що дозволяє непрямо реалізувати самоаналіз транзакції та обмеження умов. Цей підхід базується на дизайні, заснованому на підписі. Основні елементи включають APO та OP_CSFS тощо.
АПО
SIGHASH_ANYPREVOUT(APO) є запропонованим способом підпису Біткойн. Найпростіший спосіб підпису - це зобов'язатися за всіма входами та виходами угоди, але Біткойн також має більш гнучкі способи, тобто SIGHASH, що вибірково зобов'язує за входами або виходами угоди.
А SIGHASH в APO підписує лише виходи, а не входи. Це означає, що транзакції, підписані за допомогою APO, можуть бути в