Звідки беруться ефекти мережі L2? Що робить L2 липким?

Автор: Алана Левін; Упорядник: Huohuo, народний блокчейн

Два роки тому розробники додатків зіткнулися з досить простим вибором, коли вирішували, де розгортати свої додатки: Ethereum, Solana, Cosmos або, можливо, якийсь інший ланцюжок рівня 1. Rollup ще не використовується, і мало хто чув термін «модульний стек». Відмінності між L1 (пропускна здатність, вартість тощо) очевидні, і їх відносно легко зрозуміти.

**Сьогодні все виглядає зовсім інакше. Розробники додатків стикаються з більшим вибором: L1, загальні зведення (Optimistic і zk), розширена інфраструктура IBC, постачальники зведених як послуг, ланцюжки додатків тощо. **

Більше варіантів викликає більше запитань, зокрема: чи мають команди розгортати загальні зведення чи створювати зведення для окремих програм? Якщо ви обираєте загальне зведення, який із них вибрати? Якщо вони підуть шляхом зведення програми, який пакет SDK/зведення як послугу використовувати? Який рівень доступності даних вибрати? Чи може EigenLayer допомогти? Як думати про секвенсори? Якщо вони вирішать піти шляхом OP Stack, чи залишиться барвистий сферичний емодзі в екосистемі суперланцюга Optimism? Ці питання складні.

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

1. Структура високого рівня

В основі рішення щодо зведення додатків лежить просте запитання: **якби додаток був у власному ланцюжку, чи користувалися б користувачі додатком? **Є два підмножини цього питання:

1) Чи більш імовірно, що користувачі використовуватимуть програму, якщо вона в окремій мережі?

2) Якщо програма знаходиться у власному ланцюжку, чи користувач однаково може використовувати програму?

Переваги згортання для окремих програм випливають із більшого контролю: Можливість компенсувати витрати на газ, обмежити перевантаження в ланцюжку, спричинені діяльністю інших програм, краще експериментувати з використанням токенів, досліджувати різні економічні структури (наприклад, інтегровані знижки на газ) , створення настроюваних середовищ виконання, впровадження засобів контролю доступу (наприклад, розгортання дозволів) тощо.

** Але цей додатковий контроль відбувається за рахунок підключення до більшої екосистеми. **Програми в спільному/універсальному ланцюжку можуть отримати доступ до ліквідності, яка вже є в цьому ланцюжку (наприклад, без додаткових мостів між ланцюжками), можливості комбінування з іншими програмами та користувачами, які вже присвятили увагу цьому ланцюжку. Побудова на основі загального ланцюга також вимагає менше внутрішньої інженерної роботи/накладних витрат, ніж програма, яка працює з власним ланцюгом.

Кращі засоби керування могли б покращити взаємодію з користувачем, якби вони були безкоштовними. Тож відповідь на основне запитання — чи будуть користувачі й надалі використовувати програму, якби вона була у власному ланцюжку — насправді залежить від того, наскільки суворим є компроміс між контролем і з’єднанням. **

2. Скільки підключень програма може дозволити собі втратити?

Зв’язки мають багато форм. Дві найважливіші: 1) увага і 2) капітал.

** Зверніть увагу на нативний розподіл. Якщо проект команди є першою справою, з якою користувачі взаємодіють, коли вони входять в екосистему, це переконливий аргумент для того, щоб додаток мав нативний дистрибутив. ** Програми для контролю уваги краще підходять для створення власного ланцюжка; користувач використовуватиме цю програму незалежно від того, у якій ланцюжку вона існує. На мій погляд, поточні приклади додатків, які мають рідну дистрибуцію, включають Mirror, Zora, Manifold, Sound.xyz і OnCyber. Існує також аргумент, що додатки без сильного розповсюдження можуть вирішувати запускати власні ланцюжки, щоб викликати інтерес.

Другою складовою «зв’язності» є капітал. Часто кошти, використані користувачами для однієї програми, повертаються з іншої програми в тій же екосистемі. Я називаю це «спільною ліквідністю», і її наслідки реальні. Ми бачили, як нові додатки вибирають одне зведення загального призначення над іншим через більшу кількість ETH, що передається в екосистему; існуючий капітал у екосистемі може допомогти усунути перешкоди для впровадження користувачами (замість того, щоб намагатися переконати користувачів увійти в нова екосистема). Ці міркування актуальні для будь-якої програми, яка вбудовує певну форму фінансіалізації у свій продукт. Приклади за межами чистого DeFi можуть включати збір статей NFT через Mirror, плату за «крадіжку» зображень на Stealcam або будь-що з функцією підказки в продукті.

**Втрата цього «фондового зв’язку» означає, що додаткам потрібно змусити користувачів припаркувати свій інвентар у мережі. ** Одна з причин може полягати в тому, що споживачі часто користуються додатком. Перехідний досвід є болючим, тому буде легше підтримувати належний запас коштів у мережі. Але ще переконливіше, ніж незадіяний інвентар, це надання користувачам можливостей, які приносять дохід. Це може виглядати як ланцюжкова форма прибутку, додаток, що створює суміжний продукт, який забезпечує прибутковість (наприклад, протокол кредитування Blur), або щось інше.

Наведені вище причини (увага та капітал) також пояснюють те, чому багато хто бачить онлайн-ігри як ідеальних кандидатів для згортання конкретних програм: вони є досить самодостатньою економікою, контролюють частку розуму споживачів і є сортуй і уникай перевантаження це категорія, яка є одночасно важливою для приємного користування.

Іншими словами, ігри в ланцюжку отримують переваги від високого ступеня контролю, і вони не мають істотного впливу, якщо вони ізольовані. Інші програми, які добре підходять для зведення додатків, можуть робити це шляхом субсидування транзакцій (наприклад, перші кілька транзакцій безкоштовні) або спочатку не вимагають оплати (наприклад, створений користувачами вміст у мережі, певні соціальні програми, мережі DePIN, тощо) Зведіть до мінімуму вимоги до початкового капіталу користувачів.

Звичайно, існують інші причини, чому проекти хочуть більше контролювати свою інфраструктуру. Наявність зведеного пакета дає дозвіл на розгортання або можливість запровадити вимоги перевірки користувачів (наприклад, KYC на секвенсорах, які належать/керуються мережею). Однак у цих випадках межа між зведеними базами даних і централізованими базами даних стає все менш чіткою.

3. Мінімізуйте втрату з'єднання

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

Економіка одиниці Rollups є ще однією сферою, де «зв’язок» має вплив. ** Комісія за транзакції L2 складається з двох факторів: 1) вартості публікації даних у L1 і 2) вартості, яку користувачі сплачують за включення. **Оператор зведення групує дані викликів для транзакцій, що дозволяє розподілити витрати на публікацію між користувачами - чим більше транзакцій, тим нижча середня вартість на користувача. Це також означає, що менш активні зведення можуть затримувати публікацію транзакцій на L1, доки вони не досягнуть достатньо великого розміру пакета. Наслідком цього є повільніший час завершення та погіршення взаємодії з користувачем. Здається, спільні замовники все частіше служать рівнями агрегації, де групування транзакцій із кількох менших зведень може допомогти створити життєздатну економіку одиниці для існування довгого хвоста.

4. Ми на переломній точці?

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

Але в останні місяці ми почали спостерігати перший приплив жителів. Lattice створив OpCraft, мережевий автономний світ, який підтримується власним зведенням. Такі проекти, як Lit Protocol і Synapse, оголосили про власні зведені пакети (хоча обидва більше орієнтовані на інфраструктуру, а не на програми). Zora запустила Zorachain. Останні розмови з більш зрілими командами прикладного рівня (особливо з тими, хто розглядає стратегії L2) почали досліджувати, чи підходять їм зведені програми.

Я припускаю, що справжня точка перелому настане через (принаймні) 6-12 місяців. ** Ігри та соціальні програми мають найбільш очевидну відповідність ринку продукту завдяки спеціальним пакетам програм: соціальні та ігрові програми значною мірою покладаються на індексування (і отримують значну вигоду, оскільки не потрібно конкурувати зі спільним станом), проблеми з замовленням (особливо в ігровому процесі) та Спеціальні функції (наприклад, безгазові транзакції) особливо корисні для споживчих продуктів, орієнтованих на розваги**. Багато з цих груп додатків ще знаходяться на стадії розробки. Зокрема, для розробки та випуску ігор можуть знадобитися роки.

Інший мій висновок полягає в тому, що привернення уваги є найважливішим фактором для менш фінансових програм. Наразі ця стаття визначала зведення програм як «одну програму на зведення». Але цей погляд може бути занадто вузьким. Можливо, декілька додатків вирішать сформувати колектив, об’єднати свою «увагу» та розпочати ланцюжок разом. Подібним чином ми можемо спостерігати, як велика програма вирішує побудувати власний ланцюжок і заохочувати інші програми до розгортання в ній – по суті, використовуючи власну програму для перевірки впровадження інфраструктури, яку вона хоче контролювати.

Нарешті, я дуже вірю, що ми побачимо більше зведених програм у майбутньому. Відбулося поширення проектів, що створюють інфраструктурні служби для зведених програм. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer тощо пропонують рішення з низьким рівнем підйому, щоб команди могли розпочати власний Rollup.

Espresso, Astria та SUAVE від Flashbots є одними з перших учасників секвенсорного простору. Витрати на налаштування зменшуються, а компроміс «підключення» стає менш серйозним. Обидва підкріплюють аргументи на користь усиновлення. **Але така велика кількість нових постачальників інфраструктури також означає, що команди додатків можуть витрачати час на вивчення різноманітних варіантів і випробування цих різних гравців перед тим, як вибрати переможця. **Знову ж таки, хоча є ознаки усиновлення, я думаю, що до переломного моменту залишилося кілька місяців.