Автор: Виктор Бунин, эксперт Coinbase Cloud Protocol Компилятор: Qianwen, ChainCatcher
Я некоторое время не использовал Lightning (позже названный «Lightning Network»).
В последний раз я работал над ним в 2019 году, когда вместе с Элизабет Старк и другими лидерами сообщества организовал первую конференцию Lightning Network в Берлине. С тех пор я провел большую часть своего времени, работая над другими протоколами, и хотя я все еще дружу с такими людьми, как Элизабет, мое понимание того, как на самом деле работает Lightning Network, ухудшилось. После повторного осмотра я понял, что это был не только я, но и большинство моих друзей.
Этот пост для тех, кто в последнее время не использовал Lightning Network. В нем будут обсуждаться неправильные представления, которые я или другие, которых я видел. Если я пропустил какие-либо хорошие моменты, пожалуйста, напишите мне в Твиттере.
**Заблуждение 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: Пользователи должны понимать и выбирать Биткойн и Lightning Network при отправке BTC. **
Должно быть, так было раньше. Но сейчас все по-другому. Теперь у них есть унифицированный QR-код, который аккуратно связывает сетевой адрес со счетом Lightning Network, чтобы отправляющий кошелек мог выбрать правильный маршрут. Откройте CashApp, перейдите на вкладку Биткойн. Обратите внимание, что, хотя Cash App поддерживает Lightning Network, выбрать Lightning Network нельзя. Это потому, что они используют единый QR-код.
Однако это не решает проблему единого баланса — баланс BTC пользователя по-прежнему может быть разделен внутри сети и в сети Lightning. Эту проблему можно до некоторой степени решить с помощью Submarinesswap и/или Splicing, но я считаю, что в долгосрочной перспективе пользователи даже не поймут, что это проблема, и не поймут, что Lightning Network существует, потому что кошелек и другие поставщики обрабатывают основные сложности, которые будут скрыты за плавным взаимодействием с пользователем.
**Миф №6: Lightning Network неэффективна с точки зрения капитала и поэтому нежизнеспособна. **
Это обсуждение деликатное, и я постараюсь быть максимально нейтральным.
Lightning Network использует модель ступицы и спицы. Часть сети от концентратора к концентратору отличается высокой эффективностью капиталовложений из-за высокого коэффициента «распределения капитала на единицу» больших каналов между биржами, кастодиальными кошельками, LSP и оптимальными узлами маршрутизации.
Однако там, где капитальная неэффективность сети Lightning находится на периферии — пользователи, не связанные с тюремным заключением. Для кастодиальных пользователей Lightning кошельки должны только поддерживать большие каналы с другими хабами и выполнять внутренний учет балансов пользователей. Для пользователей, не связанных с тюремным заключением, кошелек должен поддерживать отдельный открытый канал финансирования для каждого пользователя. Проблема заключается в том, как поддерживать непрерывное распределение ликвидности и управление ею по этим каналам.
Приведем конкретный пример: пользователь кошелька, не связанного с тюремным заключением, хочет отправить 0,1 BTC другу через сеть Lightning. Предполагая, что в канале между ними и поставщиком кошелька и каждым узлом на этом пути достаточно ликвидности, платеж будет успешным. Но теперь у кошелька есть проблема - у них есть 0,1 BTC в канале на их стороне, если пользователь не получит никакой оплаты (таким образом ребалансируя канал), эти 0,1 BTC будут простаивать там, что приведет к низкой неэффективности провайдера кошелька. На этом этапе поставщики кошельков должны решить, сохранять ли ликвидность или изымать ликвидность, закрывая каналы (что создает плохой пользовательский опыт) или соединяя каналы (которые невидимы для пользователей).
Для пользователей, не связанных с хранением, эта проблема предельной неэффективности капитала является очень раздражающей проблемой оптимизации, которая объективно хуже, чем модель, основанная на учетных записях, независимо от размера транзакции. Однако это не неразрешимая проблема. Пока это возможно, оно должно быть успешным, что также является девизом сообщества разработчиков биткойнов.
Помимо сложности оптимизации капитала, еще одна проблема связана с расходами, связанными с управлением каналами и ликвидностью, поскольку каждое соединение, закрытие канала и т. д. требует транзакции в сети. Бюджет безопасности Биткойна зависит от значительного увеличения транзакционных сборов, но если транзакционные сборы вырастут до 30-60 долларов, управление каналом станет непомерно дорогим в масштабе, а сеть Lightning Network, не подлежащая хранению, может быть недоступна для значительной части населения мира. Хостинговые кошельки Lightning в настоящее время имеют преимущество благодаря встроенным стимулам и, вероятно, будут расти еще больше по мере роста комиссий в цепочке, поскольку их модель омнибусной учетной записи делает управление каналом гораздо менее частым. Сообщество усердно работает над тем, чтобы исправить это и обеспечить, чтобы кошельки Lightning, не связанные с тюремным заключением, продолжали оставаться первоклассными гражданами в сети, но четкого решения пока нет.
Lightning Network еще предстоит пройти долгий путь, чтобы стать простой, цельной и полностью абстрактной. Есть еще много пограничных случаев, и неуправляемые пользователи еще не наслаждаются максимальным пользовательским интерфейсом. Однако многие проблемы уже решены, и еще больше будет решено в ближайшие несколько лет. Теперь, когда пришла молния, может ли гром быть далеко позади?
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Разъяснение 6 заблуждений о сети Lightning Биткойн
Автор: Виктор Бунин, эксперт Coinbase Cloud Protocol Компилятор: Qianwen, ChainCatcher
Я некоторое время не использовал Lightning (позже названный «Lightning Network»).
В последний раз я работал над ним в 2019 году, когда вместе с Элизабет Старк и другими лидерами сообщества организовал первую конференцию Lightning Network в Берлине. С тех пор я провел большую часть своего времени, работая над другими протоколами, и хотя я все еще дружу с такими людьми, как Элизабет, мое понимание того, как на самом деле работает Lightning Network, ухудшилось. После повторного осмотра я понял, что это был не только я, но и большинство моих друзей.
Этот пост для тех, кто в последнее время не использовал Lightning Network. В нем будут обсуждаться неправильные представления, которые я или другие, которых я видел. Если я пропустил какие-либо хорошие моменты, пожалуйста, напишите мне в Твиттере.
**Заблуждение 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: Пользователи должны понимать и выбирать Биткойн и Lightning Network при отправке BTC. **
Должно быть, так было раньше. Но сейчас все по-другому. Теперь у них есть унифицированный QR-код, который аккуратно связывает сетевой адрес со счетом Lightning Network, чтобы отправляющий кошелек мог выбрать правильный маршрут. Откройте CashApp, перейдите на вкладку Биткойн. Обратите внимание, что, хотя Cash App поддерживает Lightning Network, выбрать Lightning Network нельзя. Это потому, что они используют единый QR-код.
Однако это не решает проблему единого баланса — баланс BTC пользователя по-прежнему может быть разделен внутри сети и в сети Lightning. Эту проблему можно до некоторой степени решить с помощью Submarinesswap и/или Splicing, но я считаю, что в долгосрочной перспективе пользователи даже не поймут, что это проблема, и не поймут, что Lightning Network существует, потому что кошелек и другие поставщики обрабатывают основные сложности, которые будут скрыты за плавным взаимодействием с пользователем.
**Миф №6: Lightning Network неэффективна с точки зрения капитала и поэтому нежизнеспособна. **
Это обсуждение деликатное, и я постараюсь быть максимально нейтральным.
Lightning Network использует модель ступицы и спицы. Часть сети от концентратора к концентратору отличается высокой эффективностью капиталовложений из-за высокого коэффициента «распределения капитала на единицу» больших каналов между биржами, кастодиальными кошельками, LSP и оптимальными узлами маршрутизации.
Однако там, где капитальная неэффективность сети Lightning находится на периферии — пользователи, не связанные с тюремным заключением. Для кастодиальных пользователей Lightning кошельки должны только поддерживать большие каналы с другими хабами и выполнять внутренний учет балансов пользователей. Для пользователей, не связанных с тюремным заключением, кошелек должен поддерживать отдельный открытый канал финансирования для каждого пользователя. Проблема заключается в том, как поддерживать непрерывное распределение ликвидности и управление ею по этим каналам.
Приведем конкретный пример: пользователь кошелька, не связанного с тюремным заключением, хочет отправить 0,1 BTC другу через сеть Lightning. Предполагая, что в канале между ними и поставщиком кошелька и каждым узлом на этом пути достаточно ликвидности, платеж будет успешным. Но теперь у кошелька есть проблема - у них есть 0,1 BTC в канале на их стороне, если пользователь не получит никакой оплаты (таким образом ребалансируя канал), эти 0,1 BTC будут простаивать там, что приведет к низкой неэффективности провайдера кошелька. На этом этапе поставщики кошельков должны решить, сохранять ли ликвидность или изымать ликвидность, закрывая каналы (что создает плохой пользовательский опыт) или соединяя каналы (которые невидимы для пользователей).
Для пользователей, не связанных с хранением, эта проблема предельной неэффективности капитала является очень раздражающей проблемой оптимизации, которая объективно хуже, чем модель, основанная на учетных записях, независимо от размера транзакции. Однако это не неразрешимая проблема. Пока это возможно, оно должно быть успешным, что также является девизом сообщества разработчиков биткойнов.
Помимо сложности оптимизации капитала, еще одна проблема связана с расходами, связанными с управлением каналами и ликвидностью, поскольку каждое соединение, закрытие канала и т. д. требует транзакции в сети. Бюджет безопасности Биткойна зависит от значительного увеличения транзакционных сборов, но если транзакционные сборы вырастут до 30-60 долларов, управление каналом станет непомерно дорогим в масштабе, а сеть Lightning Network, не подлежащая хранению, может быть недоступна для значительной части населения мира. Хостинговые кошельки Lightning в настоящее время имеют преимущество благодаря встроенным стимулам и, вероятно, будут расти еще больше по мере роста комиссий в цепочке, поскольку их модель омнибусной учетной записи делает управление каналом гораздо менее частым. Сообщество усердно работает над тем, чтобы исправить это и обеспечить, чтобы кошельки Lightning, не связанные с тюремным заключением, продолжали оставаться первоклассными гражданами в сети, но четкого решения пока нет.
Lightning Network еще предстоит пройти долгий путь, чтобы стать простой, цельной и полностью абстрактной. Есть еще много пограничных случаев, и неуправляемые пользователи еще не наслаждаются максимальным пользовательским интерфейсом. Однако многие проблемы уже решены, и еще больше будет решено в ближайшие несколько лет. Теперь, когда пришла молния, может ли гром быть далеко позади?