огляд

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

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

на даний момент, в біткойн-скрипті підтримуються лише три основні опкоди для інтроспекції: checklocktimeverify, checksequenceverify та checksig, разом з їх варіантами checksigverify, checksigadd, checkmultisig та checkmultisigverify.

ковенант, простими словами, відноситься до обмежень на передачу монет, що дозволяє користувачам вказувати, як розподіляються utxo. багато ковенантів реалізуються за допомогою опкодів інтроспекції, а обговорення про інтроспекцію тепер віднесені до теми ковенантів на Gate.io.Біткойн optech.

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

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

Нижче ми опишемо широко обговорюваний пропозицію опкоду угоди.

CTV (CheckTemplateVerify) BIP-119

ctv (checktemplateverify) - це пропозиція щодо оновлення біткойна, що міститься в bip-119 і залучила значну увагу спільноти. ctv дозволяє вихідному скрипту вказати шаблон для витрати коштів у транзакції, включаючи поля, такі як nversion, nlocktime, scriptsig hash, input count, sequences hash, output count, outputs hash, input index. Ці обмеження шаблону реалізовані за допомогою хеш-зобов'язання, і при витраті коштів скрипт перевіряє, чи співпадають хеш-значення вказаних полів у витратній транзакції з хеш-значеннями у вхідному скрипті. Це ефективно обмежує час, метод і суму майбутніх транзакцій для цього UTXO.

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

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

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

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

CTV може значно розширити мережі другого рівня. Наприклад, у мережі Lightning CTV може дозволити створювати дерева часу очікування та фабрики каналів, розширюючи один UTXO до дерева CTV, відкриваючи кілька каналів стану лише з однією транзакцією та одним підтвердженням. Крім того, CTV також підтримує атомні торги в протоколі Ark через ATLC.

apo (sighash_anyprevout) bip-118

bip-118 вводить новий тип прапорця хешу підпису для tapscript, спрямований на полегшення більш гнучкої логіки витрат, відомої як sighash_anyprevout. apo та ctv мають багато спільного. При вирішенні циклічної проблеми між scriptpubkeys та txids підхід apo полягає в виключенні відповідної інформації про вхід та підписуванні лише виходів, що дозволяє транзакціям динамічно прив'язуватися до різних utxos.

Логічно, операція перевірки підпису op_checksig (та її варіанти) виконує три функції:

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

специфіка підпису має багато гнучкості, з вирішенням про те, які поля транзакції підписувати, визначеним за допомогою прапорця sighash. Згідно з визначенням опкодів підпису в BIP 342, прапорці sighash поділяються на sighash_all, sighash_none, sighash_single та sighash_anyonecanpay. sighash_anyonecanpay контролює входи, тоді як інші контролюють виходи.

sighash_all - це значення за замовчуванням sighash, яке підписує всі виходи; sighash_none не підписує жодного виходу; sighash_single підписує певний вихід. sighash_anyonecanpay може бути встановлено з першими трема значеннями sighash. Якщо встановлено sighash_anyonecanpay, то підписується лише вказаний вхід; в іншому випадку потрібно підписати всі входи.

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

Так, BIP 118 пропонує sighash_anyprevout. Підпису APO не потрібно прив'язуватися до витраченого вводу utXO (відомого як Prevout), а потрібно лише підписувати виходи, забезпечуючи більшу гнучкість у контролі Bitcoin. Шляхом попередньої побудови транзакцій та створення відповідних одноразових підписів та відкритих ключів, активи, надіслані на цю адресу з відкритим ключем, повинні бути витрачені через попередньо створену транзакцію, таким чином реалізуючи ковенант. Гнучкість APO також може бути використана для відновлення транзакцій; Якщо транзакція застрягла в ланцюжку через низькі комісії, можна легко створити іншу транзакцію, щоб збільшити комісію без необхідності нового підпису. Крім того, для гаманців з мультипідписом не залежить від витрачених вхідних даних, що робить операції зручнішими.

Оскільки це усуває цикл між ScriptPubKeys і вхідними TXID, APO може виконувати самоаналіз, додаючи вихідні дані в Witness, хоча це все одно вимагає додаткових витрат простору для свідків.

для off-chain протоколів, таких як мережа блискавок та сховища, apo зменшує необхідність зберігання проміжних станів, що значно зменшує вимоги до зберігання та складності. найпряміше використання apo - це eltoo, яке спрощує фабрики каналів, будує легкі та недорогі вежі, дозволяє односторонні виходи без залишення помилкових станів, покращуючи продуктивність мережі блискавок у багатьох відношеннях. apo також можна використовувати для моделювання функцій ctv, хоча це вимагає, щоб особи зберігали підписи та попередньо підписані транзакції, що є більш витратним та менш ефективним, ніж ctv.

Головна критика apo зосереджена на необхідності нової версії ключа, яку не можна впровадити просто шляхом забезпечення сумісності з попередніми версіями. Крім того, новий тип підпису може створити потенційні ризики подвійного витрачання. Після широких обговорень у спільноті apo додав регулярні підписи до початкового механізму підпису, щоб пом'якшити побоювання щодо безпеки, тим самим здобувши код bip-118.

op_vault bip-345

BIP-345 пропонує додати два нових коди операцій, op_vault і op_vault_recover, які в поєднанні з CTV реалізують спеціалізовану ковенант, що дозволяє користувачам застосовувати затримку на витрачання певних монет. Під час цієї затримки раніше здійснена транзакція може бути «скасована» через шлях відновлення.

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

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

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

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

впровадження сховища через bip-345 вимагає урахування питань витрат, особливо для відновлювальних транзакцій. можливі рішення включають cpfp (child pays for parent), тимчасові якорі, та нові прапори хеш-підпису sighash_group.

tluv (таплифеафупдатеверіфі)

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

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

1. оновити внутрішній публічний ключ
2. обріж путь Меркле
3. видалити виконуваний в даний момент скрипт
4. додайте новий крок в кінці мерклевого шляху

Конкретно, tluv приймає три вхідні дані:

1. той, що вказує, як оновити внутрішній загальний ключ.
2. той, що вказує на новий крок для шляху Меркла.
3. той, який вказує, чи видаляти поточний скрипт та/або скільки кроків дерева Меркла вирізати.

опкод tluv обчислює оновлену scriptpubkey та перевіряє, що вихід, що відповідає поточному вводу, витрачено на цей scriptpubkey.

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

Опкод tluv забезпечує обмеження часткового витрачання шляхом оновлення початкового дерева taproot, але не реалізує інтроспекцію суми виведення. Тому потрібен новий опкод in_out_amount. Цей опкод запихує два елементи на стек: суму utxo для цього входу та суму для відповідного виведення, після чого ті, хто використовує tluv, очікують використання математичних операторів для перевірки того, що кошти належним чином зберігаються в оновленому scriptpubkey.

Внутрішнє спостереження за вихідними сумами ускладнюється тим, що суми в сатошах потребують до 51 біту для представлення, але скрипти дозволяють лише 32-бітні математичні операції. Це потребує перевизначення поведінки опкоду для оновлення операторів у скриптах або використання sighash_group для заміни in_out_amount.

TLUV має потенціал як рішення для децентралізованих пулів фінансування рівня 2, хоча надійність у налаштуванні Taproot Trie все ще потребує підтвердження.

матт

matt (мерклізуйте все) має на меті досягти трьох цілей: мерклізувати стан, мерклізувати сценарій та мерклізувати виконання, тим самим забезпечуючи універсальні розумні контракти.

1. мерклізація стану: це включає побудову мерклівського дерева, де кожен листок представляє хеш стану, а мерклівський корінь втілює загальний стан контракту.
2. мерклізація скрипту: це відноситься до формування мастерноди за допомогою тапскрипту, де кожен листовий вузол представляє можливий шлях переходу стану.
3. мерклізоване виконання: виконання мерклізується за допомогою криптографічних зобов'язань та механізму виклику шахрайства. для будь-якої обчислювальної функції учасники можуть обчислити поза ланцюжком, а потім опублікувати зобов'язання, f(x)=y. якщо інші учасники знайдуть неправильний результат, f(x)=z, вони можуть ініціювати виклик. арбітраж виконується за допомогою бінарного пошуку, схожого на принцип оптимістичного rollup.

Мерклізація страти

для впровадження метта мові скриптів біткоїна потрібно мати наступні функціональності:

1. змусити вихід мати певний скрипт (і їх суми)
2. прикріпити шматок даних до виводу
3. прочитайте дані з поточного введення (або іншого)

Другий пункт є критичним: динамічні дані означають, що стан може бути обчислений через вхідні дані, які надає витрачач, оскільки це дозволяє симулювати машину стану, здатну визначити наступний стан та додаткові дані. Схема Matt реалізує це за допомогою опкоду op_checkcontractverify (op_ccv), який є об'єднанням раніше запропонованих опкодів op_checkoutputcontractverify та op_checkinputcontractverify, використовуючи додатковий параметр flags для вказівки цілі операції.

контроль за обсягами продукції, що випускається: найпростішим методом є прямий самоаналіз; Однак вихідні суми є 64-бітними числами, що вимагає 64-бітної арифметики, що представляє значну складність у сценарії Bitcoin. op_ccv застосовує підхід відкладеної перевірки, подібний до op_vault, коли всі входи на один і той же вихід з ccv підсумовуються, служачи нижньою межею для суми цього виходу. Відстрочка пов'язана з тим, що ця перевірка відбувається під час процесу транзакції, а не під час скриптової оцінки вхідних даних.

З огляду на універсальність доказів шахрайства, певні варіанти контракту MATT повинні бути здатні реалізовувати всі типи смарт-контрактів або конструкцій рівня 2, хоча додаткові вимоги (такі як блокування капіталу та затримки періоду виклику) повинні бути точно оцінені; Необхідні подальші дослідження, щоб оцінити, які програми є прийнятними для транзакцій. Наприклад, використання криптографічних зобов'язань і механізмів боротьби з шахрайством для імітації функції op_zk_verify, досягнення безнадійних зведень на Bitcoin.

На практиці все вже відбувається. Йохан Торос Хальсет (Johan Torås Halseth) використав для реалізації код операції op_checkcontractverify з пропозиції Matt Soft Fork elftrace, що дозволяє будь-якій програмі, яка підтримує компіляцію risc-v, бути перевіреною в блокчейні біткойн, що дозволяє стороні у протоколі контракту отримати доступ до коштів через перевірку контракту, тим самим з'єднуючи перевірку біткойну.

csfs (op_checksigfromstack)

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

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

Гнучкість csfs дозволяє реалізувати механізми, такі як підписи платежів, делегування авторизації, контракти оракулів, захист від подвійного витрачання облігацій, і, що ще важливіше, інтроспекцію транзакцій. Принцип використання csfs для інтроспекції транзакцій досить простий: якщо вміст транзакції, який використовується op_checksig, пушується в стек через свідка, і та сама відкритий ключ та підпис використовуються для перевірки як з op_csfs, так і з op_checksig, і якщо обидві перевірки успішно пройдуть, тоді довільний вміст повідомлення, що передається op_csfs, такий самий, як серіалізована транзакція витрат (і інші дані), які неявно використовуються op_checksig. Ми потім отримуємо перевірені дані транзакції в стеку, які можуть бути використані для застосування обмежень до витратних транзакцій з іншими опкодами.

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

csfs може виконувати опкоди, такі як cltv, csv, ctv, apo та інші, що робить його універсальним опкодом інтроспекції. Таким чином, він також сприяє рішенням масштабованості для другого рівня біткойн. Недолік полягає в тому, що для інтроспекції за допомогою csfs потрібно додати повний копію підписаної транзакції в стек, що може значно збільшити розмір транзакцій. Натомість одноразові опкоди інтроспекції, такі як cltv та csv, мають мінімальні накладні витрати, але для додавання кожного нового спеціального опкоду інтроспекції потрібні зміни консенсусу.

хеш транзакції (op_txhash)

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

внаслідок схожості між txhash та ctv, у спільноті виникло значна кількість обговорень щодо цих двох.

txhash може бути вважений універсальним оновленням ctv, яке пропонує більш розширений шаблон транзакції, який дозволяє користувачам вказувати частини витратної транзакції явно, вирішуючи багато питань, пов'язаних з комісіями за транзакції. на відміну від інших опкодів обітних умов, txhash не вимагає копіювання необхідних даних у свідку, що додатково зменшує вимоги до зберігання; на відміну від ctv, txhash не є сумісним z nop і може бути реалізований лише в tapscript; поєднання txhash та csfs може служити альтернативою ctv та apo.

З погляду конструювання ковенантів, txhash сприяє створенню «додаткових ковенантів», де всі частини даних угоди, які ви хочете закріпити, поміщаються в стек, хешуються разом, а отриманий хеш перевіряється на відповідність фіксованому значенню; ctv більш підходить для створення «віднімальних ковенантів», де всі частини даних угоди, які ви хочете залишити вільними, поміщаються в стек. потім, за допомогою опкоду rolling sha256, хешування починається з фіксованого проміжного стану, який закріплює префікс даних хешування угоди. вільні частини хешуються в цей проміжний стан.

поле txfieldselector, визначене в специфікації txhash, очікується розширити на інші опкоди, такі як op_tx.

bip, пов'язаний з txhash, наразі знаходиться в статусі чернетки на GitHub і не має присвоєного номера.

op_cat

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

насправді, поведінка op_cat досить проста: вона конкатенує два елементи зі стеку. як вона включає функціональність договору?

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

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

у підписах Шнорра повідомлення, яке потрібно підписати, складається з наступних полів:

Ці поля містять основні елементи транзакції. Помістивши їх у scriptpubkey або witness і використавши op_cat у поєднанні з op_sha256, ми можемо створити підпис Шнорра та перевірити його за допомогою op_checksig. Якщо верифікація проходить, стек зберігає перевірені дані про транзакції, досягаючи самоаналізу транзакції. Це дозволяє нам витягувати та «перевіряти» різні частини транзакції, такі як її входи, виходи, цільові адреси або залучені суми біткойнів.

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

У підсумку, універсальність op_cat дозволяє йому емулювати майже будь-який опкод угоди. Багато опкодів угоди базуються на функціональності op_cat, що значно покращує його позицію в списку злиття. Теоретично, спираючись лише на op_cat та існуючі опкоди біткойну, ми сподіваємося створити довірчу btc zk rollup. Starknet, Chakra та інші партнери екосистеми активно підтримують це.

висновок

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

без гнучкого основного рівня неможливо побудувати більш гнучкий другий рівень.

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

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

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

APO, op_vault і TLUV схиляються до прямих застосувань, і їх вибір може досягти конкретних застосувань дешевшим і ефективнішим способом. Ентузіасти Lightning Network віддали б перевагу APO для досягнення LN-симетрії; тим, хто хоче реалізувати сховище, найкраще підійде op_vault; Для створення Coinpool TLUV пропонує більшу конфіденційність та ефективність. op_cat і txhash є більш універсальними, з меншою ймовірністю вразливостей безпеки і можуть реалізовувати більше випадків використання в поєднанні з іншими кодами операцій, можливо, ціною складності скрипта. CTV і CSFS налаштували обробку блокчейну, при цьому CTV реалізує відкладені виходи, а CSFS реалізує відкладені підписи. Метт виділяється своєю стратегією оптимістичного виконання та доказів шахрайства, використовуючи структуру спроби Меркла для реалізації універсальних смарт-контрактів, хоча вона все ще вимагає нових кодів операцій для інтроспективних можливостей.

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

відмова від відповідальності:

1. ця стаття переписана з [Дзеркало]. всі авторські права належать оригінальному автору [ чакра]. Якщо є заперечення до цього перевидання, будь ласка, зв'яжіться зНавчання на Gateкоманда, і вони оперативно займуться цим.
2. відповідальність за відмову: погляди та думки, висловлені в цій статті, є виключно поглядами автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate.io learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонено.