On-chain гаманці досягають приблизно 1-1 відповідності транзакцій до транзакцій: для кожної економічної транзакції, яку виконує користувач, потрібна приблизно одна транзакція блокчейну. Агрегації, coinjoin, cut-through-payments і т. Д. Змінюють цей вислів трохи. Але це приблизно правильно.

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

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

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

Дякую йде доFulgur Venturesза спонсорство цього дослідження. Вони не мали редакційного контролю над змістом цього повідомлення та не переглядали його перед публікацією.

Також дякуютьDaniela Brozzoni, Сара Кокс, та інші для попереднього перегляду перед публікацією.

Визначення

Що таке Рівень 2?

Часто термін «Рівень 2» визначається широко, до такої міри, що навіть банківська організація (наприклад, ліквідна) може бути визначена як рівень 2. Для цілей цієї статті ми приймемо суворе визначення: рівень 2 (L2) - це система, деномінована в біткойнах, з метою дозволити транзакціям BTC частіше, ніж кількість ончейн-транзакцій з іншими сторонами. Такі, що:

1. Ніхто не може прибутково вкрасти кошти в системі, враховуючи внутрішні покарання та витрати. Зовнішні витрати та покарання, такі як втрата репутації, юридичні наслідки тощо, не враховуються в нашому визначенні.
2. (Перевага) Справжні власники коштів можуть односторонньо зняти свої кошти, мінус витрати на транзакції, без співпраці з будь-якими третіми сторонами.

Перша опція обов'язкова, оскільки ми хочемо, щоб наші системи L2 могли представляти суми та транзакції такої малої вартості, що їх неможливо представити on-chain. Наприклад, в Lightning HTLC можуть мати занадто малу вартість для представлення on-chain. У такому випадку значення HTLC додається до комісії транзакції зобов'язання. Хоча вузол Lightning може "вкрасти" пиловий HTLC, закривши канал у потрібний момент, така дія є дорожчою¹ніж HTLC варті, зробивши крадіжку невигідною.

Це сказано, що одностороннє виведення завжди є нашою основною ціллю дизайну.²

За цим визначенням речі, як Lightning, вважаються системами L2. Однак системи, такі як Liquid, Cashu та Fedimint, не є L2, оскільки інша сторона або сторони контролюють ваші кошти. Схеми перевірки на боці клієнта, такі як RGB, також не є L2 за цим визначенням, оскільки вони не можуть здійснювати безпечні транзакції з BTC самостійно. Нарешті, @RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39">Statechains не проходить випробування, оскільки сутність Statechain може вкрасти кошти, якщо вони не дотримуються протоколу.

Що таке Ковенанти?

...і чому потрібні більш масштабовані системи Рівня 2?

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

Рекурсивні договори

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

Цілі

Lightning — це поточна «найкраща у своєму класі» система рівня 2. Однак він має обмеження. Саме:

1. Масштабування - Lightning наразі вимагає принаймні одного UTXO на кінцевого користувача.³
2. Ліквідність - Lightning вимагає зв'язування коштів в каналах.
3. Інтерактивність - Lightning вимагає, щоб отримувачі платежів були онлайн, щоб отримувати їх безпечно.

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

Обмеження масштабування Lightning

Що означає "один UTXO на кінцевого користувача" на практиці? Оскільки канали Lightning можуть працювати нескінченно, один зі способів розглядати це - запитати, скільки нових каналів можна створити щороку⁴. Створення виведення taproot має маргінальну вартість 43vB; якщо створення каналу амортизується, з багатьма каналами, створеними в одній транзакції, інші накладні витрати транзакції можуть бути знехтувані, і велика кількість каналів може бути відкрита щорічно для включення нових користувачів. Наприклад, припустимо, що 90% пропускної здатності блоку було використано для відкриття нових каналів Lightning taproot:

Оцінюється, що близько половини світового населення володіють смартфоном, 4,3 мільярда людей. Таким чином, ми фактично можемо залучити значну частку всієї населення, яке, ймовірно, зможе скористатися каналом Lightning на рік.

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

Якщо канал відкривається, сполучення також може бути виконано амортизованим способом для покращення ефективності, з декількома операціями сполучення, які використовують одну транзакцію для зменшення кількості входів та виходів, необхідних для додавання та вилучення коштів.⁵. Таким чином, дельта-простір блоку, необхідний для зрощування користувачів, припускаючи використання Музика, — це вихід стрижня 43 В Б плюс

57,5 vB витрачати шлях taproot keypath, загалом 100,5 vB. Якщо ми знову припустимо 90% використання блокового простору, то отримаємо:

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

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

Огляд рівня 2

За нашим визначенням систем L2, у біткойн-спільноті розглядаються два основні шаблони проектування:

1. Канали
2. Віртуальні UTXOs

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

У шаблоні проектування Virtual UTXO (V-UTXO), найяскравішим прикладом якого є Ark, V-UTXO створюються за допомогою ковенантів або багатосторонньої угоди, шляхом створення транзакцій, які можуть бути видобуті для одностороннього виведення коштів V-UTXO шляхом розміщення їх у мережі, але не перебувають на «щасливому шляху». У цьому відношенні V-UTXO схожі на канали. Але на відміну від каналів, схеми V-UTXO здійснюють транзакції, витрачаючи самі V-UTXO (концептуально) в одному⁶попередньо підписана транзакція.

Шаблон проектування “щасливий шлях” полягає в використанні шляху сценарію “усі сторони згодні”, такого як N-of-N multisig; taproot розроблено спеціально для цього концепту, дозволяючи ключовому шляху бути N-of-N multisig через musig. Припускаючи, що всі сторони згодні, щасливий шлях дозволяє ефективно (та приватно) витрачати гроші.

Цікаво, оскільки віртуальні UTXO є "реальними" в багатьох відношеннях, досить легко побудувати канали на основі віртуальних UTXO, просто створюючи віртуальні UTXO, які, у разі витягування, призведуть до створення необхідних UTXO для каналів. У цьому відношенні схеми віртуальних UTXO є

трохи нижчий шар, ніж канали.

Блискавка

Становище, реалізоване в промисловості як Мережа Lightning, переважно базується на стандарти BOLTs. Lightning - це поєднання кількох речей, включаючи канали Lightning та HTLC, P2P-маршрутизаційну мережу, цибульне маршрутизування, стандарти рахунків тощо. Зокрема, Lightning не є системою консенсусу, тому різні елементи «системи Lightning» не обов'язково приймаються всіма користувачами однаковим чином. У цій статті, коли ми кажемо «Lightning», ми використовуємо його в широкому розумінні, включаючи легко передбачувані оновлення поточного (типового) протоколу(ів) Lightning, які широко використовуються.

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

Неінтерактивні канали

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

Фабрики каналів

Тут ми маємо декілька сторін, які узгоджують один n-of-n multisig адресу, разом з транзакцією, яка витрачає цю адресу, щоб створити n різних UTXO, розбиваючи кошти. Ці UTXO в свою чергу використовуються для платіжних каналів. Канали можуть використовуватися з такою ж безпекою, якщо б вони були відкриті безпосередньо на ланцюжку, тому що в разі, якщо потрібно буде виставити стан каналу на ланцюжок, розділена транзакція може бути видобута. Це потенційно зберігає місце на ланцюжку, коли канали закриваються, оскільки n сторони можуть спільно закрити всі nn канали одночасно.

Оскільки фабрики каналів узгоджують UTXO, які можуть бути видобуті, але не очікуються насправді видобуті в щасливому сценарії, вони є дуже примітивним прикладом V-UTXO.

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

Eltoo/LN-Симетрія

Оскільки Eltoo - це дуже заплутана назва, ми будемо використовувати оновлену назву LN-Symmetry в майбутньому.

У той час як канали Poon-Dryja заохочують публікацію правильного стану в мережі, караючи за неправильні стани, LN-симетрія натомість дозволяє оновлювати неправильні стани додатковою транзакцією. Перевага цього полягає у спрощенні каналів Lightning, усуваючи складність штрафів. Однак це, ймовірно, буде недоліком у ненадійних сценаріях, оскільки, можливо, потрібні штрафи, щоб запобігти шахрайству.

LN-Symmetry потребує софт-форку, щоб увімкнути SIGHASH_ANYPREVOUT, який потрібний для того, щоб дозволити державним транзакціям повторно витрачати інші державні транзакції під час оновлень.

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

Арк

Ark використовує новий підхід до масштабування транзакцій: повністю передавані віртуальні UTXO (V-UTXO), які можна об'єднувати та розділяти в атомарні⁷ офчейн-транзакції. У Ark центральний координатор, постачальник послуг Ark (ASP), надає V-UTXO для користувачів із визначеним терміном дії, наприклад, 4 тижні. Ці періоди називаються раундами. Ці V-UTXO створюються за допомогою пулу txouts, по одному на раунд, за допомогою певного механізму, такого як CTV, щоб дозволити одному ончейн-txout зафіксувати в дереві V-UTXO. Експірація раунду — це спосіб, за допомогою якого Ark досягає переваги масштабування: наприкінці раунду розблоковується пул txout, що дозволяє ASP в односторонньому порядку витратити його з одним підписом у невеликій транзакції. У зв'язку з часом закінчення раунду, термін дії V-UTXO закінчується, коли закінчується термін дії txouts пулу, що їх створює: користувачі, які володіють V-UTXO, повинні або витратити цей V-UTXO до того, як закінчиться термін дії txout пулу, або перевести його в ланцюг (одностороннє виведення).

Для здійснення транзакцій між сторонами координатор Ark підписує транзакції, які витрачають один або кілька V-UTXO, так що транзакції є дійсними лише у випадку, якщо в іншому раунді створюються один або кілька інших V-UTXO. В поєднанні з деякими обережними таймаутами — див. документи Ark для повних деталей — ця залежність є тим, що робить витрату V-UTXO недовіреною: V-UTXO не можуть бути вимагані на ланцюгу, якщо не створюються нові V-UTXO у різній транзакції пулу. Є кілька потенційних способів фактичної реалізації цієї залежності. Але точні деталі не мають відношення до мети цієї статті.

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

Арк Економіка

Коли V-UTXO витрачається, ASP повинен надати відповідні BTC у новому пулі txout, що представляє новий раунд. Але вони не можуть повернути вартість витраченого V-UTXO до закінчення раунду. Таким чином, економіка витрат V-UTXO має вартість грошей у часі, що пов'язано з ліквідністю, яку має забезпечувати ASP.

Зокрема, витрати сплачуються, коли витрачається V-UTXO. Хоча V-UTXO не витрачений, він являє собою цілком реальний потенційний UTXO, який можна розмістити в мережі для одностороннього зняття коштів; Користувач володіє цими коштами. Однак, щоб витратити V-UTXO, ASP повинен створити новий пул txout, використовуючи кошти, отримані ASP в іншому місці, тоді як кошти у витраченому V-UTXO недоступні для ASP до закінчення терміну дії.

Таким чином, витрати на витрату V-UTXO потребують короткострокового кредиту, позика коштів для покриття інтервалу часу між зараз і закінченням раунду. Це означає, що вартість ліквідності для витрати V-UTXO фактично зменшується зі старінням V-UTXO та наближенням часу закінчення, врешті-решт, в теорії - досягає нуля, коли раунд остаточно закінчується.

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

Яка вартість ліквідності? На момент написання гаманець Lightning Phoenix збирає комісію в розмірі 1% для резервування ліквідності каналу на 1 рік; в найгіршому випадку Phoenix мусів би заморозити свої кошти на 1 рік. Однак це передбачає, що ліквідність не використовується. Дуже можливо, що вартість капіталу для Phoenix фактично вища, і вони припускають, що середній клієнт використовує їх вхідну ліквідність менше, ніж за один рік. Крім того, Phoenix заробляє гроші на комісіях за транзакції, що потенційно субсидує ліквідність каналу. Нарешті, Phoenix може не бути прибутковим!

Ставка білетів Скарбниці США дає нам ще одну оцінку. На момент написання ставка на 3 місяці Скарбничих білетів становить приблизно 5% на рік. Оскільки є аргумент, що ця ставка завищена через те, що долари США є інфляційними, ми припускаємо, що вартість ліквідності для фондів, що деномінуються в BTC, становить 3% на рік для нашого аналізу.

Якщо інтервал раунду становить 4 тижні, це означає, що транзакція починається з вартості ліквідності

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

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

Що, якщо фіксовані витрати не такі незначні? Припустимо, що ASP має 1000 користувачів, і операції з виведення коштів з басейну створюються в середньому один раз на годину. Протягом 4-х тижнів це 672 транзакції на ланцюжку. Це означає, що для простого утримання своїх коштів користувачі ASP зазначено майже стільки ж транзакцій, скільки і користувачі! Ймовірно, для них було б дешевше відкрити власні канали Lightning, навіть якщо ASP вимагає від них чекати цілу годину на підтвердження.

Завантажувальний ковчег

Новий ASP з невеликою кількістю користувачів стикається з дилемою: або ASP раунди відбуваються рідко, і користувачам доводиться довго чекати, поки запропонований раунд зібере достатньо V-UTXO для досягнення ефективного масштабування та зниження комісії за транзакцію. Або басейн транзакцій ASP відбуваються часто з високими комісіями за транзакцію, які сплачуються кожним користувачем. Як ми показали у попередньому розділі, може знадобитися багато користувачів для амортизації частих раундів та їх основних txouts басейну.

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

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

Інтерактивність

Некастодіальний Ark - це високоінтерактивний протокол: оскільки ваші V-UTXO закінчуються, у вас є жорсткі терміни для взаємодії з вашим ASP, інакше ASP може вирішити забрати ваші кошти. Цю взаємодію також не можна передати іншим: хоча Lightning маєвежі спостереженнящо зневажає контрагентів спробувати обдурити вас — навіть якщо ваш канал не був в мережі — власники монети Ark повинні використовувати свої власні приватні ключі для оновлення коштів без довіри. Найближче, що можливо в Ark до ваучерів, це підписувати транзакції, дозволяючи ваучеру односторонньо зняти ваші кошти на ланцюжок до часу закінчення, що має значні витрати на комісію за транзакцію.

Розгляньте, що трапляється з V-UTXO, якщо власник виходить з лінії: після закінчення раунду АСП має відновити кошти, щоб отримати свою ліквідність для подальших раундів. Якщо власник V-UTXO виходить з лінії, розміщення цього V-UTXO на ланцюжку має значні транзакційні витрати, так як АСП тепер має відновлювати кошти на кількох рівнях дерева V-UTXO. АСП може відновити невикористані V-UTXO в новому раунді. Але це не є довірчим з точки зору власників V-UTXO, оскільки вони не можуть витратити ці V-UTXO без отримання даних.⁹ від АСП. ASP також може просто записувати невитрачені V-UTXO як кастодіальний баланс. А може, навіть провести політику арешту коштів!

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

Розширений Арк

Можливо, зменшення вимог до ліквідності Ark через більш розвинені умови, якщо звичайно ліквідність вичерпується посередині раунду. Наприклад, давайте припустимо, що 50% загальної вартості V-UTXO в pool txout було витрачено. Якщо ASP може викупити саме цю частину pool txout раунду, вони можуть швидше відновити ліквідність, зменшуючи загальні витрати на ліквідність. Хоча конкретних пропозицій щодо того, як це зробити, не було опубліковано, здається, що це повинно бути можливо за допомогою Sufficiently Advanced™ умов. Ймовірно, через якийсь вид м'якого форку скриптового оновлення, який одночасно додає багато корисних опкодів.

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

Проблема зберігання кінцевої опіки в кінці раунду - це ще один випадок, коли достатньо розвинуті™ альянси можуть вирішити проблему: альянс, зокрема, доказ знання ЗК, може змусити ASP відтворити всі невитрачені V-UTXO в наступному раунді, усуваючи проблему опіки, яка повертається до них в кінці раунду. Хоча, ймовірно, це неможливо зробити довіреності, оскільки користувачім, ймовірно, знадобиться деяка інформація від ASP, щоб витратити свій V-UTXO на новому раунді, це може запобігти ASP від фінансового збагачення за рахунок шахрайства проти офлайн-користувачів.

Оплата комісії за ланцюгом при односторонньому знятті коштів

Аналогічно Lightning, економіка платежів за комісії на ланцюжку та фактична вартість V-UTXO після сплати комісій визначають, чи відповідає використання Ark нашому визначенню L2 через одностороннє вилучення або шахрайство, яке не приносить користь ASP. Ми розглянемо конкретику цього питання детальніше, коли будемо обговорювати зразок конструкції txout tree.

Зведення валапів валідності

Великий клас сайдчейн-подібних конструкцій, як правило, пропонується використовувати різні форми технології доведення з нульовим знанням (ZK) для забезпечення дотримання правил ланцюга. Технологія ZK-proof є критичною відмінністю між технологією валідності зведення та іншими формами сайдчейну: якщо схема ZK-proof працює, валідність транзакцій може бути гарантована математикою, а не довірою до третьої сторони. Аспект «нульового знання» доказу ZK насправді не є обов'язковою вимогою в цьому випадку використання: цілком нормально, якщо доказ «зливає» інформацію про те, що він доводить. Так склалося, що більшість математичних схем для цього класу доказів виявляються доведеннями з нульовим розголошенням.

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

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

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

BitVM

Дуже грубо кажучи, BitVM - це спосіб побудови блискавичного каналу між двома сторонами таким чином, що правила каналу Lightning дотримуються за допомогою доказу з нульовим знанням. Оскільки на сьогоднішній день на Bitcoin не потрібно реалізовувати договори, і через те, що він не може безпосередньо використовуватися для створення системи L2, яка масштабується понад обмеження користувача 1-UTXO, ми не будемо розглядати його далі.

Ієрархічні канали

Ієрархічні канали¹⁰має на меті зробити зміну розміру каналу швидкою і дешевою: "Іерархічні канали роблять для місткості каналу те, що LN робить для біткоїну". Однак вони все ще фундаментально не перевищують обмеження 1 UTXO-на-користувача. Вони також не потребують будь-яких змін в протоколі біткоїну в будь-якому випадку. Тому ми не будемо говорити про них далі. Прихильники просто повинні їх реалізувати! Вони не потребують нашої згоди.

CoinPool

CoinPool дозволяє кільком користувачам ділитися одним UTXO, переказувати кошти між різними користувачами та односторонньо знімати їх. Пропозиція з паперовим проектом CoinPool потребує трьох нових функцій м'яких вилок: SIGHASH_ANYPREVOUT, SIGHASH_GROUP, що дозволяє підпису застосовуватися лише до конкретних UTXO, і OP_MerkleSub для перевірки видалення конкретних гілок з дерева Меркла; останнє також можна зробити за допомогою OP_CAT.

На даний момент розробка CoinPool, здається, зупинилася, з останнім комітом на сайті специфікації було два роки тому.

Мережа Енігма

Хоча мене попросили розповісти про мережу Engima, здається, бракує документації щодо того, що насправді є цією пропозицією. Бітфінекс пост блогу пред'являє багато претензій; Об'єкт сторінка MIT порожня. Оскільки публікація в блозі насправді не дає зрозуміти, що саме має відбуватися, ми не будемо обговорювати це далі.

Врахування Mempool

Поточна політика пам'яті в Bitcoin Core не є ідеальною для систем L2. Тут ми розглянемо деякі з основних викликів, з якими вони стикаються, та потенційні покращення.

Фіксація транзакцій

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

Найпростішим прикладом закріплення є той факт, що без full-RBF заміну транзакцій можна відключити. Таким чином, ми можемо мати транзакцію з низькою комісією, з вимкненою заміною, яка не буде майнитися, але не може бути замінена. По суті, 100% хеш-потужності виправили цю проблему, увімкнувши full-RBF, і на момент написання статті full-RBF має бути ввімкнено за замовчуванням у наступному випуску Bitcoin Core (після 11 років зусиль!).

Це залишає BIP-125 Правило №3 підключення, єдину залишену проблему підключення, яка є відповідною для багатоутовних L2 протоколів та не виправлена в Bitcoin Core. Для посилання, Правило #3 BIP-125 містить наступне:

Для оплати вищої абсолютної комісії потрібна заміна транзакції (а не

just fee rate), ніж сума комісій, сплачених усіма транзакціями, що замінюються.

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

Правило №3 закріплення досить легко виправляється черезЗаміна за тарифною ставкою, і цей виправлення працює в усіх ситуаціях. Нажаль, невідомо, чи буде RBFR прийнято Core у найближчому майбутньому, оскільки вони витратили значну кількість зусиль на недосконале часткове рішення, Транзакції TRUC/V3.

Оплата внесків: RBF, CPFP, SIGHASH_ANYONECANPAY, якорі та спонсорство

Оскільки комісійні ставки непередбачувані, надійно і економічно виплачувати в ситуаціях, коли угоди попередньо підписані, складно. Золотий стандарт для оплати комісій полягає у використанні RBF, починаючи з початкової оцінки «низької кулі» та замінюючи транзакцію версіями з вищою комісією за потреби, доки вона не буде видобута. Наприклад, календарне програмне забезпечення OpenTimestamps використовувало RBF таким чином протягом багатьох років, а LND додав підтримку RBF з урахуванням терміну в v0.18.

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

Ефективність є важливою, оскільки неефективності у сплаті комісій роблятьоплата комісії поза каналом зв'язкуприбутковий джерело доходу для великих шахтарів; менші, децентралізовані шахтарі не можуть отримати прибуток від платежів поза межами через непрактичність та непотрібність оплати невеликому шахтарю за підтвердження транзакції. Платіж поза межами також здається запрошувати проблеми AML/KYC: наразі більшість систем оплати поза межами фактично доступні зараз вимагають якогось процесу AML/KYC для здійснення платежу, за винятком відомого винятку прискорювач mempool.space, який на момент написання (серпень 2024 року) приймає Lightning без облікового запису.

Щоб використовувати RBF безпосередньо в ситуаціях з попередньо підписаними транзакціями, вам потрібно попередньо підписати варіанти збору, що охоплюють повний спектр можливих зборів. Хоча це досить реально в багатьох випадках, оскільки кількість необхідних варіантів зазвичай невелика.¹², до цього часу протокол Lightning для виробництва — а також інші запропоновані протоколи — вибрали використання Дитина платить за батьків (CPFP), зазвичай за допомогою якірних виводів.

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

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

SIGHASH_ANYONECANPAY може використовуватися для оплати комісії у деяких випадках, дозволяючи додавати додаткові входи до підписаних транзакцій; SIGHASH_SINGLE також дозволяє додавати виходи. Lightning використовує це для транзакцій HTLC. На даний момент ця практика може бути вразливою до закріплення транзакцій, якщо з нею не обережно.¹³, оскільки зловмисник може додати велику кількість входів та/або виходів до транзакції, щоб створити високу комісію/низьку ставку комісії. RBFR виправляє цю проблему; підхід, використаний у транзакціях TRUC/V3, не може виправити цю проблему. Цей стиль оплати комісії не настільки ефективний, як RBF. Але він може бути ефективнішим, ніж якірні виходи.

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

Заміна велосипеда

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

Канонічний приклад - проти Хешованого-Замкнутого-Контракту (HTLC). Хоча легко уявити HTLC як контракт, який дозволяє витратити транзакцію шляхом розкриття попереднього зображення або за допомогою тайм-ауту. Насправді, через обмеження скриптування Bitcoin, HTLC дозволяє витратити транзакцію завжди шляхом розкриття попереднього зображення, а потім після закінчення тайм-ауту - додатково за допомогою механізму тайм-ауту.

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

Основним викликом у прибутковому експлуатуванні циклічної заміни є те, що кожне раунд заміни коштує гроші. Реалізація Lightning, яка враховує терміни, буде витрачати все більші та більші комісії, намагаючись витратити закінчену HTLC вихідну операцію до закінчення наступної HTLC вихідної операції, яка в свою чергу закінчується. По-друге, будь-хто може перемогти атаку, просто повторно транслюючи замінену транзакцію.¹⁵одного разу цикл заміни закінчено.

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

Шаблони функцій та м'який форк

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

OP_Expire

Спочатку ми розберемося з цим. Було запропоновано OP_Expire¹⁶ як простий спосіб усунення атаки циклічності заміни шляхом усунення проблеми в джерелі: той факт, що HTLC можна витрачати двома різними способами одночасно. У контексті систем L2 це актуально для всього, що використовує HTLC-подібний механізм, і, можливо, для інших випадків використання. OP_Expire зробило б вихід транзакції невитратним через певний момент часу, дозволивши умовам витрат HTLC бути справжнім ексклюзивним АБО, а не «програмістським АБО».

Фактичний м'який форк OP_Expire, ймовірно, складався би з двох функцій, подібних до того, як OP_CheckLockTimeVerifyтаOP_CheckSequenceVerifyопкоди складаються з двох частин:

1. Поле висоти закінчення для транзакцій, ймовірно, реалізоване в додатку taproot.
2. Опкод OP_Expire, який перевіряє, що висота закінчення встановлена щонайменше на бажану висоту.

Хоча сам OP_Expire навряд чи кваліфікується як ковенант, він виявляється корисним для багатьох залежних від завіту систем L2. Однак це може бути недостатньо корисним, враховуючи, що заміщення велосипедів також може бути пом'якшене альтруїстичною ретрансляцією¹⁵

Дуже помітною проблемою, пов'язаною з розгортанням та використанням OP_Expire, є reorgs: технічне співтовариство Bitcoin, починаючи з Satoshi¹⁷, намагався забезпечити, щоб протокол консенсусу Bitcoin був розроблений таким чином, що після глибокого переорганізації раніше замайнені транзакції можуть бути замайнені в нові блоки. Цей принцип дизайну намагається уникнути кошмарного сценарію великої кількості підтверджених монет, які стають назавжди недійсними — і, отже, люди, які покладаються на ці монети, втрачають гроші — якщо збій консенсусу призводить до великої переорганізації.

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

Значна перешкода у впровадженні терміну дії транзакцій полягає в досягненні згоди щодо того, чи цей компроміс прийнятний, чи навіть потрібний. Типи транзакцій, де OP_Expire був би корисним, вже передбачають досить тривалі тайм-ауты, коли кошти користувача заморожені. Додавання ще більшого часу до цих тайм-аутів не є бажаним. Крім того, подвійні витрати завжди були ще одним способом анулювати монети після реорганізації: зі збільшеним використанням RBF та запропонованого використання безключових якісних виведень, чи термін дії транзакцій зробить значну різницю?

SIGHASH_ANYPREVOUT

BIP-118пропонує два нових режими хешування підпису, які не фіксуються на конкретному UTXO, що витрачається. SIGHASH_ANYPREVOUT, який (по суті) фіксується на scriptPubKey, і SIGHASH_ANYPREVOUTANYSCRIPT, який дозволяє будь-який скрипт. Як вже обговорювалося, спочатку це було запропоновано для використання LN-Symmetry з метою уникнення необхідності окремо підписувати кожен окремий попередній канал, з якого може бути необхідно реагувати.

SIGHASH_ANYPREVOUT також потенційно корисний у випадках, коли ми хочемо використовувати попередньо підписані варіанти RBF з виставленою комісією разом з попередньо підписаними транзакціями, оскільки факт того, що підпис вже не залежить від конкретного txid, уникати Комбінаторний вибух тарифних варіантів. Однак поточний пропозиція BIP-118 не враховує цей випадок використання, і може бути несумісним з ним через те, що SIGHASH_ANYPREVOUT також запропоновано зобов'язатися до вартості UTXO.

Початковим запереченням до SIGHASH_ANYPREVOUT була ідея, що гаманці можуть потрапити у біду, використовуючи його неправильним чином. Проблема полягає в тому, що як тільки опубліковано один підпис SIGHASH_ANYPREVOUT, його можна використовувати для витрати будь-якого виводу txout із заданим скриптом. Таким чином, якщо випадково створено другий вивід з тим самим скриптом, SIGHASH_ANYPREVOUT дозволяє здійснити тривіальну атаку повторного відтворення для викрадення цих монет. Однак, оскільки існує багато інших проблем, пов'язаних з гаманцями та реалізаціями L2, ця проблема, здається, зникла.

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

OP_CheckTemplateVerify

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

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

Тим не менш, це не обов'язково є реальним обмеженням: ви можете легко хешувати ланцюг CTV-шаблонів до глибини десятків мільйонів транзакцій за кілька секунд на сучасному комп'ютері. Звідносні часові блокування nSequenceі обмежений розмір блоку насправді досягнення кінця такого ланцюга може легко зайняти тисячі років.

Поточний пропозиція CTV в BIP-119має лише один режим хешування, відомий як DefaultCheckTemplateVerifyHash, який по суті зобов'язується до кожного аспекту витратної транзакції у хеші шаблону. З практичної точки зору це означає, що в багатьох випадках єдиним доступним механізмом для оплати комісій буде CPFP. Як зазначено вище, це потенційна проблема через те, що вона робить плату за комісію поза каналом невеликою економією в тих випадках, коли транзакції, які використовують CTV, малі.

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

LNHANCE

Один з пропозицій, щоб реалізувати CTV, полягає в поєднанні його з двома додатковими опкодами, OP_CheckSigFromStack(Verify) та OP_InternalKey. Проблема полягає в тому, що на момент написання документація в цьому pull-req та пов'язані з ним BIP просто недостатні, щоб аргументувати за чи проти цієї пропозиції. BIP повністю не містять жодних раціональних обґрунтувань того, що очікується від опкодів насправді робити в реальних прикладах, не кажучи вже про глибокі прикладні сценарії.

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

OP_TXHASH

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

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

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

OP_CAT

Оператор конкатенації, який об'єднує два верхні елементи стеку і знову поміщає отриманий результат у стек. Початково в Bitcoin був увімкнений OP_CAT. Але Сатоші тихо видалили його у 2010 році, ймовірно, через те, що початкова реалізація була вразлива до атак типу DoS через відсутність обмежень на розмір отриманого елемента скрипту. Розгляньте наступний скрипт:

DUP CAT DUP CAT…

Без обмежень розміру елементу, кожна ітерація DUP CAT подвоює розмір верхнього елементу стеку, в результаті чого використовується вся доступна пам'ять.

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

1. Зібрати часткову транзакцію, без свідчень, на стеку з одним або декількома викликами OP_CAT (і будь-якою конкретною логікою, яка потрібна для договору).
2. Перевірте, що транзакція в стеку відповідає транзакції витрат.

Як виявляється, зловживання математикою підписів Schnorr, можливо виконати другий крок за допомогою OP_CheckSig через уважно сконструйовані підписи. Однак більш ймовірно, що м'який форк OP_CAT буде поєднаний з OP_CheckSigFromStack, що дозволить виконати другий крок, перевіривши, що підпис на стеку є дійсним підписом для транзакції¹⁹і потім повторно використовуючи цю ж підпис з OP_CheckSig, щоб підтвердити, що транзакція витрат відповідає.²⁰

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

Обмеження розміру скрипту Modulo, поєднання OP_CAT та OP_CheckSigFromStack достатні для побудови багатьох типів вірництв, включаючи рекурсивні вірництва. Порівняно з більш ефективними рішеннями, такими як CTV, це дорожче. Але різниця в вартості менша, ніж ви очікуєте!

Грубо кажучи, використання OP_CAT для цього потребує, щоб усі частини витратної транзакції, які не є свідченням, були поміщені на стек через свідчення. Для типових випадків використання CTV, таких як txout trees, витратна транзакція не матиме жодних свідчень. Оскільки простір свідчень знижується на 75%, це збільшує нашу ефективну комісію за дочірню транзакцію лише на 25%. Непогано!

Чи є OP_CAT занадто потужним?

Це, ймовірно, найбільша політична та технічна перешкода для впровадження OP_CAT: дуже важко передбачити, які використання будуть можливі завдяки OP_CAT. І як тільки "кіт" вилізе з мішка, його дуже важко туди повернути.

Чудовим прикладом є те, що OP_CAT, як стверджується, достатньо для забезпечення достатньо ефективного та безпечногоSTARK-перевірка буде реалізована в скрипті Bitcoin. Оскільки STARK здатні доводити надзвичайно загальні твердження, можливість ефективного впровадження STARK має значні наслідки, які виходять за рамки систем L2, оскільки це дозволило б побудувати багато різних систем на основі Bitcoin. Вагомим аргументом проти OP_CAT є те, що ці варіанти використання можуть бути не дуже корисними для користувачів Біткойн.

Створення шкідливої централізованої вартості, яку можуть видобути майнери, є ключовою потенційною проблемою,називається "MEV, що є зЛЕ" (MEVil)Матт Коралло. У короткому вигляді, MEVil - це будь-яка обставина, коли великі гірники/пули можуть видобути додаткову вартість, застосовуючи складні стратегії транзакційного майнінгу, які виходять за межі простого максимізування загальних комісій, що є практично неможливим для менших гірників/пулів. Велика складність потенційних фінансових інструментів, які можуть бути створені з OP_CAT, ускладнює визначення MEVil дуже складним. Значна кількість MEVil вже з'явилася на Bitcoin від протоколів торгівлі токенами; на щастя, цей конкретний випадок був переможений завдяки впровадженню повного RBF.

На додаток до потенціалу MEVil, є багато інших конкретних використань OP_CAT, які можуть бути потенційно шкідливими. Наприклад, пропозиція Drivechains була переглянуто тут, і широко вважається шкідливим для Біткойн. Це вважається можливимдля реалізації Drivechain з OP_CAT. Ще одним прикладом є пропозиції щодо токенів, такі як Taproot Assets. Хоча загалом неможливо запобігти їх реалізації звалідація на клієнтській стороні, існують пропозиції реалізувати їх за допомогою OP_CAT таким чином, що потенційно набагато привабливіше для кінцевих користувачів, при цьому використовуючи набагато більше блокового простору, що потенційно може здійснити перевищення «легітимних» транзакцій Bitcoin. Ці використання також можуть викликати правові питання через те, як часто протоколи токенів використовуються для фінансової шахрайства.

Інкрементне хешування

Для обітниць OP_CAT в основному використовується для конкатенації даних, а потім їх хешування. Ще один спосіб досягнення цієї ж мети - це якийсь інкрементальний опкод хешування, який бере проміжний стан SHA256 певного виду, і хешує в ньому більше даних; сам SHA256 працює з 64-байтовими блоками. Існує багато можливих дизайнів для опкодів інкрементального хешування.

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

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

Відродження сценарію

OP_CAT був одним із 15 кодів операцій, які Сатоші вимкнув. Крім відновлення OP_CAT, Расті Рассел пропонує²¹щоб, по суті, відновити скрипт біткойна до "Оригінальної Візії Сатоші" шляхом знову увімкнення більшості цих опкодів, додавання обмежень DoS та, можливо, додавання кількох інших у тому ж самому софт-форку. Зокрема, ймовірно, буде додано OP_CheckSigFromStack.

Хоча OP_CAT сам по собі дійсно дозволяє (рекурсивні) обов'язки, повне «відродження сценарію» зробило би можливими більш складні обов'язки - і набагато легше реалізовувати - оскільки частини транзакції витрат можна було б маніпулювати безпосередньо. Наприклад, можна уявити обов'язки сценарію, які використовують арифметичні опкоди, щоб забезпечити, що загальна вартість txouts у транзакції відповідає деякому бажаному властивості.

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

Простота

Подібно до проведення Скрипту, простота є відповідною до L2 та умов, що дає змогу робити все. На відміну від проведення Скрипту, м'який форк простоти додав би цілком нову мову програмування до скриптової системи Bitcoin на основі дев'яти примітивних операторів, відомих як комбінатори.

На практиці Simplicity - це і занадто просто, і зовсім не просто. Примітивні комбінатори настільки низького рівня, що базові операції, такі як додавання, доводиться трудомістко реалізовувати з нуля; На практиці простота була б виключно багатослівною. Таким чином, будь-яке реальне використання Simplicity буде використовувати систему замін коду, подібну до викликів бібліотечних функцій, відомих як літаки. Це створює практичну / політичну проблему: як ви вирішите, які реактиви реалізувати? Ймовірно, реактиви будуть реалізовані на C++, як будь-який інший опкод, що потребує форка для кожного нового реактиву.

OP_FancyTreeManipulationStuff

Існує велика кількість відносно спеціалізованих кодів операцій, які були запропоновані для маніпулювання деревом просторово ефективним способом для залежних від ковенантів пропозицій L2. Наприклад, Coinpools запропонували і те, і інше TAPLEAF_UPDATE_VERIFYіOP_MERKLESUB, обидва з яких маніпулюють стрижневими кореневими деревами способами, необхідними для пропозиції Coinpools, і MATTпропозиція запропонувала опкод OP_CheckContractVerify, який, в основному, перевіряє висловлювання про дерева Меркла.

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

Та ж сама динаміка відбуватиметься, якби Bitcoin прийняв систему скриптів Simplicity. Еквівалент opcodes у Simplicity - це додавання реактивного двигуна для часто використовуваного шаблону. Знову ж таки, впровадження реактивних двигунів для специфічних випадків використання, таких як маніпуляція деревом, має схожі переваги й недоліки, що і впровадження складних opcodes для специфічних випадків використання.

Фондові Пули

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

Для того, щоб пул фондів був корисним, він повинен мати якийсь «стан даних про обмін», пов'язаний з ним: як розподіляється вартість txout? Якщо пул фондів має розвиватися з часом, цей стан також повинен змінюватися в міру додавання або вилучення коштів з пулу. Оскільки ми спираємося на Bitcoin, додавання або видалення коштів з пулу неминуче вимагатиме витрачання UTXO, яке контролює пул.

Пам'ятайте, що сама система консенсусу Bitcoin заснована на перевірці змін стану: транзакції доводять через своїх свідків, що зміни встановленого стану UTXO є дійсними; Proof-of-work дозволяє нам прийти до консенсусу щодо того, який набір транзакцій є правильним. Це означає, що пули фондів самі по собі також будуть засновані на валідації змін стану: ми доводимо кожному вузлу Bitcoin, що правила для пулу фондів дотримуються при кожній зміні стану.

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

З огляду на ці обмеження, на яких структурах даних будуть базуватися фондові пули? Неминуче, що всі вони є якимось деревом. Зокрема, якесь дерево меркле. Вони повинні бути деревом, тому що це практично єдина масштабована структура даних в комп'ютерних науках; Вони повинні бути меркелізовані, тому що це, по суті, єдиний розумний спосіб криптографічно прив'язати до стану дерева. Нарешті, оновлення дерева неминуче будуть опубліковані в блокчейні Bitcoin, тому що це один публікаційний середовищевсі користувачі L2 діляться тільки одним деревом, на яке ми можемо змусити користувачів публікувати для переміщення монет. І, оскільки будь-яка реалізація обіцянки вимагатиме деяких частин дерева для перевірки того, що правила обіцянки дотримуються.

Так, коли високорівнева теорія вже встигла бути розглянута, як же це насправді відображається у скриптах та транзакціях Bitcoin?

Індивідуальні передпідписані транзакції

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

Єдиним «заповітом», який потрібний тут, є найпростіший заповіт: передпідписана транзакція.

Дерева Txout

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

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

Так, які можливості може надати дерево txout? Знову ж таки, Ark - це чудовий приклад: ми не хочемо, щоб он-чейн викуп єдиного V-UTXO вимагав розміщення кожного окремого V-UTXO на ланцюжку. За допомогою дерева, викуп може розбити дерево на менші частини, поки бажаний V-UTXO не буде розміщений на ланцюжку.

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

Масштабованість дерев txout має цікаві економічні вигоди в масштабі. Вартість першого V-UTXO, яке буде внесено до ланцюжка, у фондовому пулі з n V-UTXOs, приблизно в n log2(n) разів дорожче, ніж одна окрема транзакція, оскільки на ланцюжок потрібно внести log2(n) рівнів розбитих транзакцій. Однак, як тільки перше V-UTXO буде внесено до ланцюжка, подальші V-UTXOs стають дешевше для викупу на ланцюжку, оскільки хтось інший уже заплатив вартість видобуття посередницьких транзакцій.

Згадайте, що загальна кількість елементів у бінарному дереві з

n листя - це 2n. Це означає, що для розміщення всіх V-UTXO на ланцюгу загальна вартість для цього за допомогою дерева txout буде невеликим кратним загальної вартості для цього в одній транзакції. Дивно ефективно!

А може й ні... Якщо загальний розмір викупу фонду достатньо великий, вони можуть представляти незначний попит на загальний обсяг блокування. Блокування - це система подання та попиту, тому в певний момент комісія збільшиться через великий попит. У крайньому випадку дуже можливо створити дерева txout настільки великі та глибокі, що фактично викупляти кожен

V-UTXO в дереві неможливо.

Відкрите питання щодо дерев txout полягає в тому, хто платить комісії та яким чином? Одним очевидним рішенням є використання виходів ключових як якірів на листкових транзакціях, і дозволити кому бажає листкових транзакцій, щоб їх видобули, платити комісії через CPFP. У деяких випадках самі V-UTXO можуть бути витрачені одразу після створення, без затримки CSV, тому самі V-UTXO можуть бути витрачені для додавання комісії через CPFP.

RBF складно реалізувати через дозвіл: очевидне місце для збору комісій за RBF - це значення V-UTXO. Але як забезпечити, що тільки власник має можливість підписати транзакцію з більш високою комісією? У багатьох випадках неочевидно, як це зробити способом, який ефективніший, ніж безключовий вихідний якір. Однак відсутність цього створює серйозні виклики для схем, які використовуються кінцевими користувачами гаманців, які можуть не мати UTXO для виконання CPFP, якщо самі V-UTXO не можуть бути витрачені негайно.

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

Якщо це так, то, можливо, така система не відповідатиме нашим критеріям, щоб бути L2 для малих V-UTXO.

Схеми на основі балансу

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

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

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

Цікаво, що, як і в деревах txout, ви не можете зробити нічого кращого, ніж замовити масштабування log(n), зберігаючи при цьому аналогічні властивості безпеки. Чому? Припустимо, що у нас є гіпотетичний OP_ZKP, який, за допомогою вищої математики, потребував лише 32 байти, щоб довести будь-яке твердження. Хоча цей zk-доказ може довести, що меркелізована структура даних була маніпульована відповідно до правил системи рівня 2, він не зможе надати дані, необхідні для того, щоб наступний користувач також вніс зміну стану. Це не відповідає нашим улюбленим критеріям забезпечення безумовного виведення коштів: у кращому випадку один користувач може досягти безумовного виведення коштів. Але більше ніхто з користувачів не зміг цього зробити.

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

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

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

Коефіцієнт даних про відмову

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

Максимальна ємність блоку в усіх децентралізованих (і централізованих) блокчейнах обмежується технічними обмеженнями. У Bitcoin максимальний розмір блоку такий, що Bitcoin фактично працює на максимальній ємності ~100% часу. Оскільки Bitcoin майнінг діє як аукціонна система, розпродаж блокпростору найвищому пропоненту, на практиці це означає, що мінімальна ставка комісії для видобування транзакції змінюється в залежності від зростання та зменшення попиту.

Швидкість плати завжди враховується в економіці та режимах невдачі L2. Наприклад, у Lightning «пилоподібні» HTLC, які занадто малі для вигідного викупу на-ланцюжкової мережі, використовують інший модель безпеки, ніж більші HTLC. Хоча протокол Lightning ще не належним чином реалізує це, в теорії цей поріг повинен бути динамічним, залежно від швидкості плати, як вони піднімаються та знижуються, ідеально до точки, де сторона могла б вибрати, чи існує HTLC навіть у даній транзакції зобов'язання на основі швидкості плати.

Було запропоновано різноманітні атаки, де ця ситуація намірено викликається на Lightning, такі як повінь і грабіж²² і масова атака на вихід²³. Оскільки ємність блокчейну Bitcoin спільна для всіх випадків використання, також можливі атаки між різними системами L2: наприклад, спровокувати масовий вихід з Ark, щоб отримати прибуток з каналів Lightning.

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

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

Очищення консенсусу

У початковому протоколі Bitcoin Сатоші допустив кілька помилок, зокрема, атаки DoS на сценарії, атаки на часову петлю та проблеми з деревом Меркля. Раніше було вже виправлено кілька інших багів консенсусу за допомогою м'яких форків, таких як перехід до оцінки nLockTime на основі часу, що пройшов, (спроба) виправити проблему дублювання txid тощо.

Останній м'який форк, taproot, мав досить контроверсійний процес впровадження, що зайняло досить довгий час для фактичного впровадження. Аргумент за те, щоб спочатку зробити м'який форк для очищення консенсусу, перед ввімкненням будь-яких нових опкодів або інших функцій для нових типів L2, полягає в тому, що ми дізнаємося більше про те, наскільки готова широка спільнота реалізувати те, що, мабуть, є відносно неспірним м'яким форком, який, безсумнівно, корисний для всіх.

Тестування залежних від м'якого форку L2

Розробникам не потрібно чекати, поки відбудеться софт-форк, щоб протестувати свої ідеї. Один з особливо складних підходів, який використовується розробниками Ark в Ковчег без завітуполягає в тому, щоб симулювати договори, які вони потребують з передпідписаними транзакціями. Це дозволяє їм перевірити ідеї Ark з реальним BTC, на головній мережі, з такими ж характеристиками довіри, які Ark очікується досягти з договорами. Компромісом є те, що Ark без договорів вимагає, щоб всі сторони були онлайн, щоб підписати передпідписані транзакції. Оскільки clArk працює з реальним BTC, він може виявитися достатньо корисним для використання в продукції для певних випадків використання переказу, які можуть терпіти компроміс інтерактивності.

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

Потенційні форки другого рівня

Який шлях вперед? Тут ми будемо складати всі основні схеми L2, які ми проаналізували, та які м'які вилки є корисними (U) або необхідними (R), щоб зробити ці схеми L2 успішними. Як вже обговорювалося вище, OP_CAT (і наслідок цього - Script Revival, який включає OP_CAT), може емулювати всі інші м'які вилки з цього списку - за винятком OP_Expire та Fee Sponsorship - тому, де проект найефективніше задовольняє свої потреби іншою м'якою вилкою безпосередньо, ми не включатимемо OP_CAT.

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

CTV - це бездоганний переможець тут, за ним йде SIGHASH_ANYPREVOUT (OP_Expire є корисним для багатьох речей, бувши заміною циклічного виправлення, але не є обов'язковим). CTV перемагає, тому що так багато речей підходять під шаблон 'переконайтеся, що транзакція витрат відповідає цьому шаблону'; навіть конструкції OP_CAT можуть ефективно використовувати CTV.

На відміну від OP_CAT, CTV, схоже, не створює великого ризику ненавмисних наслідків, окрім заохочення позасмугових платежів у певних випадках. Це не ідеально. Але ніхто не придумав широко підтримуваної альтернативи.

Моя особиста рекомендація: зробити очищення згоди м'яким форком, а потім CTV.

Застереження:

1. Ця стаття розміщена з [ Пітертодд], Переслайте оригінальну назву «Чи є дорожня карта Ethereum не на правильному шляху?», Усі авторські права належать оригінальному автору [petertodd]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Gate Learn команди, і вони оперативно впораються з цим.

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

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