Автор: Віктор Бунін, експерт з хмарних протоколів Coinbase. Компілятор: Qianwen, ChainCatcher
Я деякий час не використовував Lightening (пізніше названу «Lightning Network»).
Востаннє я працював над цим у 2019 році, коли об’єднався з Елізабет Старк та іншими лідерами спільноти, щоб організувати першу конференцію Lightning Network у Берліні. Відтоді я витрачав більшу частину свого часу на роботу над іншими протоколами, і хоча я все ще дружу з такими людьми, як Елізабет, моє розуміння того, як насправді працює Lightning Network, деградувало. Після повторного огляду я зрозумів, що справа не тільки в мені, а й у більшості моїх друзів.
Ця публікація для тих, хто останнім часом не користувався Lightning Network. У ньому обговорюватимуться неправильні уявлення, які я чи інші бачили. Якщо я пропустив якісь хороші моменти, напишіть мені в Twitter.
**Помилка 1: Ви повинні запустити власний вузол, щоб використовувати Lightning Network без обмеження доступу, що перешкоджає звичайним користувачам використовувати мобільні пристрої. **
Це було правдою кілька років тому, але тепер користувачі можуть використовувати Lightning Network на мобільних пристроях через некеровані легкі клієнти. Користувачі завжди контролюють свої ключі, а робота гаманця з клієнтом Lightning Light така ж, як виклик Alchemy або Infura через RPC під час використання Ethereum.
**Помилка 2: відправник і отримувач повинні бути онлайн одночасно, щоб платежі Lightning були успішними (без офлайн/синхронних платежів). **
Ця ситуація все ще існує, але з деякими акуратними обхідними шляхами. Мобільні гаманці Lightning, які не підлягають зберіганню, можуть отримувати платежі за допомогою фонових завдань або телефонних сповіщень, навіть якщо гаманець не працює в активному режимі. Однак цей підхід обмежений мобільними операційними системами. Сучасні операційні системи обмежують кількість обчислень, що виконуються фоновими програмами, щоб заощадити акумулятор. Отримання кількох LN-платежів — це нормально, але якщо за короткий проміжок часу їх надходить занадто багато, термін їх дії закінчується через обчислювальні обмеження.
У довгостроковій перспективі розробники протоколу Lightning Network працюють над специфікацією асинхронних платежів, яка забезпечить будь-які довгі затримки без довіри. По суті, платіж зараховується з вузла відправника, але якщо вузол одержувача вимикається, платіж залишається в LSP відправника (Lightning Network/Liquidity Service Provider, зазвичай керується самим гаманцем), доки одержувач не повернеться в мережу. ** Очікується, що це оновлення відбудеться наступного року, але офіційної дати запуску ще немає. **Однак для цього потрібно, щоб гаманці-учасники містили LSP, що може перешкодити його прийняттю як рішення для всієї мережі.
**Непорозуміння 3: Lightning Network вимагає від обох користувачів інвестувати однакову суму BTC у канал, щоб відкрити канал. **
Це не відповідає дійсності. У більшості клієнтів Lightning Network за замовчуванням канал відкрито в одну сторону, тому лише відправник має інвестувати кошти в канал, а одержувач може бути абсолютно новою порожньою адресою. Це непорозуміння випливає з офіційного документа Lightning Network, де приклади постійно посилаються на двосторонні канали фінансування.
Насправді він заснований на цікавій передісторії. Найраніший платіжний канал (Spilman) дозволяв лише односторонні платежі. Інновація Lightning Network полягає в реалізації подвійних коштів і двосторонньої оплати, а канал не має терміну дії. Можливо, саме тому в статті Lightning Network так багато уваги приділяється цьому. Це був значний винахід порівняно з відомими на той час дизайнами протоколів.
**Міф 4: Lightning Network вимагає від користувачів вказувати конкретні одноцільові рахунки-фактури, що є жахливим для користувачів. **
Це справді було правдою на початку. Але тепер з адресою Lightning Network це фактично ENS мережі Lightning. Вони ввімкнені за допомогою lnurl-pay, яка дозволяє користувачам надсилати BTC на viktor@example.com через Lightning Network, незалежно від суми та тривалості.
**Непорозуміння 5: користувачі повинні розуміти та вибирати Bitcoin і Lightning Network під час надсилання BTC. **
Мабуть так було раніше. Але зараз все інакше. Тепер у них є уніфікований QR-код, який акуратно об’єднує адресу мережі з рахунком-фактурою Lightning Network, щоб гаманець-відправник міг вибрати правильний маршрут. Відкрийте CashApp, перейдіть на вкладку Bitcoin. Зауважте, що в той час як Cash App підтримує Lightning Network, ви не можете вибрати Lightning Network. Це тому, що вони використовують єдиний QR-код.
Однак це не вирішує проблему єдиного балансу – баланс BTC користувача все одно може бути розділений на ланцюг і в Lightning Network. Цю проблему можна певною мірою вирішити за допомогою Submarineswap та/або Splicing, але я довгостроково бачу, що користувачі навіть не усвідомлять, що це проблема, і вони не усвідомлять, що Lightning Network існує, тому що гаманець та інші постачальники обробляють базові складності, які будуть приховані під зручним користуванням.
**Міф №6: мережа Lightning неефективна і тому нежиттєздатна. **
Ця дискусія є делікатною, і я намагатимусь бути максимально нейтральним.
Lightning Network використовує модель зі спицями. Частина мережі «хаб-хаб» має високу ефективність капіталу завдяки високому коефіцієнту «розподілу капіталу на одиницю» великих каналів між біржами, кастодіальними гаманцями, LSP та оптимальними вузлами маршрутизації.
Однак там, де капітальна неефективність мережі Lightning знаходиться на межі, - користувачі, які не є опікунами. Для кастодіальних користувачів Lightning гаманцям потрібно лише підтримувати великі канали з іншими хабами та виконувати внутрішній облік балансів користувачів. Для користувачів, які не є опікунами, гаманець повинен підтримувати окремий відкритий канал фінансування для кожного користувача. Завдання полягає в тому, як підтримувати постійний розподіл ліквідності та управління цими каналами.
Наведемо конкретний приклад: користувач гаманця, який не є опікуном, хоче надіслати 0,1 BTC другові через Lightning Network. Якщо припустити, що в каналі між ними та постачальником гаманця та кожним вузлом на цьому шляху є достатня ліквідність, платіж буде успішним. Але тепер у гаманця виникла проблема – у них є 0,1 BTC у каналі на їхньому боці, якщо користувач не отримує жодного платежу (таким чином перебалансовуючи канал), ці 0,1 BTC будуть там простоювати, що спричинить низьку неефективність постачальника гаманця. На цьому етапі постачальники гаманців повинні вирішити, чи зберігати ліквідність, чи вилучати ліквідність шляхом закриття каналів (що створює поганий досвід користувача) або з’єднання каналів (які невидимі для користувачів).
Для користувачів, які не є опікунами, ця проблема граничної неефективності капіталу є дуже неприємною проблемою оптимізації, яка об’єктивно гірша, ніж модель на основі рахунку, незалежно від розміру транзакції. Однак це не є нерозв'язною проблемою. Поки це не неможливо, воно має бути успішним, що також є девізом спільноти розробників Bitcoin.
На додаток до труднощів оптимізації капіталу, ще одна проблема пов’язана з витратами, пов’язаними з управлінням каналом і ліквідністю, оскільки кожне з’єднання, закриття каналу тощо вимагає транзакції в ланцюжку. Бюджет безпеки біткойна залежить від значного збільшення комісії за транзакції, але якщо комісія за транзакції зросте до 30-60 доларів США, управління каналом буде надзвичайно дорогим у масштабі, а мережа Lightning Network без опіки може бути недоступною для значної частини населення світу. Розміщені гаманці Lightning наразі мають перевагу завдяки вбудованим заохоченням і, ймовірно, зростуть ще більше, оскільки комісії в ланцюжку зростуть, оскільки їх модель омнібусного облікового запису робить керування каналом набагато рідше. Спільнота наполегливо працює, щоб виправити це та забезпечити, щоб гаманці Lightning, які не підлягають зберіганню, залишалися першокласними громадянами в мережі, але чіткого рішення поки що немає.
Lightning Network ще має пройти довгий шлях, щоб стати простою, бездоганною та повністю абстрактною. Є ще багато крайніх випадків, і некеровані користувачі ще не насолоджувалися найкращим користувацьким досвідом. Однак багато проблем уже вирішено, і ще багато буде вирішено в найближчі кілька років. Тепер, коли блискавка спалахнула, чи може грім залишитися далеко позаду?
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Роз’яснення 6 неправильних уявлень про мережу Lightning Bitcoin
Автор: Віктор Бунін, експерт з хмарних протоколів Coinbase. Компілятор: Qianwen, ChainCatcher
Я деякий час не використовував Lightening (пізніше названу «Lightning Network»).
Востаннє я працював над цим у 2019 році, коли об’єднався з Елізабет Старк та іншими лідерами спільноти, щоб організувати першу конференцію Lightning Network у Берліні. Відтоді я витрачав більшу частину свого часу на роботу над іншими протоколами, і хоча я все ще дружу з такими людьми, як Елізабет, моє розуміння того, як насправді працює Lightning Network, деградувало. Після повторного огляду я зрозумів, що справа не тільки в мені, а й у більшості моїх друзів.
Ця публікація для тих, хто останнім часом не користувався Lightning Network. У ньому обговорюватимуться неправильні уявлення, які я чи інші бачили. Якщо я пропустив якісь хороші моменти, напишіть мені в Twitter.
**Помилка 1: Ви повинні запустити власний вузол, щоб використовувати Lightning Network без обмеження доступу, що перешкоджає звичайним користувачам використовувати мобільні пристрої. **
Це було правдою кілька років тому, але тепер користувачі можуть використовувати Lightning Network на мобільних пристроях через некеровані легкі клієнти. Користувачі завжди контролюють свої ключі, а робота гаманця з клієнтом Lightning Light така ж, як виклик Alchemy або Infura через RPC під час використання Ethereum.
**Помилка 2: відправник і отримувач повинні бути онлайн одночасно, щоб платежі Lightning були успішними (без офлайн/синхронних платежів). **
Ця ситуація все ще існує, але з деякими акуратними обхідними шляхами. Мобільні гаманці Lightning, які не підлягають зберіганню, можуть отримувати платежі за допомогою фонових завдань або телефонних сповіщень, навіть якщо гаманець не працює в активному режимі. Однак цей підхід обмежений мобільними операційними системами. Сучасні операційні системи обмежують кількість обчислень, що виконуються фоновими програмами, щоб заощадити акумулятор. Отримання кількох LN-платежів — це нормально, але якщо за короткий проміжок часу їх надходить занадто багато, термін їх дії закінчується через обчислювальні обмеження.
У довгостроковій перспективі розробники протоколу Lightning Network працюють над специфікацією асинхронних платежів, яка забезпечить будь-які довгі затримки без довіри. По суті, платіж зараховується з вузла відправника, але якщо вузол одержувача вимикається, платіж залишається в LSP відправника (Lightning Network/Liquidity Service Provider, зазвичай керується самим гаманцем), доки одержувач не повернеться в мережу. ** Очікується, що це оновлення відбудеться наступного року, але офіційної дати запуску ще немає. **Однак для цього потрібно, щоб гаманці-учасники містили LSP, що може перешкодити його прийняттю як рішення для всієї мережі.
**Непорозуміння 3: Lightning Network вимагає від обох користувачів інвестувати однакову суму BTC у канал, щоб відкрити канал. **
Це не відповідає дійсності. У більшості клієнтів Lightning Network за замовчуванням канал відкрито в одну сторону, тому лише відправник має інвестувати кошти в канал, а одержувач може бути абсолютно новою порожньою адресою. Це непорозуміння випливає з офіційного документа Lightning Network, де приклади постійно посилаються на двосторонні канали фінансування.
Насправді він заснований на цікавій передісторії. Найраніший платіжний канал (Spilman) дозволяв лише односторонні платежі. Інновація Lightning Network полягає в реалізації подвійних коштів і двосторонньої оплати, а канал не має терміну дії. Можливо, саме тому в статті Lightning Network так багато уваги приділяється цьому. Це був значний винахід порівняно з відомими на той час дизайнами протоколів.
**Міф 4: Lightning Network вимагає від користувачів вказувати конкретні одноцільові рахунки-фактури, що є жахливим для користувачів. **
Це справді було правдою на початку. Але тепер з адресою Lightning Network це фактично ENS мережі Lightning. Вони ввімкнені за допомогою lnurl-pay, яка дозволяє користувачам надсилати BTC на viktor@example.com через Lightning Network, незалежно від суми та тривалості.
**Непорозуміння 5: користувачі повинні розуміти та вибирати Bitcoin і Lightning Network під час надсилання BTC. **
Мабуть так було раніше. Але зараз все інакше. Тепер у них є уніфікований QR-код, який акуратно об’єднує адресу мережі з рахунком-фактурою Lightning Network, щоб гаманець-відправник міг вибрати правильний маршрут. Відкрийте CashApp, перейдіть на вкладку Bitcoin. Зауважте, що в той час як Cash App підтримує Lightning Network, ви не можете вибрати Lightning Network. Це тому, що вони використовують єдиний QR-код.
Однак це не вирішує проблему єдиного балансу – баланс BTC користувача все одно може бути розділений на ланцюг і в Lightning Network. Цю проблему можна певною мірою вирішити за допомогою Submarineswap та/або Splicing, але я довгостроково бачу, що користувачі навіть не усвідомлять, що це проблема, і вони не усвідомлять, що Lightning Network існує, тому що гаманець та інші постачальники обробляють базові складності, які будуть приховані під зручним користуванням.
**Міф №6: мережа Lightning неефективна і тому нежиттєздатна. **
Ця дискусія є делікатною, і я намагатимусь бути максимально нейтральним.
Lightning Network використовує модель зі спицями. Частина мережі «хаб-хаб» має високу ефективність капіталу завдяки високому коефіцієнту «розподілу капіталу на одиницю» великих каналів між біржами, кастодіальними гаманцями, LSP та оптимальними вузлами маршрутизації.
Однак там, де капітальна неефективність мережі Lightning знаходиться на межі, - користувачі, які не є опікунами. Для кастодіальних користувачів Lightning гаманцям потрібно лише підтримувати великі канали з іншими хабами та виконувати внутрішній облік балансів користувачів. Для користувачів, які не є опікунами, гаманець повинен підтримувати окремий відкритий канал фінансування для кожного користувача. Завдання полягає в тому, як підтримувати постійний розподіл ліквідності та управління цими каналами.
Наведемо конкретний приклад: користувач гаманця, який не є опікуном, хоче надіслати 0,1 BTC другові через Lightning Network. Якщо припустити, що в каналі між ними та постачальником гаманця та кожним вузлом на цьому шляху є достатня ліквідність, платіж буде успішним. Але тепер у гаманця виникла проблема – у них є 0,1 BTC у каналі на їхньому боці, якщо користувач не отримує жодного платежу (таким чином перебалансовуючи канал), ці 0,1 BTC будуть там простоювати, що спричинить низьку неефективність постачальника гаманця. На цьому етапі постачальники гаманців повинні вирішити, чи зберігати ліквідність, чи вилучати ліквідність шляхом закриття каналів (що створює поганий досвід користувача) або з’єднання каналів (які невидимі для користувачів).
Для користувачів, які не є опікунами, ця проблема граничної неефективності капіталу є дуже неприємною проблемою оптимізації, яка об’єктивно гірша, ніж модель на основі рахунку, незалежно від розміру транзакції. Однак це не є нерозв'язною проблемою. Поки це не неможливо, воно має бути успішним, що також є девізом спільноти розробників Bitcoin.
На додаток до труднощів оптимізації капіталу, ще одна проблема пов’язана з витратами, пов’язаними з управлінням каналом і ліквідністю, оскільки кожне з’єднання, закриття каналу тощо вимагає транзакції в ланцюжку. Бюджет безпеки біткойна залежить від значного збільшення комісії за транзакції, але якщо комісія за транзакції зросте до 30-60 доларів США, управління каналом буде надзвичайно дорогим у масштабі, а мережа Lightning Network без опіки може бути недоступною для значної частини населення світу. Розміщені гаманці Lightning наразі мають перевагу завдяки вбудованим заохоченням і, ймовірно, зростуть ще більше, оскільки комісії в ланцюжку зростуть, оскільки їх модель омнібусного облікового запису робить керування каналом набагато рідше. Спільнота наполегливо працює, щоб виправити це та забезпечити, щоб гаманці Lightning, які не підлягають зберіганню, залишалися першокласними громадянами в мережі, але чіткого рішення поки що немає.
Lightning Network ще має пройти довгий шлях, щоб стати простою, бездоганною та повністю абстрактною. Є ще багато крайніх випадків, і некеровані користувачі ще не насолоджувалися найкращим користувацьким досвідом. Однак багато проблем уже вирішено, і ще багато буде вирішено в найближчі кілька років. Тепер, коли блискавка спалахнула, чи може грім залишитися далеко позаду?