Вперше за чотири роки Біткойн може зустріти «користувацький софтфорк»?

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

Автор: GaryMa 吴 говорить про блокчейн

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

Цього разу на базовому рівні підтримуються два пропозиції з поліпшення Біткойна (BIP), а саме BIP-119 (CTV) та BIP-348 (CSFS). Ці два пропозиції пропонують новий спосіб написання скриптів Біткойна, який дозволить Біткойну реалізувати функцію «угод» (Covenants). Ці два пропозиції можуть бути реалізовані під час наступного м’якого хардфорку Біткойна.

Щоб уникнути ситуації, коли деякі читачі тимчасово не можуть зрозуміти зв’язок між Ковенантами Біткойна та конкретними схемами BIP, давайте розберемося:

Простими словами, Ковенанти – це функціональна концепція в мережі Біткойн, а два BIP, згадані в тексті, є різними варіантами реалізації цієї функціональної концепції.

Що таке Ковенанти Біткойна?

Визначення:

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

Дія:

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

Тут, мабуть, можна зрозуміти, що Пакти – це концепція, а BIP-119 (CTV) та BIP-348 (CSFS), згадані в цій статті, є конкретною реалізацією цієї функціональної концепції Пактів.

Поточний стан:

Біткойн основна мережа наразі офіційно не інтегрувала жодних функцій, пов’язаних з Covenants, хоча відповідні обговорення та пропозиції (як-от BIP-119) просуваються вже багато років.

BIP 119:OP_CHECKTEMPLATEVERIFY (CTV)

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

Запропонована колишнім учасником ядра Біткойн Джеремі Рубіном, вона існує вже більше п’яти років. Вона реалізує функцію «перенесення стану», обмежуючи витрати коштів лише певними попередньо визначеними способами.

Сценарії застосування включають:

• Створення масових платежів (Batch Payments), зменшення комісій за транзакції. Побудова децентралізованої біржі (DEX) або кредитного протоколу.
• Реалізація Vaults (сховищ), захист коштів від крадіжки.
• CTV є легковаговою реалізацією Covenants, яка зосереджена на обмеженнях формату виходу, не займаючись складною логікою.

BIP 348:OP_CHECKSIGFROMSTACK (CSFS)

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

Офіційно запропоновано Джеремі Рубіном і Брендоном Блеком у листопаді 2024 року.

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

Конкретні застосування:

• Реалізація Ковенантів: OP_CSFS може використовуватися для створення складної умовної логіки, що забезпечує витрачання коштів лише за певними правилами. Наприклад, валідатор може перевіряти, чи відповідають вхідні транзакції попередньо встановленим шаблонам або обмеженням.
• Підвищена безпека: підтримка Vaults та децентралізованих протоколів, запобігання крадіжкам або несанкціонованим витратам за допомогою перевірки підписів.
• Масштабованість: у поєднанні з іншими операційними кодами (такими як OP_CAT) можна створювати складніші смарт-контракти.

А згадуючи про Covenants Біткойна та дві групи пропозицій BIP-119 (CTV) та BIP-348 (CSFS), напевно, не обійдеться без OP_CAT.

BIP 347:OP_CAT

Історія:

Ранні існування: OP_CAT є частиною оригінальної мови скриптів Біткойна, яку Сатоші Накамото включив у 2009 році під час запуску Біткойна. Він спочатку був розроблений для підвищення гнучкості скриптів, підтримуючи складнішу логіку.

Причина видалення (2010 рік):

• OP_CAT був видалений (вимкнений) у 2010 році через потенційні проблеми з безпекою та зловживання ресурсами.
• Конкретна проблема: якщо не вводити обмеження, OP_CAT може бути використано зловмисними користувачами для генерації безкінечно довгих даних (через рекурсивні виклики), що призводить до «атаки відмови в обслуговуванні» (DoS Attack), оскільки вузли Біткойн повинні обробляти ці дані, збільшуючи витрати на обробку та зберігання.
• Тоді мова сценаріїв Біткойн була спрощена, зберігши найосновніші функції, щоб забезпечити легкість, безпеку та децентралізацію протоколу.

Визначення та роль:

OP_CAT є кодом операцій (Opcode) мови сценаріїв (Script) Біткойна, який не є безпосередньою реалізацією Covenant, але є потенційним інструментом для побудови складної логіки Covenant. На відміну від двох вище згаданих кодів операцій, OP_CAT є більш універсальним, підходить для обробки даних, але потребує поєднання з іншими кодами операцій для реалізації складних функцій.

Стан:

Біткойн спільнота останніми роками знову обговорює повернення OP_CAT, який раніше з’являвся у вигляді пропозиції BIP-420, що мала більш ігровий характер для спільноти, але наразі офіційно об’єднаний під номером BIP-347 у репозиторії bitcoin/bips.

Як просувається

Згідно з новинами Coindesk, протягом останніх кількох тижнів багато західних Біткойн-розробників активно висловлювали свою підтримку CTV і CSFS в Twitter — це безумовно є сильним сигналом, що принаймні в соціальних медіа деяка частина Біткойн-спільноти рухається в напрямку прийняття цих змін.

Крім того, розробники загалом вважають, що визначення цих двох пропозицій є досить «вузьким». Іншими словами, це означає, що після активації ймовірність ненавмисного зловживання з боку користувачів є досить низькою. Спільнота розробників Біткойн завжди була обережною щодо змін у Біткойн. Наприклад, незважаючи на те, що BIP 119 вже майже п’ять років на паузі, нещодавно CTV також вважали надто радикальним і таким, що не підлягає активації.

Співзасновник цих двох пропозицій ДжереміRubin раніше зазнав сильного опору під час кампанії з просування CTV — зокрема, з боку деяких біткойн-лідерів думок з великою кількістю послідовників, таких як Адам Бек і Джиммі Сунг. Різні критики врешті-решт переросли у широке незадоволення в біткойн-спільноті, змусивши Рубіна в підсумку відійти від біткойн-сфери.

Отже, що ж стало причиною цієї зміни? Нещодавнє просування операційного коду OP_CAT, здається, розширило межі того, що вважається «прийнятним» для пропозицій Біткойна, окресливши CTV та CSFS як відносно «консервативні» варіанти. Варто зазначити, що більшість прихильників OP_CAT також підтримують BIP 119 та BIP 348 (а також більшість інших пропозицій).

Що ми можемо очікувати далі? По-перше, обговорення продовжиться. Очікується, що розробники на кількох технічних конференціях далі обговорять ці пропозиції, наприклад, заплановані на квітень OPNEXT, на липень BTC++ та на жовтень TABConf. Як тільки розробники досягнуть попередньої згоди, фактична активація м’якого форка буде передана майнерам, спільноті та інвесторам для остаточного підтвердження.

Як стежити за прогресом обговорення BIPs у спільноті / процесом м’якого форку?

Відповідь важка!

Технічне співтовариство Біткойн зазвичай проводить глибокі обговорення цих пропозицій. Але це виглядає як заплутаний і циклічний процес обговорення.

Простими словами, процес м’якого хардфорку Біткойна потребує приблизної оцінки рівня підтримки від різних зацікавлених сторін Біткойна, до яких відносяться розробники, сховища, інвестори та майнери. Найбільш очевидний показник підтримки зазвичай надходить від майнерів, оскільки вони можуть вказувати на свою підтримку змін у коді, випускаючи сигнали в згенерованих блоках. Зазвичай Bitcoin Core вимагає, щоб протягом певного часу 95% блоків випускали сигнали підтримки, лише після цього оновлення буде заблоковано для активації.

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

Проте компанія Taproot Wizards, відома своїми NFT на основі Біткойна, на прикладі OP_CAT розкрила довгий і складний процес м’якого хардфорку Біткойна у вигляді блок-схеми. Зацікавлені читачі можуть ознайомитися самостійно, а тут ми намагатимемося підсумувати.

Життєвий цикл BIPs пропозицій | Довгий і складний процес м’якого хардфорка Біткойна

1. Пропозиція спочатку була висунута та обговорена в списку розсилки розробників Біткойн.

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

3. Базові громади пишуть чернетку BIP для пропозицій на Github.

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

5. Після перевірки редакторами сховища Біткойн BIP та попереднього схвалення спільноти, присвоюється офіційний номер BIP.

6. Увійти в тестову мережу Signet. Signet - це тестова мережа Біткойн, що дозволяє розробникам експериментувати з новими функціями або змінами коду без впливу на основну мережу. (Можливо, більшість нових функцій залишаться на цьому етапі назавжди)

7. Можливо зайти в Liquid бічний ланцюг для експериментів.

8. Подати PR до Bitcoin Core.

9. Увійдіть у процес перевірки коду Bitcoin Core та злиття пропозицій із високим ступенем невизначеності. Тільки тоді, коли більшість заперечень буде уникнено та виконано технічні вимоги (без серйозних помилок), пропозиція матиме шанс перейти на стадію злиття; Внесок ключових розробників, таких як Пітер Вуйль, часто має вирішальне значення, і схвалення або відхилення може сильно вплинути на долю пропозиції.

10. Якщо перевірка коду не виявила проблем, чекайте, поки майстер-репозиторій Біткойн об’єднає PR в головний проект. Наразі є п’ять підтримувачів: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Продовжуються потенційні суперечки та обговорення між різними групами, такими як розробники Біткойн і майнери.

12. Виберіть механізм активації:

a. Софт-форк під керівництвом майнера (MASF): Режим за замовчуванням, в якому майнери активують нові правила, такі як BIP-9 або BIP-8, за допомогою сигналу (зазвичай поріг 95%). Він відносно стабільний, але його потрібно узгоджувати з широким консенсусом і тестуванням, тому це займає багато часу;

b. Користувацький контрольований м’який форк (UASF): активується нове правило (таке як «Lockinontimeout: True» у BIP-8) за примусовою участю операторів вузлів (користувачів), обминаючи опір майнерів, що несе потенційний ризик розгалуження ланцюга та розбіжностей у спільноті.

Висновок

Ву сказав, що раніше повідомлялося, що Bitcoin.org супроводжуючий домену Cobra попередив, що мережа Bitcoin може започаткувати програмний форк під керівництвом користувача (UASF), ініційований анонімними розробниками за межами Bitcoin Core у 2025 році, що насправді є потенційною зміною BIP 119, згаданою в цій статті. Cobra вважає, що ці покращення можуть спровокувати розкол між «солістами» та «покращувачами», очолюваними низовими спільнотами та керованими розробниками, які не є розробниками Bitcoin Core.

Мається на увазі, що UASF (софтфорк, керований користувачем) - це оновлення протоколу, ініційоване користувачами Bitcoin, шляхом оновлення програмного забезпечення вузла для примусового оновлення протоколу, навіть якщо майнери або інші сторони не підтримують його, тому це також означає ризик форку ланцюга. Звичайно, на даний момент про це турбуватися не варто, адже багато хто ще не вирішені. Наприклад, чи будуть майбутні софт-форки містити тільки CTV і CSFS? Чи буде враховуватися ОП_CAT, який часто обговорюється з цим набором кодів операцій? Як буде розгортатися фактичний процес активації софтфорка? Чи приділять інші зацікавлені сторони, такі як майнери біткойнів, достатньо уваги?

Зрештою, поки консенсус щодо BIP достатньо великий, пропозиції, керовані спільнотою, також можуть мати форму софтфорку під керівництвом майнерів (MASF). І навіть для УАСФ в історії є історії успіху. UASF зіграла ключову роль в оновленні SegWit 2017 року, де користувачі успішно просунули софтфорк, уникнули хардфорка і полегшили масштабування Bitcoin.

Посилання для довідки: