Хоча обсяг пропозицій досить широкий, яким може бути причина того, що “Велике відновлення сценарію” Расти Раселла вважається передумовою розвитку Bitcoin?

Примітка блокуна єдинорога: Расті Рассел - активний розробник у спільноті Біткойн і користується великим повагою всередині неї. Він зробив помітний внесок у розробку ядра Linux і брав участь в різних проектах розробки Bitcoin Core.

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

“Природа Bitcoin така, що, як тільки була випущена версія 0.1, основний дизайн залишився незмінним на все життя. Тому я хотів розробити його так, щоб підтримувати кожен тип транзакції, який мені прийшов у голову, але в пізніших версіях ми видалили можливість запускати довільні скрипти. Проблема полягала в тому, що кожна функція потребувала спеціальних кодів підтримки та полів даних, незалежно від того, чи вони використовувалися, що призвело до занадто багатьох виняткових випадків. Рішенням був скрипт, який узагальнив проблему, так що транзакції можуть описувати свої умови специфічним для них способом, а мережеві вузли можуть оцінювати та перевіряти ці умови.” - Сатоші Накамото, 17 червня 2010 року

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

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

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

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

Відмінне відновлення сценарію

На конференції Bitcoin++ в Остіні на початку травня головний розробник мережі Lightning Rusty Russell вніс дуже радикальну пропозицію на своєму першому виступі на конференції, де він в основному запропонував знову увімкнути більшість опкодів, які були відключені Сатоші Накамото перед його зникненням у 2010 році.

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

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

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

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

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

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

ОПЕРАЦІЙНІ КОДИ (Operation Codes)

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

Крім вищезазначених опкодів для відновлення, Расти Рассел запропонував три додаткових опкоди, які призначені для спрощення поєднання різних опкодів:

OP_CTV (або TXHASH / еквівалентний опкод): Дозволяє деталізоване забезпечення певних частин транзакції, вимагаючи, щоб ці частини були точно відповідними передвизначеному вмісту.

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

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

Чому ми це робимо?

Мережі Layer2 по суті є розширенням основного рівня Bitcoin, і вони обмежені функціональністю основного рівня. Перед тим як мережу Lightning можна було впровадити, було потрібно три окремі м'які вилки: CHECKLOCKTIMEVERIFY (CLTV), CHECKSEQUENCEVERIFY (CSV) та Segregated Witness (SegWit).

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

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

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

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

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

Зміна відкритого ключа: Ми повинні забезпечити можливість перевірки змін до агрегованих відкритих ключів у стеку. У схемі спільного непотраченого вихідного операційного балансу (UTXO) нашою метою є сприяння співпраці та ефективному руху коштів через агрегований відкритий ключ, що містить всіх учасників. Коли хтось ухвалює одностороннє рішення щодо спільного UTXO, нам потрібно видалити їхній індивідуальний відкритий ключ з агрегованого відкритого ключа. Якщо всі можливі комбінації не були попередньо обчислені, то єдиний варіант - перевірити, чи віднімання відкритого ключа з агрегованого відкритого ключа приведе до створення дійсного відкритого ключа, складеного з решти індивідуальних відкритих ключів.

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

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

Зміна в Taproot щодо обмеження sigops (операцій підпису) для кожної транзакції відкриває можливість узагальненого підходу, який також є пропозицією, яку Расти Рассел запропонував щодо обмежень varops. Ідея полягає в тому, щоб виділяти вартість для кожного відновленого опкоду, щоб врахувати найгірший випадок, який кожен опкод може створити у термінах найбільших витрат на обчислення під час перевірки. Таким чином, кожен опкод матиме своє власне обмеження "sigops", обмежуючи кількість ресурсів, які він може використовувати під час перевірки. Це також буде базуватися на розмірі будь-яких транзакцій, які використовують ці опкоди, що робить його зручним для інференції, при цьому все ще накопичуючи до неявного глобального обмеження кожного блоку. Це вирішить атаки DOS (що призводять до краху мережі через відсилання великої кількості непотрібних запитів), що було також причиною, чому Сатоші Накамото спочатку вимкнув усі ці опкоди.

Рушійна сила вперед

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

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

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

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

Заява:

1. Ця стаття спочатку мала назву «Відновлення великого сценарію: шлях вперед Bitcoin» і відтворена з [ Блок єдинорог]. Усі авторські права належать оригінальному автору [SHINOBI]. Якщо у вас є які-небудь зауваження до перепублікації, будь ласка, зв'яжіться з Ворота Навчаннякоманда, команда якнайшвидше займеться цим.

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

3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіат перекладених статей заборонені.