Розробка appchain: коли спільна мережа стала вузьким місцем
Поки логіка продукту живе в спільній мережі, його швидкість залежить від чужого навантаження.
Під час пікових годин блок заповнюється транзакціями сторонніх проєктів, і операція вашого користувача стає в загальну чергу — затримка підтвердження операцій зростає з секунд до десятків хвилин, а інтерфейс увесь цей час показує «обробка».
Далі підключається економіка. Чим щільніший блок, тим дорожче місце в ньому: зростання витрат на транзакції перестає бути передбачуваним, кошторис на місяць не сходиться, а пікові вікна з'їдають основну частину ліміту.
Частина операцій не проходить за виставленою межею комісії або відпадає за часом очікування — частка відмов зростає саме тоді, коли навантаження максимальне.
Це і є вузьке місце блокчейну загального призначення: він спроєктований під універсальні сценарії, а не під ваш продукт. Йому байдужі ваші вимоги до порядку операцій, розміру блоку та правил оплати — ви підлаштовуєтесь під чужі правила.
Масштабування застосунку впирається не в код, а в чужу пропускну здатність. Розробка appchain знімає це обмеження: виділена мережа під один застосунок зі своїми параметрами блоку, комісій і доступу до вузлів.
Ми проєктуємо та запускаємо такі мережі на базі Arbitrum Orbit — логіка й дані залишаються вашими, а зовнішня мережа перетворюється на міст для ліквідності й активів.
Ефект від виділеної L3-мережі: що змінюється для продукту
Переваги appchain проявляються у трьох вимірюваних речах: своя смуга пропускання, свій порядок обробки транзакцій і своя межа відмови. Виділена L3-мережа — це окремий інтервал виробництва блоків і ліміт газу в блоці: вони належать продукту, а не діляться з чужими застосунками.
Пропускна здатність мережі перестає залежати від чужої активності, і час підтвердження вкладається в передбачуване вікно замість розтягування в години пік загального контуру.
Свій порядок обробки транзакцій — другий ефект, помітний на продукті. Секвенсор вибудовує чергу за правилами замовника: операції критичного сценарію проходять раніше за допоміжні, а не викуповують місце в блоці на загальному аукціоні. Користувач отримує рівномірну затримку замість лотереї зі ставкою.
Ізоляція навантаження змінює і клас відмов: перевантаження або спам одного застосунку залишаються всередині його мережі й не блокують інших — загальний контур перестає бути точкою, де чужий інцидент стає нашим.
Плата за це — власна зона відповідальності: вузли, моніторинг і оновлення обслуговує команда, а не зовнішній оператор.
Каркас збираємо на Arbitrum Orbit: налаштовувані параметри газу, права на оновлення та розрахунки, що спираються на захист базового рівня, — без потреби піднімати й захищати цей рівень з нуля.
Після запуску дивимося на цифри: частка операцій, що потрапили в блок з першої спроби, розкид часу підтвердження, частка відмов, локалізованих усередині своєї мережі. Рівні значення цих чисел і є практичним ефектом виділеного контуру.
Порівняння варіантів: спільна мережа, виділена L3, приватний контур
Вибір між спільною мережею та виділеним контуром визначає не пропускну здатність, а те, хто керує порядком включення транзакцій і політикою комісій.
У мережі загального користування ви орендуєте місце в блоці нарівні з усіма: під час сплеску активності ваші операції стають у чергу до чужих, а правила гри змінює той, хто цю мережу розвиває.
Виділений контур знімає ці обмеження, але переносить на вас експлуатацію: вузол-секвенсор, мости, експлорер і оновлення стають вашою зоною відповідальності. Нижче — три робочі конфігурації, між якими найчастіше обирають.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Мережа загального користування | Публічний продукт, потрібна зовнішня ліквідність і сумісність із готовими протоколами | Простір у блоці ділиться з усіма: стрибки комісій, конкуренція за включення операцій, політику газу визначаєте не ви |
| Виділена L3-мережа на Arbitrum Orbit у своєму контурі | Високе навантаження, передбачувані комісії, власні правила доступу й кастомізація виконання | Тримаєте секвенсор і всю обв'язку, відповідаєте за мости, виведення коштів і оновлення, потрібна команда експлуатації |
| Приватний блокчейн-контур | Регульовані процеси: склад учасників, дані та історія операцій не виходять назовні | Немає зовнішньої ліквідності та публічних сервісів, будь-яка інтеграція із зовнішніми протоколами будується окремо |
Головне обмеження виділеного контуру в тому, що суверенність не буває частковою: контроль над правилами неподільний із відповідальністю за доступність і безпеку виведення коштів.
Тому порівняння варіантів розгортання зводять не до швидкості, а до того, хто має керувати чергою транзакцій, доступом і оновленнями.
Розробка appchain: етапи інженерної роботи
Порядок робіт задає профіль навантаження, а не шаблон із документації: спочатку рахуємо, що саме відбуватиметься в мережі, і лише потім обираємо конфігурацію. Кожен етап закінчується артефактом, який можна перевірити, — без нього наступний крок не починається.
- Розбір навантаження та профіль операцій. Склад викликів, співвідношення читання й запису, пікові вікна, вимоги до часу відгуку. Результат — модель навантаження й аудит архітектури: де схема впреться в межу першої.
- Проєктування схеми. Ролі вузлів, порядок проведення транзакцій, зберігання даних, правила виведення коштів в основну мережу, параметри комісій.
- Розгортання контуру. Тестова мережа, що повторює майбутню промислову; перенесення контрактів і перевірка сумісності з уже працюючими сервісами.
- Налаштування мережі під задачу й доступів. Розмежування ролей, мультипідпис для критичних операцій, регламент ротації ключів — права адміністратора не залишаються в однієї людини.
- Перевірка під навантаженням. Сценарії, що повторюють реальний профіль операцій: дивимося час блоку, черги й відгук на піку.
- Передача в експлуатацію. Моніторинг з оповіщеннями, документація щодо аварійних сценаріїв, навчання команди. Далі — супровід і оновлення.
Артефакти й документація, які залишаються у замовника
Після запуску appchain на Arbitrum Orbit у замовника залишається не лише робочий контур, а й пакет документації, за яким команда може розвивати й обслуговувати ланцюжок без нас.
Ми ведемо його паралельно з розробкою: рішення фіксуються тоді, коли ухвалюються, а не відновлюються з пам'яті в кінці проєкту.
Що саме передаємо:
- Документація щодо мережі — архітектура ланцюга, ролі вузлів, параметри газової моделі та порядок фіналізації, межі відповідальності між рівнями.
- Схема розгортання — топологія контуру, розміщення сервісів і зв'язків між ними, зовнішні точки входу та місця відмови.
- Політики доступу — ролі, порядок випуску й відкликання ключів, розмежування прав на розгортання контрактів і на керування параметрами мережі.
- Регламент оновлень — послідовність викочування, обов'язкові перевірки на тестовому контурі, умови та процедура відкату на попередню версію.
- Інструкції для команди замовника — як підняти вузол, підключити моніторинг, зняти стан мережі та що робити при розсинхронізації.
- Регламент реакції на збої — класифікація інцидентів, зони відповідальності, порядок ескалації та шаблони оповіщень.
- Інвентар ресурсів — перелік серверів, репозиторіїв і секретів із зазначенням власників і строків ротації.
Документація лежить у репозиторії замовника й оновлюється разом із кодом, а не окремим файлом «на згадку». Через місяць після передачі команда замовника сама проводить оновлення або розбір інциденту — ми залишаємося на зв'язку, але не як єдиний носій знань.
Кейс: як виділена мережа зняла перевантаження основної
Що було
Усі операції — прикладна логіка, розрахунки, службові виклики — йшли через один контур.
У пікові години черга на включення в блок зростала, і частина транзакцій відпадала за таймаутом: частка відхилених операцій сягала 7-8%, а час підтвердження розтягувався з двох секунд до десятків.
Що зробили
Прикладне навантаження винесли у виділений appchain на базі Arbitrum Orbit: власний простір блоків, свої правила комісій і порядок включення транзакцій.
Основний контур залишили розрахунковим шаром — туди йде лише підсумковий стан, тому його пропускна здатність перестала бути вузьким місцем.
Що стало
Частка відхилених операцій на тих самих піках — 0,3-0,5%. Медіана підтвердження менше секунди, рідкісні повільні операції вкладаються в дві. Пропускна здатність зросла приблизно втричі за тієї ж кількості вузлів, а графік навантаження перестав бути рваним.
Ізольований контур налаштовується під профіль навантаження: межі газу, розклад відправлення пакетів, політика повторів — усе своє. Оновлення прикладної логіки більше не потребує зупинки розрахункового шару, а відкат зачіпає одну мережу, не весь сервіс.
Чим виділена мережа відрізняється від спільної та від каналу?
Спільна мережа дає один блокспейс на всіх: газ купується на відкритому ринку, а час підтвердження й комісія для користувача залежать від чужого навантаження.
У пік застосунок конкурує за місце в блоці з тими, хто готовий платити більше, і його власні ліміти перестають бути керованими. Обмежити логіку й доступи можна на рівні контрактів, але не на рівні самої мережі.
Канал — не окрема мережа, а розрахунок між заздалегідь відомим колом учасників. Сторони блокують депозит, обмінюються підписаними оновленнями стану поза мережею, а в основну мережу йде лише підсумок при закритті.
Для повторюваних двосторонніх операцій це швидко й дешево, але канал не дає довільного виконання, своєї моделі газу й правил доступу: відкриття та закриття залежать від контрагента й заблокованої ліквідності.
Виділений контур — це власний ланцюжок: свій секвенсор, свій блокспейс, ізольований стан, своя політика газу й доступу.
У Arbitrum Orbit розрахунок і доступність даних виносяться в батьківську мережу, тому контур успадковує її гарантії фінальності, але не ділить із нею чергу за місцем у блоці.
Це дозволяє зафіксувати вартість транзакції для користувача, обмежити коло учасників на рівні мережі та розвести навантаження між сервісами.
Вибір архітектури мережі зводиться до трьох питань. Потрібні довільне виконання та зовнішня ліквідність — беруть спільну мережу. Потрібен обмін цінністю всередині відомого кола без чужого трафіку — достатньо каналу.
Якщо потрібні ізоляція стану, передбачувана вартість і свої правила доступу, доречний окремий контур: на цей момент спільна мережа вже впирається в чужі ліміти, а канал не тягне довільну логіку.
Часті питання щодо конфігурації та експлуатації мережі
Питання, які виринають після запуску, стосуються не збірки, а експлуатації мережі: як проходить міграція продукту в свою мережу, хто тримає доступи, що буде при кратному зростанні навантаження і чи потрібно ділити контури. Нижче — короткі відповіді щодо кожного сумніву.
Чи можна перенести працюючий продукт без зупинки?
Переносимо поетапно: спочатку мережа й міст, потім контракти, потім потік операцій. Знімок стану фіксується на конкретній висоті блоку, а старий контур якийсь час працює лише на читання — розбіжності видно до перемикання трафіку.
Хто тримає доступи до мережі після здачі?
Ключі адміністратора, керування вузлами й оновлення передаємо вам за актом, критичні операції закриваємо мультипідписом із порогом. Наші інженери працюють під тимчасовими ролями з журналом дій, розширений доступ відкликається після приймання.
Що буде при кратному зростанні навантаження?
Межу задає не сама мережа, а пропускна здатність упорядника транзакцій і обсяг публікації даних у батьківську мережу. Заздалегідь виставляємо ліміт газу на блок і чергу операцій, важкі обчислення виносимо за межі мережі. Вузли додаються без зупинки мережі.
Навіщо ділити продукт на кілька контурів?
Окремі мережі під розробку, перевірку оновлень і роботу — з незалежними наборами ключів і вузлів. Це виключає прогін тестів на живих даних і дозволяє обкатати оновлення до застосування. Витрати на супровід зростають не лінійно: шаблони розгортання й моніторинг спільні.
Обговоримо задачу: що надіслати для точної оцінки
Точна оцінка проєкту appchain тримається не на загальних словах, а на вхідних даних. Чим конкретніші вхідні дані, тим менше припущень в оцінці та плані робіт щодо мережі — і тим нижчий ризик, що на середині виявиться невідповідність за навантаженням або доступами.
Достатньо шести пунктів, щоб порахувати строки, склад команди та межі етапів:
- Профіль операцій. Тип переважних транзакцій, частка читання й запису, середній і піковий потік, добова нерівномірність.
- Поточні вузькі місця. Що не влаштовує вже зараз: затримка підтвердження, вартість операції для користувача, відмови на піку, ручні кроки у випуску оновлень.
- Вимоги до доступів. Хто випускає контракти й керує ключами, чи потрібні мультипідпис і розмежування ролей між командами.
- Плани щодо зростання навантаження. Цільові показники на горизонт року: обсяг стану, кількість активних адрес, очікуваний приріст операцій на піку.
- Інтеграції. Мости, оракули, гаманці та зовнішні сервіси, з якими мережа має працювати одразу, плюс сумісність із поточним контуром.
- Експлуатація. Хто тримає вузли й спостерігає за мережею, які вікна на оновлення допустимі, який простій вважається прийнятним.
Опишіть задачу в такому розрізі — повернемося з оцінкою проєкту appchain і планом робіт щодо мережі, з межами етапів і точками, де потрібне ваше рішення. Якщо частину даних ще не зібрано, скажіть одразу: зазначимо, що уточнюємо в процесі, а що фіксуємо до старту.
