Невірне розуміння відношень між Шаром 1 і Шаром 2

Шар 2 - не чарівне заклинання

Загальний заклик від багатьох у цій сфері на сьогодні у відповідь на будь-яку обговорення змін у протоколі Bitcoin - `Не міксуйте з Шар 1! Ви можете просто будувати на Шар 2!` Це, здавалося б, дуже логічна річ, чи не так? Чому ризикувати безпекою і стабільністю L1, коли ви можете просто будувати на його основі? Проте ось тут фундаментально непорозуміння стосунків між Шар 1 та Шар 2.

Протокол L2 є розширенням L1. Все, що розроблено для L2, повинно в будь-якому разі зводитися до того, на що здатний L1. Загальний висновок `просто робіть це на L2!` затемнює численні неявні реальності того, що можливо або неможливо робити на L2, враховуючи поточний стан базового рівня. Наприклад, уявіть собі спробу побудувати мережу Lightning без наявності скриптів з багатьма підписантами. Це було б неможливо. Не було б можливо розділити контроль між кількома особами, і ціла концепція платіжного каналу була б неможливою. Еволюція платіжних каналів.

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

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

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

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

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

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

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

Таким чином, Ланцюг Lightning, як він існує сьогодні, повністю залежить від п`яти можливостей, які можливі на базовому рівні Bitcoin. Мультипідписні скрипти, абсолютні блокові заборони, відносні блокові заборони, відігороджені свідки та хешлоки. Без будь-якої з цих функцій, що існують на L1, Мережа Lightning, як ми знаємо її сьогодні, не була б можливим L2, який ми могли б побудувати. Її існування як L2 повністю залежить від можливості L1 виконувати певні дії. Отже, якщо хтось у світі, де Bitcoin не підтримує хешлоки, блокові заборони в скриптах та виправлення деформації, просто скаже “просто побудуйте бідирекціональну систему мульти-хопових платіжних каналів на Шар 2! Ми не повинні грати з Шар 1”, це буде абсолютно непослідовною заявою. Прикрощі

Проте, строго технічно кажучи, все одно було б можливо побудувати цю бідирекціональну