By Bitcoin Журнал - 1 рік тому - Час читання: 7 хвилини
Кілька способів, як ми можемо оновити маршрутизацію платежів у мережі Lightning
Щоб розвинути протокол, який можна використовувати в усьому світі, необхідно розглянути певні вдосконалення масштабування для Lightning.
Lightning Network — це добре розроблене, швидкозростаюче рішення для транзакцій рівня 2 на Bitcoin мережі. Все більше і більше сервісів і бірж інтегрують його, ліквідність, доступна для маршрутизації платежів, зростає, і щороку розробляється більше додатків і способів взаємодії користувачів з ним. Він також має багато проблем, які потрібно подолати в довгостроковій перспективі:
Масштабованість обмежує кількість каналів, які можна відкрити або закрити в ланцюжку одночасно. Є проблема з мінімальним розміром Контракт із заблокованим часом хешування (HTLC) зростає, оскільки комісії в ланцюжку також збільшуються, оскільки розрахунок має бути економним. Існує також безліч проблем із конфіденційністю.Одним із основних питань, яке часто обговорюється, є вимоги до ліквідності для маршрутизації платежів. Щоб успішно спрямувати платіж, має бути зв’язок каналів від відправника до одержувача, який має достатню ліквідність у правій частині каналу, щоб мати можливість передати платіж. Це робить рішення про те, де розгортати монети в мережі, дуже важливим. Це також означає, що загальний обсяг ліквідності, який люди готові розгорнути, є свого роду верхньою межею того, скільки вартості може обробити мережа.
Зрештою, це зводиться до того, що коли ви відкриваєте канал, ви вирішуєте заблокувати ці гроші, щоб їх можна було використовувати лише для спрямування платежів цьому партнеру каналу та ким би він не був пов’язаний на графіку. Так, зрештою, ідея Lightning Network полягає в тому, що, зробивши достатню кількість стрибків, ви можете знайти з’єднання практично будь-де. Однак реальність така, що якщо хтось інший може здійснити маршрутизацію платежу до пункту призначення, використовуючи менше стрибків, ніж ви, це шлях, який, швидше за все, буде вибрано для маршрутизації платежу. Lightning вже потребує надлишкової застави в значній мірі, тобто для маршрутизації платежу в 1 BTC через 10 стрибків потрібно 10 BTC застави, які будуть заблоковані в платіжних каналах уздовж цього маршруту. Конкуренція за наявність хороших з’єднань для отримання прибутку від маршрутизації посилює це, стимулюючи ще більше надлишкового забезпечення.
Ця проблема виникає через те, що канали Lightning є двосторонніми «трубками», які можуть просто штовхати значення туди-сюди в цих двох напрямках. Однак ось що: проблема начебто уявна. Платежі на Lightning використовують HTLC, скрипт у a Bitcoin вихід, який говорить, що одна особа може вимагати виведення та витрачати його, розкриваючи прообраз для хешу, або інша особа може вимагати виведення та витрачати його після закінчення часу блокування. Це загальний сценарій, який можна застосовувати в ланцюжку, у каналах Lightning, поверх ланцюжків станів, у бічних ланцюгах тощо. Якщо ви можете використовувати HTLC, теоретично будь-що може брати участь у маршрутизації платежу Lightning.
Державні ланцюги
A державний ланцюг це фактично щось на кшталт каналу Lightning, за винятком того, що ви можете передати право власності на весь канал повністю поза мережею. Їхня модель довіри залежить від оператора (яким може бути федерація) ланцюга станів, який відмовляється вступати в змову з минулими власниками та викрасти ланцюг станів у поточного власника. Він не такий надійний, як канал Lightning, але він набагато гнучкіший, оскільки право власності можна передати без необхідності виконувати транзакцію в ланцюжку. Враховуючи, що ланцюги станів базуються на попередньо підписаних транзакціях поза ланцюгом, ви можете додати до них HTLC.
Це дозволяє використовувати їх для оптимізації ефективності маршрутизації платежів на Lightning, дозволяючи операторам вузлів перепризначати ліквідність на платформі fly off-chain. Замість того, щоб відкривати канали та поглинати в них ліквідність, щоб завчасно бути добре підключеними, їхні кошти можна динамічно перерозподіляти на льоту поза ланцюгом у відповідь на зміщення попиту в місця, до яких вони не підключені (або не підключені достатньо добре, щоб ). Єдина вимога полягає в тому, щоб інша сторона бажала перенести ліквідність на довіру оператору ланцюга станів.
бічні ланцюги
Сайдчейни можуть запроваджувати будь-які довільні правила. Час блоку може бути різним, розміри блоку можуть бути різними, будь-що можна змінити. Єдина заковика на даний момент полягає в тому, щоб перемістити свій Bitcoin до бічного ланцюга, ви повинні довіряти федерації, яка зберігає кошти в основному ланцюзі. Ви можете застосувати HTLC до сайдчейну, який використовує Bitcoinсистема сценаріїв; ви можете мати більш схожу на Ethereum систему сценаріїв, яка дозволяє десяткам людей спільно використовувати обліковий запис, який розподіляє баланси та оновлює їх відповідно до того, успішно чи невдало HTLC; ти можеш все. Поки блокчейн підтримує умовну передачу грошей одній стороні, якщо вона виробляє хеш, і іншій стороні після закінчення часу блокування, вони можуть допомагати направляти платежі Lightning. Інші блокчейни можуть експериментувати зі способами зробити розподіл ліквідності більш ефективним, ніж основний Bitcoin блокчейн. Ви навіть можете зробити щось таке елементарне, як створення іншої мережі Lightning у ланцюжку, де дешевше відкривати та закривати канали. Уява – це межа.
Цілком нові конструкції
Ось моя власна випадкова ідея: багато людей можуть об’єднати в одне ціле m-з-n (тобто 3-з-5) мультисиг-адресу з декількома депонентами, і просто довіртеся депонентам, щоб вирішити питання належним чином. Кожна особа в адресі та депоновані агенти можуть відстежувати та оновлювати «баланси» на основі маршрутизації платежів; реєструвати HTLC, які були використані, і чи вони успішно врегульовані чи відшкодовані; і періодично встановлювати баланси в мережі. Ви просто створюєте мультипідпис так, щоб єдиний учасник "маршрутизації" та всі агенти депонування були всім, що потрібно витратити від мультипідпису. Ви навіть можете створити транзакцію відшкодування з обмеженим часом, щоб повернути гроші всім після певного періоду, недоліком якої буде те, що всі гроші, отримані будь-ким за час існування конструкції, будуть втрачені, якщо це буде використано. Це потребує розрахунків у ланцюжку до того, як транзакція відшкодування стане дійсною для витрачання.
Це вимагало б довіри до агентів депонування, але перевага полягала б у тому, що будь-яка особа в цій «групі UTXO» могла б переказати кошти або направити HTLC до будь-який інша особа в групі UTXO. Це було б величезним підвищенням ефективності розподілу ліквідності.
Кредитні відносини
Найпростішим способом досягти ефективності було б просто довіряти людям. Якщо ви можете заробляти гроші, направляючи платіж через мережу для когось, але у вас немає відкритого каналу до вузла, необхідного для маршрутизації цього платежу, тоді ви можете просто пообіцяти заплатити їм пізніше якщо вони тобі довіряють. Якби ви були особливо надійною особою чи організацією, і багато людей у мережі були готові довіряти вам таким чином, тоді ви могли б направляти платежі з величезним ступенем гнучкості та не вкладати капітал у платіжні канали по всій мережі. Просто чесно розрахуйтеся наприкінці дня, і люди продовжуватимуть довіряти вам і здійснювати виплати за вас на основі системи честі.
Одна проблема й переваги
Основна перевага всіх цих можливостей полягає в тому, що, незважаючи на те, що всі вони мають величезні відмінності з точки зору моделі довіри (більшість із них фактично явно вимагають від вас довіряти людям, з якими ви взаємодієте, якщо ви вирішите їх використовувати), це абсолютно не має значення для відправника та одержувача. Якщо у мене є звичайний ненадійний канал Lightning і я хочу заплатити комусь, хто також має ненадійний звичайний канал Lightning, для нас не має жодного значення, як цей платіж туди потрапить. Коли я надсилаю гроші, цей платіж оновлюється та виконується в моєму каналі Lightning разом із моїм партнером без довіри, як зазвичай. Коли одержувач дійсно отримує гроші, цей платіж оновлюється та виконується в його каналі Lightning разом із однолітком без довіри, як зазвичай. Той факт, що хтось посередині просто довіряє обіцянці свого однолітка заплатити йому пізніше, абсолютно не має значення для нас обох. Я надіслав свої гроші й більше не контролюю їх, а одержувач фактично отримав свої гроші й тепер контролює їх без довіри.
Проблема в тому, як мені, як відправнику, дізнатися про ці відносини? У Lightning відправник — це той, хто вибирає маршрут для платежу після перегляду таблиці маршрутизації загальнодоступних каналів у мережі, які бажають пересилати платежі. Щоб рекламувати можливість маршрутизації платежу, потрібно показати UTXO у ланцюжку, який фінансував ваш канал Lightning, і підтвердити, що це справжній канал. Проблема тут полягає в тому, що жодна з наведених вище ідей не зможе цього забезпечити, тому відправник платежу може знати про інші варіанти маршрутизації платежу. Якби протокол переговорів і структура таблиці маршрутизації були оновлені, щоб дозволити ці інші речі, їх можна було б повідомити про інші варіанти.
Єдина справжня вимога — переконатися, що реклама інших «неканальних» способів маршрутизації платежів не відкриває вектори відмови в обслуговуванні. Поточна схема, яка вимагає обміну UTXO, який фінансував канал, існує як захист від людей, які рекламують неіснуючі канали, що може перевантажити вузли марними плітками, а також призвести до того, що користувачі постійно намагатимуться здійснити платежі, яких ніколи не було шанс досягти успіху в першу чергу.
Зрештою, є проблеми, які потрібно вирішити, щоб підвищити гнучкість маршрутизації платежів у мережі, але їх можна вирішити. Вважати, що Lightning має продовжувати функціонувати так, як зараз, щоб працювати як платіжна мережа, є дуже вузьким мисленням, і, прямо кажучи, вигадувати проблеми, які здебільшого є уявними.
Це гостьовий пост від Shinobi. Висловлені думки є повністю їх власними і не обов’язково відображають думки BTC Inc або Bitcoin журнал.
Оригінальний джерело: Bitcoin журнал