Timeout Tree: рішення для масштабування постачальників Lightning-послуг

Одним із найбільших обмежень, притаманних мережі Lightning, є обмежена кількість каналів на блок, які можна відкрити або закрити, з огляду на обмеження розміру блоку. Незалежно від того, скільки транзакцій може відбуватися офчейн і наскільки дешево, це проблемна область, яка обмежує кількість людей, які можуть реально використовувати мережу Lightning. Навіть у white paper мережі Lightning був зроблений висновок про те, що в сценарії, коли все населення світу в 7 мільярдів людей почне використовувати Lightning, маючи можливість здійснити тільки дві внутрішньомережні транзакції на рік на людину, для роботи Lightning знадобляться Біткоїн-блоки розміром 133 МБ. Це не якась незвичайна чи непередбачувана проблема – це обмеження протоколу існувало від самого початку.

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

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

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

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

Timeout Trees

Нещодавня пропозиція Джона Лоу, Timeout Trees, здатна запропонувати вирішення однієї з основних проблем фабрик каналів. Я б не назвав Timeout Trees фабрикою каналів, скоріше «протофабрикою», але це може стати потенційним розв'язанням проблеми відкриття та закриття величезної кількості каналів без виникнення проблеми некоординованих закриттів, що заважають використанню фабрики іншими користувачами. Для його функціонування потрібен CHECKTEMPLATEVERIFY (CTV) та постачальник послуг Lighting (LSP).

Timeout Tree – це, по суті, фабрика каналів, гарантована угодами, без можливості змінити спосіб реорганізації ліквідності поза ланцюжком після її створення, зі спеціальним застереженням про відмову. LSP, назвемо його Бобом, слугує для звʼязку випадкових користувачів із ширшою мережею Lightning. Боб може взяти монети, які він контролює, і створити дерево CTV, яке створює єдиний UTXO для відкриття каналів для будь-якої кількості користувачів його сервісу LSP. CTV дозволяє робити це без одночасного підключення всіх користувачів до мережі. Боб може просто зробити так, що всі підпишуть вихідний стан каналу по одному, та утримувати учасників доти, доки всі не налаштують канал, і просто витратити кошти на дерево CTV, коли буде налаштовано канали для кожного користувача.

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

Тепер останнє, що стосується закриття каналів. Попри те, що, використовуючи CTV, для їхнього відкриття потрібно лише один UTXO в ланцюжку, їхнє закриття все одно вимагатиме розгортання всього дерева CTV у ланцюжку, щоб кожен міг відправляти стани своїх каналів, чи не так? Не зовсім. Це частина тайм-ауту у Timeout Trees. У кожній гілці дерева тайм-аутів є гілка зі скриптом, в якій Боб може забрати всі кошти після блокування часу.

Ви певно думаєте: що?! Те, як працює це рішення, справді геніально. Оскільки після таймлоку Боб може самостійно очистити UTXO в ланцюжку без будь-кого іншого, усі ці канали мають термін дії, якщо користувачі фактично не розгорнуть все дерево і не підтвердять реальне фінансування каналу ончейн. Це дозволяє Бобу зробити наступне: коли наближається час блокування, він може відкрити нове Timeout Tree з усіма користувачами поточного, в яке вони повністю перемістять усі свої кошти офчейн через Lightning, а потім забрати єдиний ончейн UTXO останнього дерева.

Це дозволяє ефективно закривати всі канали ончейн. Єдина проблема, яка залишилася, – це забезпечення дотримання HTLC ончейн, якщо інша сторона перестане співпрацювати. Ну… в цьому випадку це не проблема, чи, скоріше, це питання «все або нічого». Причина, через яку канали повинні бути закриті для забезпечення дотримання HTLC, полягає в тому, що інша сторона каналу перестає відповідати в процесі його маршрутизації. У дереві тайм-аутів двійником кожного окремого користувача є Боб. Таким чином, якщо Боб, якщо він чесний, не відповідає на оновлення невдалого чи успішного HTLC для одного користувача, він не відповідає і для будь-якого іншого користувача. У цьому випадку кожен може закрити свої канали ончейн до закінчення очікування і припинити використання LSP Боба.

Підбиваючи підсумки

Користувачам, як і раніше, доведеться платити комісію за взаємодію всередині ланцюжка, обійти це неможливо, і закриття всього дерева тайм-аутів у ланцюжку без співпраці буде великою і дорогою дією – але зрештою це проблема, яку має вирішити будь-яка багатостороння канальна система. Однак пропозиція Timeout Trees пропонує привабливі рішення для спільного відкриття та закриття величезного багатостороннього каналу без пониження моделі довіри системи до чогось кастодіального.

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

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