Якщо майбутнє складається з ончейн-економіки тисяч згортань, ми точно знаходимося на правильному графіку в сьогоденні. Від стека Optimism і комплекту для розробки ланцюжків Polygon до Caldera і Stackr, за останні місяці на ринок з’явилися різноманітні фреймворки Rollup і постачальники Rollups-as-a-Service (RaaS). Ці фреймворки пропонують модульні (часто з відкритим вихідним кодом) кодові бази для різних компонентів зведення, що дозволяє розробникам вибирати з безлічі настроюваних параметрів для кожного рівня стеку.

Але як ці постачальники накопичують вартість? Або вони взагалі накопичують якусь цінність? як нещодавно стверджував Ніл Сомані у своїй доповіді «Рішення RaaS йдуть до нуля» на Modular Summit.

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

Rollups проти Rollup Framework проти RaaS

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

Платформа зведення — це попередньо створена кодова база, яка реалізує основні компоненти зведення. Замість того, щоб створювати зведення з нуля, розробники можуть використовувати ці існуючі кодові бази (часто упаковані як SDK) і налаштувати їх відповідно до своїх конкретних потреб. Приклади фреймворків зведення з відкритим кодом включають OP Stack і Arbitrum Orbit.

Протоколи Rollups-as-a-Service або RaaS — це оболонки без коду, створені на основі існуючих фреймворків зведення. Вони дозволяють розробникам швидко розгортати зведення з нуля, вибираючи спеціальні функції зі спадних меню. Компанії RaaS часто займаються послідовністю розгортання зведених пакетів і пропонують додаткові консультаційні послуги.

Куди йдуть гроші

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

1.Виконання. Цей рівень виконує транзакції, застосовуючи функцію переходу стану (STF) до наявного стану зведення. Залежно від того, наскільки «централізованим» є зведення, вузол виконання може нести низку обов’язків від замовлення транзакцій і їх виконання до публікації їх на L1 і створення доказів шахрайства/валідності.

Рівень виконання — це рівень, який звертається до користувача, де гроші надходять у стек зведених даних. З користувачів стягується комісія за транзакцію (газ), яка зазвичай є надбавкою до різних витрат, які має сплатити рівень виконання (про це пізніше). Цей рівень також може отримувати додаткову цінність від користувачів, упорядковуючи транзакції певним чином (також відомий як MEV: максимальна витягувана вартість).

Розбивка рівня виконання, керованого централізованим секвенсором зведення. Його обов’язки включають: замовлення транзакцій, публікацію даних транзакцій на рівні DA, створення доказів, публікацію доказів і змін стану на рівні розрахунків

Розбивка рівня виконання, керованого централізованим секвенсором зведення. Його обов’язки включають: замовлення транзакцій, публікацію даних транзакцій на рівні DA, створення доказів, публікацію доказів і змін стану на рівні розрахунків

Розбивка рівня виконання, керованого централізованим секвенсором зведення. Його обов’язки включають: замовлення транзакцій, публікацію даних транзакцій на рівні DA, створення доказів, публікацію доказів і змін стану на рівні розрахунків

2. Розрахунок – це включає перевірку дійсності/доказів шахрайства та «визначення» канонічного стану зведення (у випадку зведення смарт-контрактів). Зазвичай розрахунками керує уніфікований рівень високого рівня безпеки, як-от Ethereum. Зведені фреймворки також можуть створювати власний шар розрахунків.

Розрахунок не є дуже високим рівнем захоплення вартості стека, оскільки витрати на перевірку зазвичай мізерні. Optimism платить Ethereum лише ~5 доларів на день за розрахунок. Конкурентний рівень розрахунків коштував би ще дешевше. (як також зазначено в розділі «Зведення як послуга скорочується до нуля»)

3. Доступність даних - DA включає трансляцію замовлених даних транзакції до решти мережі (також іноді називається публікацією даних). Це гарантує, що будь-хто може без дозволу реконструювати стан зведення, просто застосовуючи широкомовні дані транзакції до деякого попередньо завершеного стану.

Витрати на DA складають основну частину всіх витрат на зведення. Розміщення даних на високозахищеному рівні, як-от Ethereum, може бути досить дорогим. Дешевші та швидші альтернативи DA активно розробляються за допомогою таких протоколів, як Celestia, Avail і EigenDA. Зведені структури також можуть розглянути можливість створення власного рівня DA, але фрагментований DA має високі витрати на початкове завантаження та ускладнює взаємодію.

Потік цінностей високого рівня

Це може допомогти розглядати рівень виконання як модель B2C, а рівні Settlement і DA як моделі B2B:

Рівень виконання купує простір блоків у рівня DA та продає свої послуги виконання безпосередньо кінцевому користувачеві (клієнту). Він також купує послуги верифікації та зв’язку з рівня розрахунків

Рівень DA продає простір блоків іншому бізнесу – рівня виконання

Рівень розрахунків надає послуги з розрахунків іншому бізнесу – рівня виконання

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

Рівень виконання: економічна модель B2C

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

Дохід: вхідну вартість можна класифікувати наступним чином:

Витрати на газ, сплачені кінцевими споживачами за транзакцію

Внутрішньодоменний MEV

Міждоменний MEV (якщо структура забезпечує послідовність для кількох зведень на одному рівні DA. Інакше може бути важко видобути)

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

Витрати. Відтоки вартості з рівня виконання такі:

• Операційні витрати вузла

• Витрати на виконання (обчислення).

• Витрати на підтвердження (дійсність/докази шахрайства).

• Витрати на публікацію даних (змінна залежно від перевантаження на рівні DA)

Джерело: Understanding Rollup Value Accural by Sanjay Shah | Електричний капітал

Часто всі обов’язки рівня виконання покладаються на один централізований вузол секвенсора. Цей єдиний вузол накопичує весь дохід від користувачів і відповідає за оплату DA та витрат на розрахунки. В інший час налаштування можуть мати різні вузли для різних обов’язків:

• Секвенсори впорядковують транзакції та публікують дані на рівні DA. Вони «заробляють» комісію за транзакції, яку сплачують користувачі, і оплачують накладні витрати на послідовність і витрати на публікацію даних. Секвенування також можна виконати за допомогою попередньо вибраного набору секвенсорів або децентралізованих секвенсорів, таких як Espresso. Секвенсори також відповідають за розміщення змін стану на рівні розрахунку та сплату витрат на розрахунки
• Вузли перевірки відповідають за створення доказів. Це може бути центральний прувер або децентралізований набір вузлів перевірки. Їх витрати включають накладні витрати на створення доказів. Залежно від налаштувань, перевірки або «продають» докази секвенсору, або публікують їх безпосередньо на рівні розрахунку
• Зведення також може мати інші повні вузли (або вузли з повною перевіркою), які виконують усі пакети транзакцій і підтримують канонічний стан зведення. Ці повні вузли не обов’язково накопичують будь-який прямий дохід, але опосередковано фіксують цінність, утримуючи власний токен газу зведення

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

Тоді постає питання: якщо рівень виконання забезпечує найбільше значення, який учасник стека найкраще позиціонується для його захоплення?

Кожен, хто керує вузлом секвенування та виконує різноманітні дії, пов’язані з ним!

Це може бути сама команда зведення. Або, як згадувалося на початку статті, постачальники RaaS часто обробляють послідовність для зведених пакетів, які розгортаються з їх допомогою. Фактично, це більша частина доходу провайдерів RaaS.

(Як) RaaS заробляє гроші?

Є 3 основні області, які RaaS може отримати цінність:

Хостинг секвенсора: постачальник RaaS запускає секвенсор і пов’язані дії для зведення. Це розподіл праці, коли команда згортання вносить інновації (додаток, який вони створюють), а постачальник RaaS робить усе інше. Секвенсор впорядковує транзакції, розміщує дані на L1 і створює докази, якщо/коли потрібно

Додаткова інфра: дослідники блоків, мости тощо.

Спеціальна підтримка: консультування та партнерство щодо інфра-рішень (як послідовність, MEV тощо) + інша технічна підтримка

RaaS подібний до традиційного бізнесу B2B SaaS, де бізнес може стягувати зі своїх клієнтів фіксовану або гібридну комісію на основі придбаних послуг і використання (наприклад, кількість транзакцій кінцевих користувачів для зведення).

RaaS також може забезпечити інтеграцію зі спільним секвенсором, таким як Espresso. Однак у цьому випадку вони втратили б доходи від секвенсора, який становить основну частину прибутку RaaS. Таким чином, ці партнерства вимагають договірного розподілу прибутку між спільним секвенсером і постачальником RaaS.

Але якщо RaaS — це оболонка, побудована на основі існуючої зведеної структури, вона також повинна ділитися доходом з ними, чи не так?

Ну, не обов'язково.

Більшість зведених фреймворків, випущених досі, були з відкритим вихідним кодом і не мали дозволу для створення. Постачальники RaaS можуть без дозволу використовувати фреймворк для створення безкодової оболонки поверх нього та не зобов’язані ділитися прибутками з базовим фреймворком.

Чи можуть вони укласти договір із структурою зведення про розподіл прибутку?

Вони можуть, але якщо вони це зроблять:

1. Вони втрачають частину власних прибутків
2. Інший конкурент RaaS міг би не ділитися прибутком із зведеною структурою та був би економічно домінуючим у довгостроковій перспективі

Тому, теоретично, для того, щоб постачальник RaaS вижив, раціональним рішенням буде НЕ ділитися прибутком із базовою структурою.

Отже, якщо RaaS-провайдери не діляться прибутками, як зведена структура накопичує будь-яку цінність?

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

Відповідь не така однозначна. Щоб зведена структура була «економічно життєздатною», вона має генерувати стійку довгострокову цінність. Ідан Левін поділився хорошою ментальною моделлю, щоб подумати про те, як це можна зробити. Розповімо про цю модель. Існує 3 основні способи накопичення цінності зведених фреймворків:

Непряме нарахування вартості: якщо структура хороша, все більше і більше команд використовуватимуть її. Це приверне увагу розробників до екосистеми. Залучення розуму завжди є чистим позитивним моментом, оскільки це допоможе групі фреймворків у подальшій розробці інструментів. Будь-які вдосконалення, зроблені будь-якою командою, можна включити в структуру OG. Це створює позитивну петлю зміцнення для всієї системи.

Напівпряме нарахування вартості: деякі зведені пакети, створені на основі фреймворку, можуть мати стимул для розподілу доходу з мережею фреймворку. Наприклад, наразі Base має угоду з OP Stack, згідно з якою вони діляться частиною комісії за секвенування з Optimism.

Чому їх стимулюють це робити?

Оскільки Base не має необхідної екосистеми розробників, щоб встигати за зростанням і розвитком OP framework. Уявіть собі, якщо структура OP повністю змінить один із модулів, вони можуть відмовитися від підтримки розробників для Base, щоб не відставати від змін.

Крім того, участь у «Суперланцюжку» забезпечує такі мережеві ефекти, як можливість комбінування перехресних згортань, які можуть бути корисними мережам, таким як Base (і це може вимагати розподілу доходу з Optimism).

Одне важливе застереження тут полягає в тому, що стимули згортань і зведених інфраструктур не завжди можуть узгоджуватися. У будь-який момент зведений пакет може вибрати власний шлях, налаштувавши структуру та скасувавши будь-які угоди про розподіл доходу.

1. Пряме нарахування вартості: через власну зведену структуру (наприклад, основну мережу Optimism), створену з використанням тієї самої структури (наприклад, OP Stack). Газ може бути у рідному токені (наприклад, OP), і весь MEV від цього зведення буде накопичуватися командою фреймворку. Крім того, команда могла також «вилучити» деяке додаткове пряме значення:
2. Створення власного RaaS. Фреймворк міг би конкурувати в просторі RaaS і надавати власний хостинг Sequencer + консультаційні послуги. Якщо багато фреймворків почнуть це робити, це може зробити бізнес-модель RaaS нежиттєздатною в довгостроковій перспективі. Це пояснюється тим, що фреймворк міг би використати свою довіру та позицію на ринку, щоб випередити будь-яких зовнішніх постачальників RaaS, створених на його основі.
3. Компонування між зведеними пакетами як важіль: будь-хто може створити зведений пакет, використовуючи фреймворк таким, яким він є, або змінюючи його. Однак для досягнення мережевих ефектів і взаємодії з іншими зведеними пакетами, створеними на тій самій структурі, ця структура може вимагати дотримання певних визначених стандартів.

Це те, що OP Stack робить із Законом ланцюгів. Щоб бути частиною Superchain, ви повинні дотримуватися певних правил. Ці правила визначаються керівництвом OP. Наприклад, одне з цих правил може полягати в тому, що всі зведення в Superchain мають використовувати OP як маркер газу. Це також може розвинутися, щоб включити закони про акції MEV, наприклад, X% доходу від крос-ланцюга MEV повертатиметься до скарбниці OP.

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

• Розгортання власного зведення
• Розгортання власного RaaS
• Використання компонування для управління стандартами для фреймворку

Висновок

Швидкий розвиток зведених фреймворків і постачальників Rollups-as-a-Service (RaaS) у просторі блокчейнів викликав запитання щодо їхнього нарахування вартості. У той час як рівень виконання дає левову частку цінності, зведені фреймворки можуть отримати непряму цінність через впровадження та вдосконалення. Деякі зведені програми можуть навіть розподіляти дохід, створюючи напівпряме нарахування вартості. Крім того, завдяки розгортанню власних зведень і використовуючи можливість компонування між зведеннями, фреймворки можуть безпосередньо отримувати цінність. Оскільки екосистема розвивається, досягнення правильного балансу між конкуренцією та співпрацею буде життєво важливим для сталого зростання зведених фреймворків і постачальників RaaS.

Відмова від відповідальності:

1. Цю статтю передруковано з [Stackr Labs]. Усі авторські права належать оригінальному автору [Shivanshu Madan]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.