Два роки тому розробники додатків зіткнулися з досить простим вибором, коли вирішували, на якому ланцюжку розгорнути свою програму: Ethereum, Solana, Cosmos чи інший блокчейн рівня 1. На той момент Rollup ще не запустив основну мережу, і мало хто чув про термін «модульний стек». Відмінності між рівнями L1 (пропускна здатність, комісія тощо) очевидні та відносно легкі для розуміння.
Сьогодні все виглядає зовсім інакше. Розробники додатків стикаються з більшим вибором: L1, зведений пакет загального призначення (Optimistic і zk), інфраструктура IBC, зведений постачальник послуг, AppChain тощо. Більше варіантів викликає більше запитань: чи мають команди розгортати програми для загальних зведень чи створювати зведення для окремих програм. Якщо вони вибирають загальний Rollup, який вибрати; якщо вони вибирають маршрут Rollup програми, який SDK/Rollup-as-a-service використовувати, який рівень доступності даних вибрати, чи може EigenLayer допомогти, як думати про секвенсори; якщо вони обирають шлях OP Stack, чи зможе він зайняти місце в екосистемі суперланцюга Optimism.
Щоб звузити проблему, у цій статті буде прийнято структуру програми, уже розгорнутої на Ethereum, яка бажає масштабуватися в екосистемі Ethereum. Отже, ця стаття буде зосереджена на дереві рішень, з якими стикаються команди програм, коли вирішують, чи запускати власне зведення, які типи програм особливо підходять для певних типів інфраструктури, і коли, я думаю, ми можемо досягти переломної точки прийняття.
Фреймворк високого рівня
В основі рішення щодо зведення додатків насправді лежить просте запитання: якби додаток було створено на власному ланцюжку, чи користувалися б ним користувачі? Подальший розвиток - два питання:
Чи ймовірніше, що користувачі використовуватимуть програму, якщо вона знаходиться у власній мережі?
Якщо програма знаходиться у власному ланцюжку, чи будуть користувачі використовувати її також?
Переваги зведених програм для окремих програм полягають у кращому контролі: можливість абстрагувати витрати на газ, обмежити перевантаження в ланцюжку, спричинені іншою діяльністю програми, краще експериментувати з використанням токенів, досліджувати різні економічні структури (наприклад, знижки на газ), будувати Налаштувати середовище виконання, запровадити засоби контролю доступу (наприклад, розгортання дозволів) тощо.
Але ціною цього додаткового контролю є втрата зв’язку з ширшою екосистемою. Програми в універсальному ланцюжку мають доступ до ліквідності, яка вже є в цьому ланцюжку (наприклад, немає потреби в додаткових мостах між ланцюжками), можливість комбінування з іншими програмами та увагу користувачів у ланцюжку. Порівняно з додатками, які запускають власні ланцюжки, створення на основі загального ланцюга також економить багато інженерних витрат.
Кращий контроль міг би покращити роботу користувача, якби він був безкоштовним. Тож відповідь на головне питання — чи будуть користувачі продовжувати використовувати програму, якби вона була у власному ланцюжку — насправді залежить від цього компромісу між контролем і підключенням.
**Скільки підключення може пожертвувати програма? **
Зв’язки бувають у багатьох формах, дві найважливіші: 1) увага та 2) капітал.
Увага пов'язана з рідним спілкуванням. Якщо проект команди є першим проектом, з яким користувачі взаємодіють, коли входять в екосистему, тоді програма є природно вірусною. Програми, які можуть привернути увагу, краще підходять для запуску власної мережі; користувачі використовуватимуть програму незалежно від того, до якої мережі вона входить. На мою думку, поточні програми з нативним розповсюдженням включають Mirror, Zora, Manifold, Sound.xyz і OnCyber. Існує також аргумент, що додатки без сильного розповсюдження можуть вирішувати запускати власні ланцюги, щоб викликати інтерес користувачів (але я вважаю це менш переконливим, якщо багато ланцюгів йдуть цим шляхом одночасно).
Другою формою зв'язку є капітал. Часто кошти, які користувачі розміщують в одній програмі, передаються з іншої програми в тій же екосистемі. Я називаю це «спільною ліквідністю», і її наслідки реальні. Велика кількість нових додатків вибирають Universal Rollup через велику кількість ETH, підключених до цієї екосистеми, а наявний капітал у екосистемі може допомогти усунути перешкоди для впровадження користувачами (замість того, щоб намагатися переконати користувачів увійти в нову екосистему). Ці фактори є міркуваннями для будь-якої програми, яка вбудовує певну форму фінансування у свій продукт. Приклади за межами DeFi можуть включати: збір документів NFT через Mirror, плату за «крадіжку» зображень на Stealcam або будь-що з функцією підказки в продукті.
Втрата цього «з’єднання з фондами» означає, що програми повинні змушувати користувачів зберігати кошти в ланцюжку. Одна з причин може полягати в тому, що споживачі часто користуються додатком, зрештою, перехресні ланцюги болючі, тому буде легше підтримувати здоровий запас коштів у ланцюзі. Але ще більш переконливим, ніж незадіяні кошти, є надання користувачам можливості генерувати прибуток. Це виглядає як прибутковість у формі ланцюжків-нативів, додатків, що створюють суміжні продукти, які забезпечують прибутковість (наприклад, протокол кредитування Blur) тощо.
Увага та капітал також є причиною того, чому багато хто бачить онлайн-ігри як ідеальних кандидатів для згортання конкретних програм: вони є досить самодостатніми економічними засобами та значною мірою покладаються на безперебійну роботу користувача. Іншими словами, онлайн-ігри виграють від високого ступеня контролю та не зазнають значних втрат, якщо вони залишаються сиротами. Інші програми, які добре підходять для Rollup, можуть робити це, субсидуючи транзакції (наприклад, перші кілька транзакцій безкоштовні) або не вимагаючи оплати після входу (наприклад, створений користувачами вміст у мережі, певні соціальні програми, мережі DePIN тощо). Мінімізує вимоги до початкового капіталу користувача.
Звичайно, існують інші причини, чому проекти хочуть більше контролювати свою інфраструктуру. Власні зведені пакети дають змогу розгортати дозволи та перевіряти користувачів (наприклад, KYC для секвенсорів, які належать/керуються мережею). Однак це також призводить до стирання межі між базами даних Rollup і централізованими базами даних.
Мінімізація втрати з’єднання
У міру покращення рішень щодо сумісності компроміс між підключенням і керуванням стає менш важливим. Мости та секвенсори часто є критичною інфраструктурою, яка обговорюється. Вони певною мірою схожі тим, що обидва забезпечують спосіб для транзакцій в одному ланцюжку впливати на транзакції в іншому ланцюжку. Мости роблять це, передаючи повідомлення або вмикаючи передачу активів, спільні замовники роблять це, приймаючи та впорядковуючи транзакції з кількох ланцюжків. І спільні замовники, і мости необхідні для атомарної компонування - замовник гарантовано містить кілька (перехресних) транзакцій у блоці, і для фактичного виконання цих транзакцій зазвичай потрібен міст.
Економіка одиниці Rollups є ще однією сферою, де «зв’язок» має вплив. Плата за трансакцію L2 складається з двох частин: 1) вартість публікації даних на L1 і 2) вартість, яку користувачі сплачують за транзакцію. Зведення пакетно збирає дані викликів транзакцій, щоб витрати на публікацію могли розподілятися між користувачами: що більше транзакцій, то нижча середня вартість на користувача. Це також означає, що менш активні зведені пакети можуть затримувати публікацію транзакцій на L1, доки вони не отримають достатньо великий пакет транзакцій. Наслідком цього є повільніший час фіналізації та поганий досвід роботи з користувачем. Здається, спільні замовники все частіше служать рівнями агрегації, де групування транзакцій з кількох менших зведень може допомогти створити життєздатну економіку одиниць для довгохвостих людей.
**Ми на переломній точці? **
Ідея ланцюжків додатків і зведених додатків не нова. Довгий час, однак, було відчуття, що це житловий район, що будується: будувалося багато інфраструктури, але без мешканців. В останні місяці ми почали спостерігати наплив перших мешканців. Lattice створив OpCraft, автономний світ у ланцюжку, який підтримується власним зведенням; Lit Protocol і Synapse оголосили про власний зведений пакет (хоча обидва проекти більше орієнтовані на інфраструктуру, ніж на програми); Zora запустила Zorachain. Останні розмови зі зрілими командами додатків (особливо тими, хто розглядає стратегії L2) почали досліджувати, чи підходять їм зведені додатки.
Я припускаю, що справжня точка перелому настане через (принаймні) 6-12 місяців. Ігри та соціальні додатки мають найбільш очевидну відповідність ринку продукту завдяки спеціальним зведеним програмам: як соціальні, так і ігри значною мірою покладаються на індексування, проблеми з упорядкуванням (особливо в ігровому процесі) і спеціальні функції (наприклад, транзакції без газу) для рекреаційного споживання. важливо. Багато команд програм знаходяться на стадії розробки, особливо ігор, розробка та випуск яких може тривати роками.
Інший мій висновок полягає в тому, що для менш фінансових програм найважливішим є привернення уваги. Наразі ця стаття визначала зведені програми як «одну програму на зведене». Але цей погляд може бути занадто вузьким. Можливо, існує кілька додатків, які утворюють колектив, щоб разом почати ланцюжок. Подібним чином ми бачимо, як додаток створює власний ланцюжок і заохочує інші додатки розгортати його поверх нього.
Зрештою, я твердо вірю, що в майбутньому ми побачимо більше зведених пакетів. Проекти, що створюють інфраструктурні послуги для зведених додатків, зростатимуть. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer тощо надають командам додатків рішення з низьким порогом для запуску власного Rollup. Espresso, Astria та SUAVE від Flashbots були одними з перших дослідників у просторі секвенсорів. Початкові витрати зменшуються, а компроміс «підключення» стає менш важливим. Але така велика кількість нових постачальників інфраструктури також означає, що командам додатків може знадобитися час, щоб зрозуміти різні варіанти, і між цими гравцями спалахне війна. Знову ж таки, хоча є ознаки усиновлення, я думаю, що до переломного моменту залишилося кілька місяців.
Дякуємо Devloper, Джилл Гантер, Кайлу Самані, Джейсону Майеру, Джему Озеру та Віктору Буніну за їхні відгуки, коментарі та розмови, які допомогли розвинути багато з цих ідей.
Переглянути оригінал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
За тенденції модульності, чи повинна програма будувати власний ланцюжок?
Автор: Алана Левін; укладач: Луффі, Foresight News
Два роки тому розробники додатків зіткнулися з досить простим вибором, коли вирішували, на якому ланцюжку розгорнути свою програму: Ethereum, Solana, Cosmos чи інший блокчейн рівня 1. На той момент Rollup ще не запустив основну мережу, і мало хто чув про термін «модульний стек». Відмінності між рівнями L1 (пропускна здатність, комісія тощо) очевидні та відносно легкі для розуміння.
Сьогодні все виглядає зовсім інакше. Розробники додатків стикаються з більшим вибором: L1, зведений пакет загального призначення (Optimistic і zk), інфраструктура IBC, зведений постачальник послуг, AppChain тощо. Більше варіантів викликає більше запитань: чи мають команди розгортати програми для загальних зведень чи створювати зведення для окремих програм. Якщо вони вибирають загальний Rollup, який вибрати; якщо вони вибирають маршрут Rollup програми, який SDK/Rollup-as-a-service використовувати, який рівень доступності даних вибрати, чи може EigenLayer допомогти, як думати про секвенсори; якщо вони обирають шлях OP Stack, чи зможе він зайняти місце в екосистемі суперланцюга Optimism.
Щоб звузити проблему, у цій статті буде прийнято структуру програми, уже розгорнутої на Ethereum, яка бажає масштабуватися в екосистемі Ethereum. Отже, ця стаття буде зосереджена на дереві рішень, з якими стикаються команди програм, коли вирішують, чи запускати власне зведення, які типи програм особливо підходять для певних типів інфраструктури, і коли, я думаю, ми можемо досягти переломної точки прийняття.
Фреймворк високого рівня
В основі рішення щодо зведення додатків насправді лежить просте запитання: якби додаток було створено на власному ланцюжку, чи користувалися б ним користувачі? Подальший розвиток - два питання:
Переваги зведених програм для окремих програм полягають у кращому контролі: можливість абстрагувати витрати на газ, обмежити перевантаження в ланцюжку, спричинені іншою діяльністю програми, краще експериментувати з використанням токенів, досліджувати різні економічні структури (наприклад, знижки на газ), будувати Налаштувати середовище виконання, запровадити засоби контролю доступу (наприклад, розгортання дозволів) тощо.
Але ціною цього додаткового контролю є втрата зв’язку з ширшою екосистемою. Програми в універсальному ланцюжку мають доступ до ліквідності, яка вже є в цьому ланцюжку (наприклад, немає потреби в додаткових мостах між ланцюжками), можливість комбінування з іншими програмами та увагу користувачів у ланцюжку. Порівняно з додатками, які запускають власні ланцюжки, створення на основі загального ланцюга також економить багато інженерних витрат.
Кращий контроль міг би покращити роботу користувача, якби він був безкоштовним. Тож відповідь на головне питання — чи будуть користувачі продовжувати використовувати програму, якби вона була у власному ланцюжку — насправді залежить від цього компромісу між контролем і підключенням.
**Скільки підключення може пожертвувати програма? **
Зв’язки бувають у багатьох формах, дві найважливіші: 1) увага та 2) капітал.
Увага пов'язана з рідним спілкуванням. Якщо проект команди є першим проектом, з яким користувачі взаємодіють, коли входять в екосистему, тоді програма є природно вірусною. Програми, які можуть привернути увагу, краще підходять для запуску власної мережі; користувачі використовуватимуть програму незалежно від того, до якої мережі вона входить. На мою думку, поточні програми з нативним розповсюдженням включають Mirror, Zora, Manifold, Sound.xyz і OnCyber. Існує також аргумент, що додатки без сильного розповсюдження можуть вирішувати запускати власні ланцюги, щоб викликати інтерес користувачів (але я вважаю це менш переконливим, якщо багато ланцюгів йдуть цим шляхом одночасно).
Другою формою зв'язку є капітал. Часто кошти, які користувачі розміщують в одній програмі, передаються з іншої програми в тій же екосистемі. Я називаю це «спільною ліквідністю», і її наслідки реальні. Велика кількість нових додатків вибирають Universal Rollup через велику кількість ETH, підключених до цієї екосистеми, а наявний капітал у екосистемі може допомогти усунути перешкоди для впровадження користувачами (замість того, щоб намагатися переконати користувачів увійти в нову екосистему). Ці фактори є міркуваннями для будь-якої програми, яка вбудовує певну форму фінансування у свій продукт. Приклади за межами DeFi можуть включати: збір документів NFT через Mirror, плату за «крадіжку» зображень на Stealcam або будь-що з функцією підказки в продукті.
Втрата цього «з’єднання з фондами» означає, що програми повинні змушувати користувачів зберігати кошти в ланцюжку. Одна з причин може полягати в тому, що споживачі часто користуються додатком, зрештою, перехресні ланцюги болючі, тому буде легше підтримувати здоровий запас коштів у ланцюзі. Але ще більш переконливим, ніж незадіяні кошти, є надання користувачам можливості генерувати прибуток. Це виглядає як прибутковість у формі ланцюжків-нативів, додатків, що створюють суміжні продукти, які забезпечують прибутковість (наприклад, протокол кредитування Blur) тощо.
Увага та капітал також є причиною того, чому багато хто бачить онлайн-ігри як ідеальних кандидатів для згортання конкретних програм: вони є досить самодостатніми економічними засобами та значною мірою покладаються на безперебійну роботу користувача. Іншими словами, онлайн-ігри виграють від високого ступеня контролю та не зазнають значних втрат, якщо вони залишаються сиротами. Інші програми, які добре підходять для Rollup, можуть робити це, субсидуючи транзакції (наприклад, перші кілька транзакцій безкоштовні) або не вимагаючи оплати після входу (наприклад, створений користувачами вміст у мережі, певні соціальні програми, мережі DePIN тощо). Мінімізує вимоги до початкового капіталу користувача.
Звичайно, існують інші причини, чому проекти хочуть більше контролювати свою інфраструктуру. Власні зведені пакети дають змогу розгортати дозволи та перевіряти користувачів (наприклад, KYC для секвенсорів, які належать/керуються мережею). Однак це також призводить до стирання межі між базами даних Rollup і централізованими базами даних.
Мінімізація втрати з’єднання
У міру покращення рішень щодо сумісності компроміс між підключенням і керуванням стає менш важливим. Мости та секвенсори часто є критичною інфраструктурою, яка обговорюється. Вони певною мірою схожі тим, що обидва забезпечують спосіб для транзакцій в одному ланцюжку впливати на транзакції в іншому ланцюжку. Мости роблять це, передаючи повідомлення або вмикаючи передачу активів, спільні замовники роблять це, приймаючи та впорядковуючи транзакції з кількох ланцюжків. І спільні замовники, і мости необхідні для атомарної компонування - замовник гарантовано містить кілька (перехресних) транзакцій у блоці, і для фактичного виконання цих транзакцій зазвичай потрібен міст.
Економіка одиниці Rollups є ще однією сферою, де «зв’язок» має вплив. Плата за трансакцію L2 складається з двох частин: 1) вартість публікації даних на L1 і 2) вартість, яку користувачі сплачують за транзакцію. Зведення пакетно збирає дані викликів транзакцій, щоб витрати на публікацію могли розподілятися між користувачами: що більше транзакцій, то нижча середня вартість на користувача. Це також означає, що менш активні зведені пакети можуть затримувати публікацію транзакцій на L1, доки вони не отримають достатньо великий пакет транзакцій. Наслідком цього є повільніший час фіналізації та поганий досвід роботи з користувачем. Здається, спільні замовники все частіше служать рівнями агрегації, де групування транзакцій з кількох менших зведень може допомогти створити життєздатну економіку одиниць для довгохвостих людей.
**Ми на переломній точці? **
Ідея ланцюжків додатків і зведених додатків не нова. Довгий час, однак, було відчуття, що це житловий район, що будується: будувалося багато інфраструктури, але без мешканців. В останні місяці ми почали спостерігати наплив перших мешканців. Lattice створив OpCraft, автономний світ у ланцюжку, який підтримується власним зведенням; Lit Protocol і Synapse оголосили про власний зведений пакет (хоча обидва проекти більше орієнтовані на інфраструктуру, ніж на програми); Zora запустила Zorachain. Останні розмови зі зрілими командами додатків (особливо тими, хто розглядає стратегії L2) почали досліджувати, чи підходять їм зведені додатки.
Я припускаю, що справжня точка перелому настане через (принаймні) 6-12 місяців. Ігри та соціальні додатки мають найбільш очевидну відповідність ринку продукту завдяки спеціальним зведеним програмам: як соціальні, так і ігри значною мірою покладаються на індексування, проблеми з упорядкуванням (особливо в ігровому процесі) і спеціальні функції (наприклад, транзакції без газу) для рекреаційного споживання. важливо. Багато команд програм знаходяться на стадії розробки, особливо ігор, розробка та випуск яких може тривати роками.
Інший мій висновок полягає в тому, що для менш фінансових програм найважливішим є привернення уваги. Наразі ця стаття визначала зведені програми як «одну програму на зведене». Але цей погляд може бути занадто вузьким. Можливо, існує кілька додатків, які утворюють колектив, щоб разом почати ланцюжок. Подібним чином ми бачимо, як додаток створює власний ланцюжок і заохочує інші додатки розгортати його поверх нього.
Зрештою, я твердо вірю, що в майбутньому ми побачимо більше зведених пакетів. Проекти, що створюють інфраструктурні послуги для зведених додатків, зростатимуть. Caldera, Sovereign SDK, Eclipse, Dymension, Conduit, AltLayer тощо надають командам додатків рішення з низьким порогом для запуску власного Rollup. Espresso, Astria та SUAVE від Flashbots були одними з перших дослідників у просторі секвенсорів. Початкові витрати зменшуються, а компроміс «підключення» стає менш важливим. Але така велика кількість нових постачальників інфраструктури також означає, що командам додатків може знадобитися час, щоб зрозуміти різні варіанти, і між цими гравцями спалахне війна. Знову ж таки, хоча є ознаки усиновлення, я думаю, що до переломного моменту залишилося кілька місяців.
Дякуємо Devloper, Джилл Гантер, Кайлу Самані, Джейсону Майеру, Джему Озеру та Віктору Буніну за їхні відгуки, коментарі та розмови, які допомогли розвинути багато з цих ідей.