Інтерв'ю з Polyd: кроляча нора ковенантів

Інтерв'юер: Амелі Хуа, письменниця-фрілансер, незалежна дослідниця. Х: @AmelieHua

Співрозмовник: Polyd, спеціаліст із систем управління, обслуговує кілька розподілених систем управління (DCS), працював з іншими системами (час безвідмовної роботи 99,999%). Х: @Polyd_

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

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

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

1.

Амелі: Перш ніж перейти до ковенантів, прояснімо два питання, пов'язані з Біткоїном, що допоможе нам краще зрозуміти ковенанти.

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

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

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

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

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

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

Амелі: Чому існують жорсткі обмеження для кодів операцій? Можна використати OP_CAT як приклад, щоб прояснити цей момент?

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

Ось короткий список того, що може виконувати OP_CAT: ковенанти CTV/TXHASH, перевірка доказів SPV, захист від подвійного витрачання TX 0-conf, 64-бітова арифметика, сховища, квантово-стійкі підписи. Цей список можна продовжити: тільки OP_CAT може емулювати транзакції у стилі CTV[CheckTemplateVerify] та TXHASH. Єдина проблема полягає в тому, що він вкрай неефективний у тому, як він виконує ці дії, а це може призвести до непопулярності цих транзакцій, за винятком великих користувачів, таких як зберігачі.

2.

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

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

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

Насправді я не такий великий шанувальник того, як працює Ethereum. Через його обчислювальний характер і вбудовану верифікацію, якщо я спробую здійснити торгівлю, моє вікно може зміститися, і в мене не вийде торгувати. Однак моя транзакція для спроби торгівлі все ще буде дійсною, тому мені все одно доведеться заплатити комісію, витрачаючи блоковий простір для когось іншого. Ще один дивний аспект – оракули у Ethereum. Оракули повинні платити газ, щоб оновити ціни, тоді як у Біткоїн-DLC оракул просто надає підпис і не може бути «закріплений» через зміну комісій, а також не може бути націлений на конкретні контракти.

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

3.

Амелі: Тепер поговоримо про ковенанти. Що це таке?

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

Усередині Біткоїна вже є два ковенанти, і вони підтримують мережу Lightning Network: CSV [CheckSequenceVerify] та CLTV [CheckLockTimeVerify]. Деякі просто називають ці коди операцій «примітивами смарт-контрактів», оскільки вони є простими блокуваннями за часом.

CTV [CheckTemplateVerify] – це запропоноване оновлення Біткоїна, включене до BIP 119. Воно відрізняється від CSV та CLTV. CTV можна описати як блокування TXID [Transaction ID] або блокування UTXO, тільки ці TXID можуть бути створені з цього блокування. Для CTV ми називаємо це блокування TXID «угодами про рівність», оскільки кінцеві транзакції повинні відповідати вихідним транзакціям, які були зафіксовані. Це також називають угодою про відстрочку зобов'язань, оскільки ви можете бачити, що ваш UTXO був прийнятий, але ще не розміщений у ланцюжку.

Найбільш відомою альтернативою є SH_APO [будь-який попередній вихід або AnyPrevOut], який забезпечує зобов'язання з виплати, одночасно дозволяючи гнучкі методи внесення. Обговорюються також кілька інших: OP_CCV [також відомий як MATT], OP_EXPIRE, TXHASH та TEMPLATE KEY.

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

Polyd: Так, вони фактично передбачають розподіл UTXO певним чином: як тільки ви приймете на себе зобов'язання, ви не зможете від нього відмовитися, тепер UTXO прив'язаний до консенсусу, і тільки його новий власник може вирішити, як витратити свої кошти.

Коли UTXO створюється ончейн, ми інстинктивно припускаємо, що цей UTXO зберігається за допомогою одного закритого ключа. Але якщо це був UTXO, прив'язаний до CTV, коли UTXO буде витрачений, ви побачите додатковий 32-байтовий хеш у поєднанні з новою транзакцією, який представляє прихований стан усередині вихідного UTXO.

Амелі: Ви кілька разів згадали «блокування TXID/блокування UTXO». Чи можна це сформулювати так: щоб розуміти, як CTV реалізує свою функціональність, потрібно розуміти, що таке блокування TXID і як воно працює. Блокування TXID є ключовим механізмом.

Polyd: Так, це створює міцну основу для побудови подальших схем. TXID визначається вмістом tx. І якщо можна додавати вхідні дані до tx, TXID можна маніпулювати. CTV дозволяє заблокувати кількість входів та виходів. Таким чином забезпечується відсутність довіри для зобов'язання CTV. Якби TXID був податливим, можна було б вкрасти чиїсь кошти. Маючи механізм блокування TXID, можна поєднати його з іншими механізмами блокування, такими як блокування за часом, для створення ще ефективніших смарт-контрактів.

4.

Амелі: Чому ви вважаєте, що ковенанти – це кроляча нора?

Polyd: Я називаю ковенанти кролячою норою, тому що за допомогою простих обмежень на транзакції, таких як блокування за часом або блокування TXID, можна зробити дуже багато. Нам вдалося побудувати всю мережу Lightning за допомогою простих блокувань за часом, і хоча вона не ідеальна, це єдина справді децентралізована мережа другого рівня. Мені не подобається, як усе поступово зміщується у бік кастодіального контролю, але саме тому я і почав спуск у цю кролячу нору: щоб зробити смарт-контракти потужнішими. Ми називаємо блокування TXID шаблоном. З Taproot ми отримали можливість агрегувати підписи. Завдяки шаблонам та CTV ми отримуємо можливість агрегування транзакцій.

CTV слугує заміною попередньо підписаного оракула транзакцій, що усуває вимоги довіри та інтерактивності, необхідні для створення складніших смарт-контрактів, необхідних для таких речей, як сховища та платіжні пули. Сховища та пули, які ви можете створити за допомогою CTV, сьогодні технічно можливі, але наразі вони виключені через довіру чи інтерактивність, необхідну для їхньої роботи. Щобільше, за допомогою CTV можна створювати фабрики каналів, додаткові рішення другого рівня, такі як Ark, Timeout-Trees, Stakechains або Surfchains, а також рішення JIT Fidelity Bond, такі як PathCoin.

Мабуть, моя улюблена функція – це неінтерактивні канали [NIC], які ми також називаємо холодними каналами. Основна ідея полягає в тому, щоби взяти звичайний канал Lightning і просто помістити його в шаблон CTV. Що відрізняє його від звичайного каналу Lightning, це те, що жодній зі сторін насправді не потрібно бути в мережі для створення цього каналу. Тому, якщо мені потрібний канал з іншою людиною, не потрібно, щоб вона була онлайн, щоб створити канал; мені навіть не треба говорити, що я це зробив, поки я не готовий витратити з нього гроші! Це дозволяє використовувати можливість холодного зберігання на Lightning Network, оскільки мені не потрібний вузол для захисту моїх коштів у каналах, які ще не активні. Сторонні координатори можуть встановити неінтерактивні канали для двох осіб, що забезпечує більшу гнучкість у можливостях.

У нинішньому вигляді CTV не дозволить створити DEX ончейн, але я не думаю, що це так погано, оскільки люди зараз намагаються створити DEX офчейн, використовуючи Lightning Network. Я думаю, що це пов'язано з дискусією «Верифікація чи обчислення». Єдине, що мене турбує щодо ончейн DEX, окрім надмірних оновлень у мережі, що призводять до вищих комісій, – це MEV (цінність, отримувана майнерами). Ми вже помітили деяку MEV від транзакцій DEX BCH, і з розвитком ринку ситуація обов'язково погіршиться.

Амелі: Чи можете ви навести приклад, який допоможе нам зрозуміти, як працює CTV?

Polyd: Припустимо, я маю отримати 5 BTC, і на цей час єдине, що я можу зробити, це отримати платіж і перевірити його в мережі. За допомогою CTV я можу звести все до простого публічного ключа, який я даю платнику. Деталі залишаються конфіденційними для всіх, крім мене. Як тільки я зможу підтвердити, що мені заплатили, всі дії, які я зробив з використанням шаблону CTV, також набувають чинності.

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

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

5.

Амелі: Як згадувалося раніше, можна використовувати різні коди операцій для реалізації ковенантів.

Polyd: Якщо ми використовуватимемо OP_CAT, думаю, це дозволить реалізувати практично всі можливі типи угод, оскільки можна буде емулювати будь-яку форму інтроспекції для TXHASH. Більш обмеженим методом було б введення кодів операцій, які представляють явну поведінку, як у випадку з CTV, CSFS або CheckSeperateSignature. CTV – це можливість робити відкладені виходи. CSFS – це можливість робити відкладені підписи, щоб ви могли відкласти платіж. Вони звучать схоже і добре працюють разом як будівельні блоки для забезпечення LN-симетріїї, але зобов'язання виконуються на різних рівнях.

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

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

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

Багато розробників стежать лише за Lightning та її розвитком. Вони схильні надавати перевагу таким кодам операцій, як SH_APO, оскільки він забезпечує LN-симетрію. Багато розробників, яким не особливо подобається Lightning через її обмеження, такі як обмеження вхідної ліквідності або вимоги бути онлайн, віддають перевагу таким кодам операцій, як OP_CAT, TXHASH, як більш виразним рішенням масштабування. Розробники, які віддають перевагу CTV, є більш нейтральними та дивляться на це з системного погляду. Це значно розширює можливості кожного робити те, що він вважає за краще, не створюючи при цьому ризиків.

6.

Амелі: Перед обговоренням ковенантів ми згадували про проблеми, пов'язані з кодами операцій у мові сценаріїв, та проблему обмежених обчислень, які призводять до зміни станів. Ми вже знаємо про взаємозв'язок між ковенантами та кодами операцій. Тепер заглибмося у проблему переходу станів. Я не впевнена, що розглядати ковенанти з погляду «переходу станів» правильно, але ця перспектива справді цікава.

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

Polyd: Ковенант – це шаблонна оболонка чи «стан». Всередині нього вам потрібно буде створити блокування за часом та інші функції, щоб забезпечити бажану функціональність, хай то сховище, канал Lightning або будь-яке інше рішення другого рівня.

Таким чином, CTV дозволяє створити стан, але необхідно динамічно перебудовувати стан під час кожного переходу, щоб підтримувати його в гомеостазі, що ми називаємо метарекурсивним. В той час, як SH_APO дозволяє створити стан, а потім періодично оновлювати його, роблячи його рекурсивним. CTV також може створити ланцюжок транзакцій, який дозволить вам «перейти» через цей стан.

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

Амелі: Чи можна сказати, що ковенанти реалізують форму смарт-контракту, засновану на верифікації, а не на обчисленнях?

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

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

Polyd: Здається, ми пройшли повне коло до того, чого хочуть від блокчейну. Але схоже, що Біткоїн все ще має деякі проблеми з модульністю і розміром. Мені хотілося б, щоб були кращі сайдчейни, які були б не просто рішеннями з кількома підписами, а використовували б справжні криптографічні інструменти для захисту коштів та дозволяли б односторонні виходи. Я думаю, що це допоможе розширити межі модульності Біткоїна. Taproot дозволив проводити ще більше обчислень поза ланцюжком за допомогою таких рішень, як BitVM, що дозволило б нам обчислювати практично все, що завгодно поза ланцюжком. Але, на жаль, він не може емулювати такі речі всередині Біткоїна, як CTV, тому, схоже, нам ще є куди розвиватися.

7.

Амелі: Яких можливостей можна досягти шляхом об'єднання ковенантів з іншими кодами операцій, такими як DLC?

Polyd: З DLC є кілька проблем, які можна було б вирішити за допомогою ковенантів, такі як підвищення гнучкості параметрів DLC шляхом створення безлічі цінових позицій [якщо ми робимо ставку на ціну чогось, наприклад, біткоїн]. Інша причина полягає в тому, що апаратні гаманці не можуть взаємодіяти з багатьма DLC; раунди підписання для DLC та спроби зробити це з апаратними гаманцями призводять до того, що відкриття DLC займає кілька хвилин. За допомогою CTV цю затримку входу DLC можна скоротити до секунд.

8.

Амелі: Чи ще є якісь моменти, про які ви хотіли б розповісти читачам?

Polyd: Ми розглянули безліч концепцій. Ми торкнулися питання, як можна пом'якшити надмірний попит на блоковий простір та потенційні DDoS-атаки. Ми обговорили, як можна заощаджувати простір, створюючи неінтерактивні канали. Я думаю, що ще одна хороша тема для обговорення – це «проблема виходу з другого рівня». Якби нам вдалося вивести всіх із базового рівня та перемістити їх на великий другий рівень, нині немає хорошого способу прискорити виведення людей із цього другого рівня. Як другий рівень можна розглядати Lightning [ми називаємо потенційний масовий вхід з Lightning «проблемою громового стада»] або Coinbase, Binance або Liquid. На Coinbase мільйони людей, і я гадки не маю, як вивести їх звідти на Біткоїн якимось упорядкованим чином у сьогоднішніх умовах. Спроба вивести людей із біржі призведе до затримки у мемпулі на 6 місяців. CTV може це виправити.

Можна створити Ark або дерево тайм-аутів за допомогою CTV. Біржа могла навіть пропонувати цю послугу напряму. Кожен міг би перейти із «загального UTXO» відповідно до консенсусу Coinbase на «загальний UTXO» з консенсусом на свій вибір, хай то простий пул або велике дерево тайм-аутів. Ось тут зовсім мозок плавиться, це був би чистий перехід L2L2. Не було б жодного проміжного кроку, який вимагав би спочатку спуститись на базовий рівень. І цей процес можна повторювати нескінченно, використовуючи будь-який рівень на свій вибір. Нема потреби повертатися на базовий рівень, окрім, наприклад, через відмову від співпраці з моїм каналом або, можливо, вихід з мого сховища. Недолік Ark і дерева тайм-аутів полягає в тому, що вони мають вимоги до перенесення коштів: вам доведеться переміщати свої кошти кожні кілька тижнів або місяців, інакше ви їх втратите. Це не ідеальне рішення для довгострокового зберігання, але воно чудово працює для короткострокового зберігання та більших ринків.

Я хотів би навести повний список усіх концепцій, які були розроблені з використанням опкоду CTV та його здатності агрегувати попередньо підписані транзакції: Non-Interactive Channels, Timeout-Trees, Ark, Darkpools, Payment Pools, Payment Channels, Ball Lightning, Congestion Control, Dpool's, Compaction, Tree Swaps, PathCoin, Stakechains, Surfchains. Це не незалежні шаблони: якщо один з них має функцію, яку ви хочете включити в інший шаблон, ви можете створити свій власний шаблон.

Це гостьовий пост Амелі Хуа. Висловлені погляди є її власними і не обов’язково збігаються з точкою зору BTC Inc. або Bitcoin Magazine.