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

«Природа Біткойн така, що після випуску версії 0.1 дизайн ядра був викарбуваний на камені до кінця свого життя. Через це я хотів розробити його таким чином, щоб підтримка всі можливі типи транзакцій, які тільки міг придумати. Проблема полягала в тому, що кожна річ вимагала спеціальних підтримка коду та полів даних, незалежно від того, використовувалася вона чи ні, і охоплювала лише один окремий випадок за раз. Це був би вибух особливих випадків. Рішенням став скрипт, який узагальнює проблему, щоб сторони, що здійснюють транзакції, могли описати свою транзакцію як предикат, який оцінює мережа вузлів." - Сатоші, 17 червня 2010 р.

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

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

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

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

ВЕЛИКА РЕСТАВРАЦІЯ СКРИПТУ

На Біткойн++ в Остіні на початку травня розробник Core Lightning Расті Рассел зробив досить радикальну пропозицію під час першої презентації конференції. По суті, він висунув ідею повернути більшість кодів операцій, які Сатоші відключені в 2010 році до його зникнення.

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

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

ANYPREVOUT (APO), пропозиція дозволити повторно використовувати підписи в різних транзакціях, лонг також сценарій і обсяг вхідних даних були однаковими, була розроблена спеціально для оптимізації Lightning і багатосторонніх версій. CHECKTEMPLATEVERIFY (CTV), пропозиція про примусове використання монет може бути витрачена лише транзакцією, яка точно відповідає заздалегідь визначеній транзакції, була розроблена спеціально для того, щоб розширити функціональність ланцюжків попередньо підписаних транзакцій, зробивши їх повністю недовірливими. OP_VAULT був розроблений спеціально для того, щоб увімкнути «період очікування» для схем холодного зберігання, щоб користувач міг «скасувати» виведення з холодного сховища, відправивши його в ще більш холодну установку з мультипідписом, якщо його ключі були скомпрометовані.

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

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

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

КОДИ

ОПЕРАЦІЙ
• OP_CAT: Бере два фрагменти даних у стеку та додає їх разом, щоб сформувати один.
• OP_SUBSTR: Бере аргумент довжини в байтах і вихоплює фрагмент даних зі стека, видаляючи з нього стільки байтів і повертаючи їх назад.
• OP_LEFT & OP_RIGHT: приймає аргумент length і видаляє стільки байтів з одного чи іншого боку фрагмента даних у стеку.
• OP_INVERT & OP_AND & OP_OR & OP_XOR & OP_UPSHIFT & OP_DOWNSHIFT: Бере елемент даних зі стека і виконує над ним відповідну операцію bit.
• OP_2MUL & OP_2DIV & OP_MUL & OP_DIV & OP_MOD: Математичні оператори для операцій множення, ділення та за модулем (повертають залишок від ділення).

Ті, що вище, є кодами операцій, які потрібно відновити. На додаток до них, Расті пропонує ще три, щоб спростити композицію різних кодів операцій.

• OP_CTV (АБО TXHASH/еквівалент): Щось, що дозволяє здійснювати детальне правозастосування, вимагаючи, щоб певні частини транзакції були точно визначені заздалегідь.
• CSFS: Дозволяє перевіряти підписи за довільними даними, а не лише за всією транзакцією. Це дозволяє вимагати, щоб частини сценарію або дані, які вони використовують, були підписані ордер виконані.
• OP_TWEAKVERIFY: Перевіряє операції на основі Шнорра з публічними ключами, такі як додавання або віднімання окремих відкритих ключів від сукупних. Це може бути використано для того, щоб у випадку, якщо одна сторона вийшла зі спільної UTXO в односторонньому порядку, кошти всіх інших були відправлені на сукупний публічний ключ, який не вимагає від сторони, яка виїхала, входу ордер спільних витрат.

ЧОМУ МИ ХОЧЕМО ЦЕ ЗРОБИТИ

Шар 2 за своєю суттю є продовженням базового шару Біткойн, вони за своєю природою обмежені з точки зору функціональності функціональністю базового шару. Lightning вимагав трьох окремих софтфорків: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) і Segregated Witness, перш ніж його можна було фактично впровадити.

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

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

На перший погляд, саме такий функціонал нам потрібен:

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

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

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

ЯК ЗРОБИТИ ЦЕ БЕЗПЕЧНИМ: VAROPS

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

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

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

Зміна того, як Taproot обробляє ліміти sigops відносно кожної транзакції, пропонує спосіб узагальнити це, що і пропонує Rusty з лімітом varops. Ідея полягає в тому, щоб призначити вартість для кожного з повторно активованих кодів операцій, щоб врахувати рахунок найгіршому випадку, тобто найдорожчу обчислювальну вартість для перевірки, яку може створити кожен код операції. Таким чином, кожен з цих кодів операцій матиме свій власний ліміт «sigops», щоб обмежити кількість ресурсів, які він може споживати під час перевірки. Він також буде заснований на розмірі будь-якої транзакції з їх використанням, тому зберігайте простоту міркувань про це, але при цьому додавайте неявний глобальний ліміт на блок.

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

FORWARD MOMENTUM

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

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

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

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

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

1. Ця стаття передрукована з [bitcoinmagazine], Усі авторські права належать оригінальному автору [SHINOBI]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно впораються з цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.