Ланцюги ADI Chain L3 compliant — це ролапи третього рівня з нульовим розголошенням, які виконують розрахунки на ADI Chain (L2), а L2, у свою чергу, розраховується на основній мережі Ethereum (L1). Інституції можуть запускати незалежні ланцюги відповідно до юрисдикції чи бізнес-напряму та встановлювати власні політики дотримання вимог. Відповідно до дворівневої моделі безпеки, описаної в огляді ADI Chain, L3 успадковує криптографічні гарантії як від L2, так і від L1, ізолюючи середовище виконання і домени дотримання від спільного стану L2.
Для урядів, банків та індустріальних консорціумів L3 реалізує логіку «єдина екосистема, різні правила»: регульовані активи циркулюють на виділених ланцюгах, відкриті застосунки працюють на інших L3 або на L2, а всі рівні пов’язані між собою через мости L2.
ADI Chain впроваджує трирівневу ієрархію розрахунків L3→L2→L1. Ланцюги L3 виконують транзакції локально і підтримують незалежний стан; L2 (ADI Chain) верифікує докази коректності партій L3 і зберігає корені стану L3; L1 (Ethereum) верифікує докази партій L2 і фіналізує глобальний стан. Кожен рівень піднімає безпеку вгору через докази коректності з нульовим розголошенням, тому недопустимі переходи стану не приймаються вищим рівнем.
На відміну від розгортання dApps безпосередньо на L2, L3 забезпечує фізичну ізоляцію виконання: кожен L3 має власний Sequencer, Prover і Diamond Proxy-контракт із незалежними станами. В одній екосистемі можуть розгортатися кілька L3, які спільно використовують інфраструктурні контракти, такі як Bridgehub (реєстр ланцюгів) і StateTransitionManager (STM). Пропускна здатність ADI L2 — близько 2 000–10 000 TPS; додавання нових L3 дозволяє масштабувати місткість за застосуваннями чи юрисдикціями.
| Рівень | Місце виконання | Мета подання доказу | Типова затримка підтвердження |
|---|---|---|---|
| L3-ланцюг | L3 локальний Sequencer | ADI Chain (L2) | Секунди (м’яке підтвердження) |
| ADI Chain (L2) | L2 Sequencer | основна мережа Ethereum (L1) | Хвилини (підтвердження L2) |
| Ethereum (L1) | Контракти верифікатора | Фіналізація кореня стану | Години (фінальність L1) |
З таблиці видно, що L3 — це не окремий публічний ланцюг, а гнучкий домен виконання, вкладений у ADI L2 та Ethereum L1. ADI L2 як zkRollup успадковує економічну безпеку Ethereum, а L3 додає ще один рівень дотримання інституційних вимог.
Рисунок 1. Позиція ланцюгів ADI Chain L3 compliant у багаторівневій архітектурі L3→L2→L1 та взаємозв’язок основних компонентів.
Екосистема L3 розгортає спільну інфраструктуру на рівні розрахунків L2 і контракти та операційні вузли на кожному окремому L3. Bridgehub є центральним реєстром, підтримує відповідність ідентифікаторів ланцюгів і адрес контрактів, маршрутизацію міжланцюгових повідомлень та конфігурацію екосистеми. StateTransitionManager відповідає за реєстрацію нових ланцюгів, оновлення протоколу і керування параметрами верифікації. Кожен L3 має Diamond Proxy-контракт із патерном Facet для модульних оновлень, який обробляє подання і верифікацію партій, зберігає корінь стану й управляє валідаторами.
В операційній частині кожен ланцюг L3 запускає Sequencer, Prover і набір Operator-гаманців (відповідають за Commit, Prove і Execute). На L2 L2 Prover агрегує L2-транзакції і розрахунки L3 у докази, які подаються на L1. Validator Timelock вводить затримку між Commit і Execute, залишаючи час для виявлення аномалій.
Дизайн Diamond Proxy Facet дозволяє незалежно оновлювати логіку виконання, запитів і керування. Поєднання спільної реєстраційної інфраструктури на L2 з ізольованим станом виконання на кожному L3 — ключова особливість ADI Chain порівняно з типовою моделлю L2 «один ланцюг, багато застосунків»; у порівнянні ADI Chain з Arbitrum і Base підтримка L3 і модель екосистеми Bridgehub є основними відмінностями.
ADI Chain L3 підтримує моделі з керуванням ADI, з керуванням клієнта та гібридну, що охоплюють потреби інституцій від повної автоматизації до повного самостійного контролю.
| Модель | Sequencer | Prover | Ключі контракту | Найкраще підходить для |
|---|---|---|---|---|
| З керуванням ADI | Під контролем ADI | Докази, згенеровані ADI | Ключі управління та операцій у ADI | Інституції, яким потрібне швидке розгортання без інфраструктурного навантаження |
| З керуванням клієнта | Клієнт запускає вузли | Клієнт керує GPU-проберами | Ключі на гаманцях клієнта | Інституції, яким потрібен повний контроль над операціями ланцюга і даними |
| Гібридна | Клієнт або ADI (налаштовується) | Клієнт або ADI (налаштовується) | Управління — клієнту; операції можна делегувати ADI | Інституції, яким потрібен контроль за управлінням з можливістю аутсорсу операцій |
Розгортання контрактів використовує ролевий контроль доступу: Governor проводить оновлення протоколу, Admin реагує на надзвичайні ситуації, Operator виконує Commit, Prove Operator подає докази, Execute Operator виконує підтверджені партії. Власність може бути повністю передана на мультипідпис клієнта або поступово. Екосистема L3 реалізує принцип «розгорнути один раз, додавати ланцюги поступово»: Bridgehub і STM розгортаються на рівні екосистеми, а нові L3 приєднуються як незалежні контракти.
У режимі з керуванням клієнта Prover потребує NVIDIA H100 або H200 GPU (70–140 ГБ VRAM) і системну пам’ять від 64 ГБ; Sequencer — мінімум 8 ядер CPU, 32 ГБ RAM і публічний endpoint для транзакцій. Operator-гаманці повинні містити $ADI токени як L2-газ для ончейн-операцій Commit, Prove і Execute.
Під час розрахунків партій L3 на L2 вони проходять через Commit, Prove і Execute. Sequencer пакує транзакції L3 у партії; Operator подає транзакцію Commit на L2, яка містить зміни стану (зміни слотів зберігання), інформацію про розгортання контракту і хеші повідомлень L2→L3 — без повних знімків стану, щоб зменшити вартість даних.
На етапі Prove Prover створює доказ коректності через систему Airbender (FRI/STARK → FFLONK SNARK), криптографічно гарантує, що переходи стану відповідають правилам виконання L3. На етапі Execute, після перевірки доказу на L2, новий корінь стану L3 записується в Diamond Proxy-ланцюг-контракт і партія фіналізується.
| Фаза | Оператор | Вміст подання | Результат L2 |
|---|---|---|---|
| Commit | Operator | Зміни стану, інформація про розгортання, хеші повідомлень | Дані партії на ончейн, очікує доказу |
| Prove | Prove Operator | ZK-доказ коректності | Доказ перевірено контрактом верифікатора |
| Execute | Execute Operator | Виконати підтверджену партію | Оновлено корінь стану L3, партія фіналізована |
Повний цикл розрахунків споживає близько 747 000 Gas загалом (Commit ~136 000, Prove ~494 000, Execute ~117 000), кожна фаза оплачується в $ADI з Operator-гаманців. У виробничому середовищі FRI- і SNARK-Prover можуть працювати паралельно на окремих GPU-розділах, підвищуючи пропускну здатність партій на 15–20%; одна цільова конфігурація Prover підтримує приблизно 15–20 TPS.
Рисунок 2. Схема від пакування транзакцій до розрахунків Commit, Prove і Execute на L2 для партії L3.
Рекомендована конфігурація Prover — NVIDIA H200 (140 ГБ VRAM), 2 паралельні FRI Prover і 1 виділений SNARK Prover (~33 ГБ VRAM). Інституціям у режимі з керуванням клієнта варто заздалегідь планувати кластери GPU та низьколатентні L2 RPC-з’єднання для ритмічного подання партій.
Типи підтвердження транзакцій L3 підвищуються на етапах L3→L2→L1 у процесі розрахунків. Після включення транзакції Sequencer у блок користувачі отримують м’яке підтвердження за секунди та можуть одразу використовувати передані активи; м’яке підтвердження базується на чесності Sequencer і ще не має криптографічної фінальності.
Після Commit партії L3 на L2 вона потрапляє на етап підтвердження L2 (зазвичай хвилини). Після завершення Prove і Execute на L2 корінь стану L3 записується в контракт ланцюга L2 і не може бути відкочений. Далі L2 Prover доводить стан L2, зокрема розрахунки L3, на Ethereum L1; після підтвердження контрактами верифікатора на L1 весь ланцюг розрахунків досягає фінальності L1 (зазвичай години).
Великі розрахунки чи міжланцюгові зняття слід виконувати після фінальності L2 або L1; для щоденних взаємодій достатньо м’якого підтвердження. Validator Timelock додає налаштовувану затримку між Commit і Execute, резервуючи час для виявлення аномалій.
L3 відповідає логіці «ізоляція правил, спільна безпека»: банки запускають суверенні стейблкоїн-рельси, керуючі активами розгортають RWA-контракти з доступом через KYC, уряди можуть токенізувати дані відповідно до юрисдикції. У розгортанні з керуванням клієнта відповідальність за GPU-кластери і RPC-білі списки лежить на клієнті; у режимі з керуванням ADI операції делегуються ADI.
Ланцюги ADI Chain L3 compliant використовують трирівневу ZK Rollup-архітектуру L3→L2→L1, завдяки чому інституції отримують безпеку рівня Ethereum і незалежні домени виконання з правилами дотримання вимог, налаштованими за юрисдикцією. Bridgehub і StateTransitionManager забезпечують спільну інфраструктуру реєстрації та оновлень; кожен L3 підтримує ізоляцію стану через Diamond Proxy, власний Sequencer і Prover. Партії розраховуються на L2 через Commit, Prove і Execute; система доказів Airbender і GPU-інфраструктура (H100/H200) забезпечують генерацію доказів коректності; фінальність передається від м’якого підтвердження L3 до криптографічної фінальності L2 і L1. Три моделі розгортання відповідають різним операційним і управлінським потребам, підходять для суверенних стейблкоїнів, RWA, міжнародних платежів і токенізації державних даних.
L3 — це ролап третього рівня з нульовим розголошенням, який розраховується на ADI Chain (L2), дозволяючи інституціям, урядам чи галузевим консорціумам запускати незалежні ланцюги за юрисдикцією з власними політиками дотримання вимог. Кожен L3 має власний Sequencer, Prover і Diamond Proxy-контракт, успадковує дворівневу безпеку через L2 і Ethereum та розділяє інфраструктуру реєстрації Bridgehub з іншими L3 в екосистемі.
ADI Chain працює як L2 zkRollup на Ethereum; переходи стану партій L2 вимагають перевірки доказів ZK контрактами верифікатора L1 перед фіналізацією. L3-ланцюги додатково розраховуються на ADI L2, формуючи трирівневий ланцюг доказів коректності L3→L2→L1. Активи можуть переміщуватися між L1, L2 і L3 через мости, а модель безпеки на кожному рівні успадковує економічну безпеку Ethereum.
ADI Chain використовує ZK-докази коректності, тому недопустимий стан не може бути прийнятий на L1; партії L3 також мають пройти перевірку L2 перед фіналізацією. Sequencer забезпечує м’яке підтвердження; криптографічна фінальність вимагає перевірки доказу на L2 і L1. Користувачам та інституціям слід враховувати ризики, пов’язані з мостовими контрактами, керуванням ключами, власною GPU-інфраструктурою L3 і вікном між м’яким підтвердженням і фінальністю L1.
ADI Chain L3 підтримує три моделі: з керуванням ADI (ADI керує Sequencer, Prover і контрактними операціями), з керуванням клієнта (інституція запускає вузли, GPU-інфраструктуру і володіє ключами) та гібридну (управління залишається за клієнтом, а Sequencer і Prover можна гнучко призначати). Вибір залежить від балансу між операційним навантаженням, контролем і гнучкістю дотримання вимог.
Sequencer L3 пакує транзакції у партії; Operator фіксує зміни стану на L2; Prover створює ZK-доказ коректності через систему Airbender і подає транзакцію Prove; після перевірки на L2 Execute Operator ініціює виконання, записуючи корінь стану L3 у контракт ланцюга і фіналізуючи партію. Три фази споживають близько 747 000 Gas загалом, оплата — у $ADI.
Виробниче середовище потребує NVIDIA H100 або H200 GPU з мінімум 70 ГБ VRAM (рекомендовано 140 ГБ), 64 ГБ і більше системної пам’яті та NVMe SSD для даних свідків. Рекомендована конфігурація: 2 паралельні FRI Prover і 1 виділений SNARK Prover (~33 ГБ VRAM), орієнтир — близько 15–20 TPS. Sequencer вимагає щонайменше 8 ядер CPU, 32 ГБ RAM і публічний endpoint для транзакцій.





