Другий рівень – це не чарівне рішення

У наші дні багато хто у цій сфері у відповідь на будь-яке обговорення змін у протоколі Біткоїна різко відповідає: «Не зачіпайте базовий рівень! Можна просто працювати з другим рівнем!» Здається, що це дуже логічно, чи не так? Навіщо ризикувати безпекою та стабільністю базового рівня, якщо можна просто використовувати його як основу? Проблема в тому, що тут не враховується взаємозв'язок між базовим і другим рівнем.

Протокол другого рівня – це розширення базового рівня. Все, для чого призначений другий рівень, зрештою зводиться до того, на що здатен перший рівень. Загальна порада «просто зроби це на другому рівні!» маскує численні неявні реалії того, що можна чи не можна зробити на другому рівні з огляду на поточний стан базового рівня. Наприклад, ви спробуєте побудувати мережу Lightning без використання скриптів з мультипідписом. У вас не вийшло б. Не вийшло б розділити контроль між кількома людьми, і вся концепція платіжного каналу стала б неможлива.

Еволюція платіжних каналів

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

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

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

Для двосторонніх платежів необхідне було правильне рішення податливості транзакцій. Це стало величезним поштовхом для створення Segregated Witness. Таймлок – це все, що було необхідно для одностороннього каналу, бо сума коштів збільшувалася лише в одному напрямку. Єдиним ризиком для відправника було те, що інша сторона не вимагатиме коштів, які вже було відправлено ончейн, внаслідок чого гроші відправника «застрягали». Повернення з використанням блокування за часом дало одержувачу стимул запросити кошти ончейн до настання моменту блокування, інакше він втратив би вже надіслані кошти, а відправнику – використовувати право регресу та назавжди відключити отримувача від мережі. Скрипт не підтримує примусове використання певних сум у певних майбутніх сценаріях, тому попередньо підписана транзакція є єдиним життєздатним механізмом відшкодування, якщо платежі повинні бути двосторонніми. Це відновило ризик того, що кошти застрягнуть.

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

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

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

Таким чином, Lightning Network у тому вигляді, в якому вона існує сьогодні, повністю залежить від п'яти функціональних можливостей, доступних на базовому рівні Біткоїна: скрипти з кількома підписами, абсолютні таймлоки, відносні таймлоки, Segregated Witness та хеш-локи. Без будь-якої з цих функцій на базовому рівні не було б мережі Lightning, якою вона є сьогодні. Її існування як другого рівня залежить від функціональності першого рівня.

У чому підступ

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

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

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

В чому сенс?

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

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

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