Створення власного Layer 2: від Optimistic Rollup до ZK Stack

Чому розробка L2 впирається у пропускну здатність

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

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

Далі вмикається аукціон за це місце. Вартість транзакції рахується за поточною завантаженістю, тому на піковому навантаженні — запуск токена, масова роздача, сплеск активності в застосунку — плата зростає в десятки разів за лічені хвилини.

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

Продукт ламається не в момент явної відмови, а раніше.

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

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

Розбираємо, як це закривається: де закінчується ємність базового рівня і що саме дає власна мережа другого рівня.

Що дає власний ролап: швидкість, вартість, контроль

Пропускна здатність перестає впиратися в чужу мережу

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

Комісію задаєте ви, а не аукціон в основній мережі

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

Відмова, яка більше не зупиняє сервіс

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

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

Передбачуваний час підтвердження

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

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

Порівняння підходів: оптимістичні ролапи та ZK-докази

Архітектуру другого рівня обирають не за «сучасністю» рішення, а за тим, які гарантії отримує користувач і скільки він чекає на повернення коштів. Нижче — три варіанти, між якими реально обирають на старті проєкту.

Оптимістична та ZK-схема розходяться за трьома осями: фінальність розрахунків, час виведення коштів і модель безпеки — хто саме доводить коректність і що відбувається при нечесній поведінці вузла.

Виділений канал стоїть окремо: він не успадковує захист базового рівня в повному обсязі, зате дає контроль над правилами виконання та пропускною здатністю.

На практиці схему підбирають під профіль навантаження: де важливі сумісність і вартість виконання — виграє оптимістичний шлях; де критична швидка фінальність — докази з нульовим розголошенням.

Розробка L2: аудит, схема мережі, налаштування та передача

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

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

Порядок робіт

1. Аудит сценаріїв. Розбираємо потоки операцій, піковий профіль навантаження, вимоги до часу підтвердження й те, хто тримає ключі. Фіксуємо, які операції виносимо на другий рівень, а які залишаємо в основній мережі.
2. Проєктування схеми мережі. Обираємо модель збирання та доказування, кількість вузлів-валідаторів, топологію розміщення, правила плати за обчислення й ролі доступу. Тут же визначаємо, як мережа переживе падіння окремого вузла.
3. Налаштування вузлів. Піднімаємо вузли, налаштовуємо синхронізацію, доступ до стану мережі, моніторинг і резервні копії. Окремо перевіряємо, що порядок запуску відтворюється з нуля за інструкцією.
4. Зв’язка з основною мережею. Налаштовуємо переведення активів між рівнями, затримки виведення й обробку відкатів при перебудові ланцюга.
5. Перевірка під навантаженням. Проганяємо сценарії, що повторюють піковий профіль, заміряємо пропускну здатність і час відгуку, навмисно гасимо вузли й дивимося на відновлення.
6. Приймання та передача. Віддаємо документацію, доступи, регламенти оновлення й розбору збоїв, навчаємо команду — мережа має обслуговуватися без нас.

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

Комплект документації: схеми мережі, політики доступу, регламенти

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

• Конфігурації вузлів — файли налаштувань секвенсора, перевіряльних вузлів і вузлів доступу до мережі з порядковим розбором: які значення штатні, які підбиралися під ваше навантаження і що станеться при відхиленні.
• Схема топології — як вузли пов’язані між собою, де проходить межа з основною мережею, які канали дублюються і які точки відмови залишені свідомо.
• Політики доступу та ролі — матриця «роль → дія → ключ»: хто випускає оновлення контрактів, хто керує гаманцями, хто лише читає метрики і чому перші два права не повинні бути в однієї людини.
• Регламент оновлення — порядок випуску нових версій контрактів і вузлів: підготовка, вікно робіт, хто затверджує, як перевіряється результат і за яким сценарієм відкочуємося.
• Інструкції для чергової зміни — що вважати відхиленням, які сигнали потребують реакції всередині зміни, які чекають ранку, у який момент піднімають розробників.
• Порядок роботи з ключами — де зберігаються ключі підпису, як проходить ротація і що робити при компрометації.
• План відновлення — що і з якою періодичністю копіюється, скільки займає підйом мережі з нуля на чистій інфраструктурі і хто відповідає за процедуру.

Як ми знімали пікове навантаження: метрики до і після

Що було до переїзду

Клієнт — сервіс із потоком дрібних операцій: нарахування, ставки, виведення. У пікові години базовий рівень переставав приймати частину транзакцій: частка відхилених операцій сягала 8–9%, а підтвердження розтягувалося до хвилини й більше.

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

Що змінили і що отримали

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

Метрики до і після: частка відхилених операцій упала з 8–9% до 0,3%, середнє підтвердження скоротилося з 60 до 2–4 секунд, поведінка на піку стала рівною.

Навантажувальний прогін із триразовим перевищенням звичайного трафіку утримували 40 хвилин — без зростання черги і без ручних втручань чергового.

Головне — пішов цілий клас відмов: операції більше не губляться через переповнення блоку базового рівня. Повтори повернулися в штатний режим, а пікові інциденти перестали бути регулярною статтею у звіті чергування.

Чим оптимістичний ролап відрізняється від ZK-ролапа?

Обидві родини вирішують одну задачу: виконання переноситься з основного рівня, а в мережу-розрахунковий рівень (Ethereum) йдуть дані й доказ коректності стану.

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

Оптимістичний ролап за замовчуванням вважає партію транзакцій правильною і залишає вікно на оспорювання.

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

Перевіряльній стороні вистачає звичайного вузла — спеціальне обладнання не потрібне, а вартість перевірки близька до нуля.

ZK-ролап додає до кожної партії доказ із нульовим розголошенням, і контракт змінює стан лише після його перевірки. Підтвердження приходить помітно швидше і не залежить від того, чи є поруч спостерігачі.

Перевірка доказу на основному рівні коштує дешево, але генерація потребує спеціалізованого обладнання в оператора — цей ресурс і є основною статтею витрат схеми.

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

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

Схему обирають за пріоритетом: швидкість остаточного підтвердження й незалежність від спостерігачів — на користь ZK; сумісність із наявними контрактами та інструментами, передбачуваний супровід — на користь оптимістичної моделі.

Опишіть сценарій — повернемося з оцінкою та планом за обома варіантами, із зазначенням вузького місця й способу його закрити.

Типові сумніви: безпека, виведення коштів, підтримка

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

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

Що буде при відмові вузла-упорядковувача?

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

Як влаштовано виведення коштів?

Виведення двоетапне: ініціювання на другому рівні, потім підтвердження в базовому після вікна оспорювання. У ZK-варіанті очікування коротше — коректність уже підтверджена доказом. Швидке виведення через сторонні мости підключаємо окремо, з оцінкою їхніх ризиків і лімітів.

Хто підтримує мережу після запуску?

Передаємо регламент: моніторинг вузлів і черги, ротація ключів, планові оновлення, розбір інцидентів. Перші тижні чергуємо разом із вашою командою, далі — за узгодженим рівнем технічної підтримки із заданим часом реакції.

Обговоримо задачу: підберемо схему і повернемося з оцінкою

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

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

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