Стаття «Воскресіння» була видалена Кодом операції Сатоші Накамото?, читайте OP_CATSoft Fork

Оригінальна стаття Jaleel, BlockBeats

У кодовій базі Біткойн код операції “OP _CAT”, який був видалений Сатоші Накамото і довгий час був запечатаний історією, може бути “воскреслим”.

Навколо коду операції OP_CAT проект Bitcoin Non-fungible Token Taproot Wizards запустив нову серію Non-fungible Token Quantum Cats. Хоча термін OP_CAT не відноситься до знайомого «кота», Taproot Wizard використав образ кота, щоб випустити новий невзаємозамінний токен під назвою Quantum Cats, використовуючи культуру мемів, щоб допомогти OP_CAT наростити імпульс. Читайте також: “Біткойн “квантовий кіт”: без смарт-контракту як досягти динамічної зміни написів?”

OP_CAT, Код операції, який колись був видалений Сатоші Накамото з скриптової мови Біткойн, тепер повернутий на обговорення для обговорення, і деякі розробники Біткойн хочуть “воскресити” цей код операції і прокласти шлях для реалізації Смарт-контракту Біткойн за допомогою софтфорку з 13 рядків коду. Натхненні розробниками Bitcoin і створивши імпульс в образі мема про кота, запал і дискусія про OP_CAT досягли нових висот.

Код операції «Воскресіння» видалений Сатоші Накамото

Коди операцій, також відомі як інструкції або функції, є основними будівельними блоками скриптової мови Біткойн. Історично склалося так, що деякі операційні коди були видалені з попередніх версій Bitcoin через занепокоєння з приводу можливих вразливостей у клієнтських реалізаціях, однією з яких є OP_CAT Operation Code.

OP_CAT спочатку був частиною офіційного набору команд Bitcoin, дозволяючи з’єднувати рядки, зрощуючи два елементи в один. Однак, оскільки критична вразливість, знайдена в коді операції, така як OP_LSHIFT, може призвести до збою будь-якого BitcoinNode, існує занепокоєння, що OP_ CAT Operation Code може призвести до експоненціального зростання елементів стека, що може призвести до експоненціального збільшення використання пам’яті та розміру скрипту.

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

У жовтні 2023 року розробник Bitcoin Core Ітан Хейлман і головний інженер-програміст Botanix Labs Армін Сабурі спільно випустили проєкт пропозиції щодо покращення Bitcoin (BIP) під назвою «OP_CAT», який вивів цю дискусію на новий рівень.

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

Умови “воскресіння” виконані

Що стосується того, чому Код операції, який був видалений Сатоші Накамото, тепер відновлюється розробниками, мотиваційний розділ цього проекту BIP пояснюється досить детально: це в основному базується на міркуваннях використання пам’яті, і OP_CAT змушує використання пам’яті конструкцій скриптів експоненціально збільшуватися від розміру самого скрипту. Зокрема, простий скрипт, який просто надсилає 1-байтове значення в стек, потім реплікує його за допомогою коду операції OP_DUP і об’єднує його 40 разів за допомогою коду операції OP_CAT, може призвести до роздуття значення стека до величезного розміру понад 1 ТБ.

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

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

1. Попит на просунуті смарт-контракти та протоколи: У міру зростання екосистеми Bitcoin зріс попит на більш просунуті та складні смарт-контракти та протоколи. OP_CAT підвищує виразність і функціональність кранів, дозволяючи об’єднувати об’єкти на стеку. Наприклад, його можна використовувати для створення та оцінки дерева Меркла та інших структур хеш-даних, підтримуючи сигнатури дерева, постквантові сигнатури Лемпорта, контракти про нерозірвання, сховища тощо.

2. Інші історії успіху в мережі: Деякі форки Bitcoin, такі як Bitcoin Cash і Sidechain Liquid, знову ввімкнули OP_CAT і використовували його для реалізації створення та управління токенами, платіжних каналів і способів вбудовування та отримання даних у блокчейн. Це вказує на те, що OP_CAT можна безпечно та ефективно використовувати у відповідних умовах та обмеженнях.

3. Дослідження квантової безпеки: Деякі дослідження припускають, що якщо такі операції, як OP_CAT, можуть бути використані в поєднанні з такими технологіями, як сигнатури Лемпорта, можна побудувати квантово-безпечні транзакції та протоколи біткойнів. Це дослідження має потенційну цінність для підвищення майбутньої безпеки системи Bitcoin.

4. Розвиток спільноти та технологій: Постійний розвиток біткойн-спільноти та технології спонукав людей переглянути та оцінити попередні рішення. У міру того, як з’являється більш глибоке розуміння протоколу Bitcoin та нові технології, функції, які раніше вважалися проблематичними або незастосовними, можуть знайти безпечні та корисні варіанти використання в нових контекстах.

Софт-форк, про який легко говорити

На технічному рівні небагато інших пропозицій Bitcoin так легко інтерпретувати та розуміти, як OP_CAT. Але OP_CAT Operation Code буде активовано шляхом перевизначення софт-форку Operation Code OP_SUCCESS 126, що, очевидно, є непростим завданням.

Нагадаємо, що останній софтфорк Bitcoin відбувся три роки тому, коли був активований Taproot, що допомогло прокласти шлях до народження Ordinals.

Консенсус і прозорість високо цінуються біткойн-спільнотою, і будь-які значні зміни в коді широко обговорюються і розглядаються в спільноті, включаючи софтфорки. Для того, щоб фрагмент коду був об’єднаний з кодовою базою Bitcoin, він повинен пройти суворий і детальний процес, який забезпечує якість пропозиції та консенсус спільноти. Ось основні етапи цього процесу:

1. Напишіть пропозицію та код: По-перше, розробнику потрібно написати детальний документ пропозиції. Цей документ повинен чітко описувати мотивацію, технічні деталі, оцінку впливу та будь-які потенційні проблеми чи виклики, пов’язані з пропозицією.

2. Обговорення спільноти: Після того, як пропозиція коду подається до спільноти Bitcoin, вона обговорюється та розглядається членами спільноти (включаючи розробників, майнерів, інвесторів та користувачів). Цей етап є ключовим для забезпечення реалістичності пропозиції та збору зворотного зв’язку.

3. Модифікації та покращення: На основі відгуків спільноти, авторам коду може знадобитися внести зміни та покращення до пропозиції.

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

5. Реалізація коду: Як тільки буде досягнуто консенсусу, код буде перевірено командою розробників Bitcoin Core. Цей крок вимагає забезпечення якості та безпеки коду.

6. Злиття з кодовою базою: Після схвалення код буде об’єднано з офіційною кодовою базою Bitcoin.

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

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

Що кажуть розробники біткойнов

Приділимо особливу увагу обговоренню OP_CAT серед розробників біткойнов в останні роки.

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

Тепер, коли ми зібрали інформаційний бюлетень Optech і різноманітний пов’язаний з ним контент, давайте розберемося з деякими дискусіями розробників Bitcoin про код операції OP_CAT в хронологічному порядку.

2019

Ітан Хейлман, один зі спонсорів проекту OP_CAT Bitcoin Improvement Proposal (BIP), заявив в електронному листі в жовтні 2019 року, що він розуміє, чому його видалили через жахливу ситуацію, з якою стикалися скрипти в той час, але він підкреслив цінність OP_CAT як коду операції: «Більшість протоколів, які хочуть будувати на основі Bitcoin сьогодні, мають обмеження: значення стека не можуть бути пов’язані. Як дослідник, якщо я відчуваю це обмеження, то, швидше за все, воно також перешкоджає прогресу інших. Якби я міг змахнути чарівною паличкою, щоб знову ввімкнути один із вимкнених кодів операцій, я б вибрав OP_CAT. Звичайно ж, це буде супроводжуватися умовою: розмір кожного об’єднаного значення повинен бути обмежений 64 байтами або менше. 」

Коли справа доходить до обговорення OP_CAT, Ендрю Поельстра – це людина, яка ніколи не зможе обійти стороною. 30 січня 2021 року він написав статтю під назвою «CAT і трюки Шнорра I», яка викликала хвилю дискусії про OP_CAT. Ендрю Поельстра є директором з досліджень Blockstream і досвідченим розробником сценаріїв BitcoinCryptography з сильною присутністю в галузі.

У статті Ендрю Поельстра пояснює: «OP_CAT допомагає об’єднати два елементи в стеку та перемістити об’єднаний результат назад у стек. Цю функцію можна використовувати для збирання кількох малих елементів в один великий елемент або для розкладання великого елемента на кілька менших елементів. CHECKSIGFROMSTACK (CSFS) – це небачений раніше код операції в Bitcoin, який дозволяє користувачам виконувати перевірку підпису на довільних даних, на відміну від коду операції CHECKSIG, який перевіряє лише підписи транзакцій. 」

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

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

ЦЕ ДОЗВОЛЯЄ КОРИСТУВАЧЕВІ НАДАТИ ДАНІ ДЛЯ ВСІЄЇ ТРАНЗАКЦІЇ В СТЕКУ, А СКРИПТ ВИКОРИСТОВУЄ OP_CAT ДЛЯ УПАКОВКИ ДАНИХ В SINGLE ITEM, ХЕШУВАННЯ ЇХ, А ПОТІМ ПЕРЕДАЧІ В CHECKSIGFROMSTACK ДЛЯ ПЕРЕВІРКИ ПІДПИСУ НА ДАНИХ. Потім він передає той самий підпис і секретний ключ до CHECKSIG. Якщо обидві перевірки проходять, це вказує на те, що дані про транзакції, надані користувачем, дійсно є реальними даними про транзакції. Таким чином, скрипт може безпосередньо використовувати ці дані для виконання будь-яких перевірок, передбачених контрактом.

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

Приблизно через два тижні після виходу CAT і Schnorr Tricks I, Ендрю Поельстра опублікував другу статтю, CAT and Schnorr Tricks II, в якій Ендрю Поельстра розповідає більше подробиць і своїх думок:

У травні 2019 року розробник Bitcoin Джеремі Рубін запропонував код операції Bitcoin CHECKOUTPUTSHASHVERIFY з метою впровадження базового та обмеженого смарт-контракту, який дозволяє уникнути технічних та соціальних ризиків, пов’язаних із попередніми конструкціями смарт-контрактів. Згодом цей код операції був замінений на SECURETHEBAG, а пізніше на CHECKTEMPLATEVERIFY, який офіційно став Bitcoin Improvement Proposal BIP 0119 у січні 2020 року.

Тим часом, Рассел О’Коннор пропонує додати CHECKSIGFROMSTACK і OP_CAT Operation Code безпосередньо до Bitcoin, щоб підтримувати смарт-контракти, які не обмежені пропозицією Рубіна. Незважаючи на те, що пропозиція зустріла певний спротив, і обговорення в кінцевому підсумку зменшилося, в основному через неефективність смарт-контрактів типу CAT+CHECKSIG і довгострокове негативне враження від повного універсального володіння смарт-контрактами.

Ендрю Поельстра також спочатку неохоче підтримував так звану функцію BitcoinSmart Contract. Однак восени 2019 року приватний обмін з Ітаном Хейлманом змінив його думку. Ітан Хейлман зазначив, що, незважаючи на занепокоєння, насправді можна реалізувати смарт-контракти, які вважаються шкідливими через CHECKMULTISIG і фактично не приймаються гаманцями та користувачами через їх недостатнє визнання та доступність. Щоб довести це, Ітан Хейлман закликав людей у соціальних мережах придумати життєздатні «темні» смарт-контракти, але поки що нікому це не вдалося.

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

У 2021 році

За цим послідувала стаття Джеремі Рубіна 6 липня 2021 року, в якій він пояснював OP_CAT з точки зору квантової безпеки біткойна. Джеремі Рубін є не тільки розробником Bitcoin, але й засновником Judica, науково-дослідної організації Bitcoin, яка займається розробкою мови програмування смарт-контрактів Bitcoin, Sapio.

В електронних листах та блогах Джеремі Рубін обговорює, як провести квантову перевірку Bitcoin за допомогою OP_CAT Operation Code та підписів Lamport. Автор починає з огляду попередньої публікації в блозі про те, як зареєструвати 5-байтові значення за допомогою арифметики сценарію Bitcoin і сигнатур Лемпорта. Цей метод хоч і акуратний, але має свої обмеження. Джеремі Рубін (Jeremy Rubin) придумав: що, якби ми могли підписувати довші повідомлення, особливо якщо ми могли б підписати до 20 байт, ми могли б підписати потенційно квантово-безпечний дайджест HASH 160.

Джеремі Рубін (Jeremy Rubin) далі досліджує наслідки підписання дайджесту HASH 160 у статті та пояснює можливість розкривати лише Private Key, не змінюючи фактичний підписаний вміст, навіть якщо Quantum Computer зламає ECDSA. Для цього автори звернулися до вченого-криптографіста Мадарса Вірзи і отримали ствердну відповідь.

Джеремі Рубін зазначає, що якщо ми вимагаємо, щоб підписи ECDSA були підписані за допомогою квантового алгоритму доказу підпису, ми можемо отримати квантовий доказ Bitcoin. 5-байтова схема підпису, розглянута раніше, насправді є квантово-безпечною сигнатурою Лемпорта. На жаль, цей метод вимагає не менше 20 послідовних байт.

Тому Джеремі Рубін припустив, що потрібна якась OP_CAT-подібна операція. У статті пояснюється, що OP_CAT не може бути розгалужений безпосередньо до Segwit v 0, оскільки він змінює стек. Отже, для спрощення, автор показує, як використовувати новий код операції OP_SUBSTRINGEQUALVERIFY який перевіряє рівність якоїсь частини рядка шляхом перевірки семантики.

5 листопада 2021 року на конференції Bitcoin в Атланті Джеремі Рубін та Ендрю Поельстра були серед спікерів, які обговорювали пропозицію щодо повторного ввімкнення Operation Code OP_CAT, стверджуючи, що OP_CAT важливий у контексті Bitcoin та підкреслюючи його потенціал, особливо з точки зору квантової безпеки та створення складного смарт-контракту. Наприклад, у поєднанні з CAT та кодом операції верифікації підпису Шнорра теоретично може бути реалізований нерекурсивний смарт-контракт. Цей смарт-контракт здатний поміщати хеш даних транзакцій SHA 2 безпосередньо в стек. Таким чином, можна в тій чи іншій мірі накласти обмеження на різні частини угоди.

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

2022

Під час обговорення списку розсилки розробників Bitcoin від 18 травня 2022 року про повторне введення коду операції OP_CAT, який був видалений з Bitcoin у 2010 році, розробник ZmnSCPxj припустив, що для досягнення неминучого рекурсивного смарт-контракту OP_CAT потрібно буде поєднати із запропонованим Кодом операції, таким як OP_TX, OP_CHECKSIGFROMSTACK (CSFS) тощо. Рекурсивний смарт-контракт використовує правила консенсусу Bitcoin, щоб гарантувати, що всі біткойни, отримані від контракту, можуть бути витрачені лише на один і той самий контракт.

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

Надав Івгі зазначає, що CAT все ще потрібен для вирішення проблеми хешування при створенні рекурсивних смарт-контрактів, але це означає, що такі функції, як CTV і APO, які зосереджені на самоаналізі вихідних даних, також можна поєднувати з CAT для створення рекурсивних смарт-контрактів. Ivgi стверджує, що при використанні в поєднанні з функціональністю taproot, перевірка попереднього результату з наступним виходом полегшує написання сценаріїв смарт-контрактів, і надає посилання на два приклади рекурсивних смарт-контрактів.

ZmnSCPxj погодився з аналізом Івгі і повторив своє занепокоєння з приводу ризиків включення рекурсивних смарт-контрактів на Bitcoin, хоча він також зазначив у наступному дописі, що рекурсивні смарт-контракти можуть бути безпечними, оскільки вони насправді не є Turing Complete. Рассел О’Коннор цитує статтю Ендрю Поельстри, в якій описується, як CAT сам по собі може бути поєднаний з існуючою функціональністю Bitcoin настільки, щоб створювати нерекурсивні смарт-контракти, і теоретично, якщо його повторно додати до Bitcoin, він також може самостійно створювати рекурсивні смарт-контракти.

У 2023 році

У січні Ентоні Таунс запустив Bitcoin Inquisition, копію Bitcoin Core, призначену для роботи на печатці за замовчуванням для тестування запропонованих софт-форків та інших серйозних змін у протоколі. Станом на кінець 2023 року Bitcoin Inquisition підтримала низку пропозицій, а крім того, до її кодової бази були подані PR (pull requests), призначені для OP_CAT, OP_VAULT та лімітних 64-байтових транзакцій, що, як очікується, ще більше розширить можливості цього тестового стенду.

23 серпня 2023 року в списку розсилки Lightning-Dev Томас Фогтлін виступив з ідеєю доказу шахрайства щодо статусу прострочених резервних копій. Фогтлін зазначає, що цей доказ шахрайства можна використовувати он-чейн, якщо OP_CHECKSIGFROMSTACK (CSFS) і OP_ CAT код операції додані до Bitcoin способом софт-форку. Пропозиція викликала багато дискусій, Пітер Тодд зазначив, що базовий механізм є загальним і не обмежується ЛН і може бути корисним у різних протоколах, але він також запропонував простіший механізм, який тут не обговорюватиметься.

До жовтня Расті Рассел працював над смарт-контрактом загального призначення для скриптової мови Bitcoin з мінімальними змінами. У той же час, що дуже важливо, Ітан Хейлман і Армін Сабурі спільно опублікували проект BIP, в якому запропонували додати OP_CAT Operation Code, код операції для з’єднання двох елементів у стеку. Дискусії на ці дві теми тривали до листопада.

У 2024 році

Зараз січень 2024 року, і Quantum Cats справді вдалося вивести дискусію про BIP та процес Bitcoin для OP_CAT на новий рівень.

Спілкуючись зі спільнотою, розробник Bitcoin Core Ава Чоу сказала: «Я не думаю, що CTV є приблизним консенсусом. Я думаю, що інші більш загальні пропозиції смарт-контрактів насправді ближчі, такі як txhash або CAT. Однак я не стежив уважно за дискусією. 」

Ава Чоу (@achow 101) в даний час займає 5-е місце в рейтингу авторів коду Bitcoin Core з 1 292 комітами коду і є однією з небагатьох, хто має право на злиття кодового коду. Як наслідок, вона також має великий вплив у спільноті розробників.

"Я не пропоную активувати OP_CAT. Я підтримую OP_CAT, тому що саме Код операції, швидше за все, досягне консенсусу. Якщо ви не знаєте про OP_CAT, я підсумовую ситуацію на цьому зображенні. Так вважає Ерік Уолл (@ercwl), співтворець Taproot Wizard.

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

Десять рядків коду, щоб дозволити Bitcoin реалізувати смарт-контракт

Як пояснює Ерік Уолл (@ercwl), співтворець Taproot Wizard: «Люди цього не усвідомлюють, але OP_CAT насправді є одним із будівельних блоків zkrollup на Bitcoin. 」

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

Пов’язане читання: Що думають досвідчені розробники про BitVM для обчислень будь-чого на Bitcoin?

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

У той час як співавтор Taproot Wizard Ерік Уолл (Eric Wall) в захваті від концепції, що лежить в основі BitVM, він вважає, що ця пропозиція може стати «технічним глухим кутом» для Bitcoin через його величезні накладні витрати і довгий цикл реалізації. Він стурбований тим, що BitVM може відволікати спільноту і перешкоджати реальному розвитку. Незважаючи на це, пропозиція BitVM все ще демонструє активний дух досліджень та інновацій у сфері технології Blockchain та смарт-контрактів.

Власне, сама команда проекту Taproot Wizard працює над впровадженням рішення рівня 2 на Bitcoin, а в попередньому просторі вони також заявили, що завершений раунд фінансування в розмірі $7,5 млн буде використаний для вивчення варіантів масштабування біткоіни.

Тому софтфорк OP_CAT також буде для них важливим кроком. Ерік Уолл, який раніше був членом правління StarkNet Foundation, дуже зацікавлений у створенні DeFi на додаток до створення інклюзивного рівня розрахунків, тому, коли Ethereum почав з’являтися у 2019 році, його, природно, приваблював простір децентралізованих фінансів на Ethereum.

Дослідження біткойна децентралізованих фінансів було майже повністю припинено, коли у 2019 році стало очевидним, що Ethereum та інші блокчейни можуть масштабуватися за допомогою zk-rollup або оптимістичних доказів шахрайства. З дослідженням доцільності масштабування zk-rollup, застосованого до Bitcoin, Волл звернувся до підтримки децентралізованих фінансів на Ethereum. Але врешті-решт він намагається привнести цю систему і ці технологічні переваги в біткойн.

Крім того, в гілці обговорення на OP_CAT на форумі bitcointalk, Картера Фельдмана (@cmpeq), засновника проекту QED, запитали, як він має намір використовувати цей код операції в біткойн-скриптах, і чи обчислює він середні байти стека свідків і комісії, які можуть бути понесені.

Картер Фельдман сказав, що він визнає, що це може бути трохи дорого, але пояснює, що доказ Меркель в основному використовується в його проекті для створення надійного скрипта блокування або прив’язкової системи як частини другого рівня zk на Bitcoin. Ця система має на меті довести, що певна кількість біткойнів може бути виведена на певну адресу, враховуючи корінь дерева виведення коштів (як публічний вхід для доказу з нульовим розголошенням).

Говорячи про витрати, він зазначив, що це буде крайнім заходом. Він передбачає, що звичайні користувачі можуть купувати загорнуті BTC на другому рівні, попросивши продавця загорнутих BTC заблокувати свій токен на L2 на певний період часу, протягом якого покупець повинен довести, що він заплатив продавцю за Bitcoin L1. Вони знають, що завжди можуть обміняти біткойн без довіри, якщо захочуть. У той же час, кілька великих постачальників ліквідності стануть організаціями, які фактично обмінюються між wBTC і BTC і можуть стягувати невеликі комісії з менших користувачів, які хочуть купити у них wBTC або перевести їх назад у Bitcoin.

Таким чином, в цілому, пропозиція BIP від OP_CAT може допомогти побудувати смарт-контракти на Bitcoin всього з 13 рядками коду, але все одно буде багато обговорень і пробних рішень для конкретних деталей кожного проекту.

Меметична культура нарощує оберти та розвиває технології

Член команди TaprootWizards Рейндаель (@rot 13 максі) звернувся до соціальних мереж, щоб поділитися різними складними механіками, які вони використовують для створення творів мистецтва. Щоб досягти цього, вони покладаються на різноманітні методи, включаючи порядкову рекурсію, попередньо підписані транзакції, симетричну криптографію та управління навантаженням на стороні клієнта. У процесі створення мистецтва вони спеціально вирішили використовувати попередньо підписані транзакції для виконання операцій, показуючи, як попередньо надіслати хеш транзакції за допомогою смарт-контракту, такого як OP_CAT або CTV.

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

OP_CAT вважається простим і зрозумілим кодом операції, і стверджується, що він може зробити Біткойн “квантово безпечним”, підписавши підписи ECDSA. Ця ідея була підтримана деякими і надихнула Taproot Wizard запустити кампанію Quantum Cats Non-fungible Token для підвищення обізнаності про OP_CAT.

Однак не тільки OP_CAT використовує меметичну культуру для створення імпульсу для технологічного прогресу.

Натхненна Quantum Cats та його відпускною ціною 0,1 BTC і, можливо, частково незадоволена високою ціною продажу, спільнота OP_CTV також запустила сендвіч-мем під назвою #rubinsreubens для просування технології OP_CTV.

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

Цей сендвіч-мем привернув увагу багатьох людей. Меми смішні і можуть бути використані, щоб висловити підтримку чомусь, але також важливо розуміти сенс, що стоїть за цим. Метою #rubinsreubens є покращення розуміння пропозицій OP_ctv, LNHANCE та Soft Fork для нового BTC Операційного коду та активації смарт-контракту.

Потенційні причини збоїв OP_CAT

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

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

На додаток до міркувань безпеки та ризику, двома основними причинами, чому OP_CAT зазнає невдачі, є: страх перед смарт-контрактом у біткойн-спільноті та відсутність «легітимності» у смарт-контракті Bitcoin.

Страх перед смарт-контрактами

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

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

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

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

Чи був Сатоші Накамото “неправий”?

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

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

Тому пропозиція відновити OP_CAT зачіпає і більш широке питання: чи повинен біткоіни бути статичним об’єктом, або він повинен підлаштовуватися під мінливе технологічне середовище і потреби користувачів?

Однак технічна сфера завжди прогресує і змінюється, і біткоіни, як технологічне нововведення, не може повністю позбутися від цього закону, і судячи з усього, так вважає команда Taproot Wizard, яка підтримує відновлення OP_CAT. Зрештою, вони навмисно розробили найбільший BitcoinBlock за всю історію, трохи нижче ліміту Bitcoin 4 МБ, щоб випустити невзаємозамінні токени Taproot Wizards.

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

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

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

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