Пошук блискавичної ліквідності Bitcoin - журнал Bitcoin - Криптіх

Це редакційна стаття Шинобі, викладача-самоучки в біткойн-просторі та ведучого біткойн-подкастів, орієнтованого на технології.

Ігнорування проблем мережі Lightning і стеку протоколів, здається, сьогодні є дуже популярним заняттям. На даний момент це найбільш поширений і використовуваний другий рівень мережі біткойн, а також найшвидший з точки зору подальшого розвитку. Він також має багато недоліків, які легко прибрати під килим і обійти, враховуючи, що він дуже маленький і знаходиться на дуже ранній стадії прийняття. Але це не усуває ці проблеми і не змінює реальність того, що в набагато більшому масштабі і далі по кривій прийняття ці проблеми стають цілком реальними, що вимагають реальних масштабованих рішень.

Однією з проблем в основі Lightning є питання отримання ліквідності. Неможливо отримати кошти через Lightning Network без попереднього забезпечення отримання ліквідності від чужого вузла. Це фундаментальне та неминуче обмеження використання Lightning Network у спосіб, не пов’язаний із зберіганням. Очевидно, використовуючи такі речі, як Wallet of Satoshi або стандартний LNDHub Bluewallet (які є зберіганням), ви можете зламати цю проблему, але це лише тому, що хтось інший вирішив її за вас, а ви насправді не контролюєте свої кошти. Однак, займаючись самообслуговуванням, ви повинні справді вирішити проблему.

Коли Lightning Network вперше запустили в епоху і почали реально використовувати в епоху «#Reckless», цю проблему вирішували дуже неформально. По суті, це було вирішено через соціальні зв’язки; через прохання до знайомих або близьких друзів; через угоди про рукостискання «Привіт, друже, можеш надіслати мені трохи ліквідності, я щойно розкрутив свій вузол». Не було маркетплейсів, не було послуг, якими можна було користуватися, це були буквально просто друзі, які допомагали один одному. Навіть сьогодні через такі речі, як PLEBNETвеликий відсоток джерел ліквідності, що відбуваються в мережі, відбувається за допомогою таких неформальних соціальних домовленостей.

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

Наступний етап зростання у вирішенні цієї проблеми відбувся незабаром після того, як мережа запрацювала. Такі сервіси, як LNBIG, почали створювати сторінку, де люди могли запитувати вхідну ліквідність. Bitrefill почав пропонувати канали з отриманням ліквідності як послугу (і в процесі створив специфікацію «Турбоканал», яка дозволяє використовувати канал ще до того, як він буде підтверджений у ланцюжку). Coincharge, Voltage та багато інших компаній також пропонують подібні послуги. Сплачуючи комісію, ви можете просто змусити бізнес відкрити з вами канал, щоб забезпечити отримання ліквідності, щоб отримати гроші. Цей крок в еволюції стався для вирішення свого роду проблеми масштабування, оскільки не всі нові користувачі, які прийшли на борт, мали ті соціальні зв’язки, щоб отримати вхідну ліквідність. Навіть якби вони це зробили, люди мають лише стільки грошей, які вони можуть виділити на канали для людей, яких вони знають. Ви також не можете очікувати, що люди будуть сидіти цілий день, завжди будьте готові відкрити канали, коли людям потрібна ліквідність. Отже, у бізнесу є можливість втрутитися і вирішити проблему за певну плату.

У вас також є динаміка постачальників послуг блискавки (LSP), як-от Breez, які втручаються і самі надають певну кількість отриманої ліквідності для своїх користувачів. Однак це все ще стикається з такими ж загальними проблемами, як і пошук речей у людей, яких ви знаєте: у Breez лише стільки грошей, які вони можуть виділити своїм користувачам для отримання коштів. Вони оплачують маршрутизацію, будучи вузлом, до якого ви підключені, але в кінцевому підсумку вони зіткнуться з проблемою необхідності керувати обмеженою кількістю коштів у зростаючій базі користувачів. Це не є стійким назавжди.

Наступним типом вирішення цієї основної проблеми Lightning були фактичні ринки. Не бізнес, який продає вам власні кошти у формі приймальних потужностей, а ринок, куди кожен може прийти і запропонувати продати отриману ліквідність кожному, хто бажає її придбати. Два приклади цього рішення — аукціонний дім Lightning Lab «Lightning Pool» та маркетплейси Magma Amboss. Lightning Pool навіть забезпечує мінімальний період часу, протягом якого придбані канали повинні залишатися відкритими в ланцюжку через блокування часу CLTV. Це обидва способи, не пов’язані з зберіганням, для центральної сторони (Lightning Labs і Amboss), щоб зіставити людей, які хочуть продати, з тими, хто хоче купити вхідну ліквідність. Проблема в тому, що вони все ще залежать від централізованого фасилітатора, щоб зробити цю роботу. І Lightning Lab, і Amboss фактично стягують плату за участь у своїх аукціонах.

Останню категорію рішень цієї проблеми втілює Liquidity Ads CLN, децентралізований ринок для отримання ліквідності, побудований на основі каналів з подвійним фінансуванням (де обидві сторони каналу забезпечують ліквідність за рахунок фінансування замість одного). Liquidity Ads використовує протокол пліток Lightning Network, який рекламує загальнодоступні канали, доступні для маршрутизації платежів, щоб публічно розміщувати оголошення, які ви готові продати, отримуючи ліквідність. Так само, як Lightning Pool, він також забезпечує «час оренди», протягом якого канал повинен залишатися відкритим із ланцюжком блокування часу CLTV.

Отже, усі ці різні варіанти залишають у повітрі одне питання: як ми насправді хочемо підійти до вирішення цієї проблеми в довгостроковій перспективі та в масштабах? Це буквально неможливо отримувати кошти через Lightning Network без попереднього пошуку ліквідності. Це основне обмеження самого протоколу. Чи хочемо ми вирішити цю проблему на рівні самого протоколу, оскільки це те, де є поточні обмеження, чи ми хочемо спиратися на централізовані послуги та ринки для цього?

Коли справа доходить до цього, це питання мережевого ефекту та проблема курки чи яйця. Покупці хочуть йти туди, де є продавці, але продавці також хочуть йти туди, де є покупці. Якщо ми посилимося на централізовані ринки чи послуги, щоб вирішити цю проблему, то в кінцевому підсумку цей мережевий ефект буде посилюватися, і його стає все важче подолати за допомогою децентралізованих альтернатив, заснованих на протоколах. Тому це дуже важливе питання, яке зараз задають собі користувачі. Чи дозволимо ми повністю вирішити цей величезний недолік стеку протоколів Lightning централізованими бізнес-сервісами, чи спробуємо вирішити його на рівні самого протоколу?

Особисто я вважаю, що враховуючи потребу у вхідній ліквідності, абсолютно необхідною для використання протоколу у спосіб самозабезпечення, цю проблему слід вирішувати на рівні протоколу. І наостанок, децентралізоване вирішення проблеми на рівні протоколу все ще дозволяє поточним підприємствам і централізованим рішенням відкрито конкурувати, використовуючи цей протокол самостійно.

Це гостьовий пост від Shinobi. Висловлені думки є повністю їх власними і не обов’язково відображають думки BTC Inc або Журнал Bitcoin.

Source link