Довгий час у мене завжди була ідея вирішити деякі проблеми, з якими зараз стикається Rollup, за допомогою мультизведеного (multi-Rollup) дизайну. Приблизно півтора року я думав, що хтось побудує її, але ніколи не заглиблювався в деталі такої системи та не розглядав їх.
Минув деякий час, і, здається, немає єдиного дизайну, який би вирішив проблему, яку я описав у цій публікації, тому я заповню якнайбільше деталей про цю систему, сподіваючись, що хтось зможе взяти натхнення з нього, або навіть з існуючого зведеного Запозичте деякі ідеї.
представити
Однією з проблем, з якими сьогодні стикається Rollup, є взаємодія з користувачем. У багатьох дизайнах Rollups є окремими екосистемами з різними характеристиками. Існують способи взаємодії, але з’єднання кількох різнорідних систем є досить складним завданням. Крім того, важко змусити користувачів зареєструватися для всіх цих зведених пакетів. Вони повинні розуміти кожен Rollup окремо, оцінювати відповідні смарт-контракти, підключати свої гаманці до нових кінцевих точок RPC, підключати активи до ланцюга тощо.
Що, якби існував один дизайн зведення, який міг би забезпечити єдиний досвід для всіх зведень? Як це буде виглядати?
Я ставив собі це питання і прийшов до таких п’яти ідей:
Він повинен забезпечувати уніфікований RPC для запитів і викликів різних смарт-контрактів у Rollup. Розумні контракти повинні мати унікальну адресу, яка не залежить від зведеного пакету, до якого вони належать.
Це має дозволяти масштабування вгору та вниз залежно від попиту. Більша кількість транзакцій має означати більше зведених пакетів для їх обробки, а нерівномірне навантаження між зведеними пакетами має бути збалансованим.
Це має стимулювати сортувальників у різних зведених пакетах залишатися онлайн. Система повинна заохочувати інші сортувальники замінити автономні сортувальники.
Він повинен підтримувати миттєві міжланцюгові перекази. Розрахунки по транзакціях мають здійснюватися достатньо швидко, щоб міжланцюгові операції мали сенс.
Він повинен підтримувати легкий клієнт і блокувати функціональні можливості дослідника під час кількох злиттів. Провідники блоків повинні забезпечувати уніфіковане уявлення про блокчейн, а спрощені клієнти повинні дозволяти недорогу перевірку.
Маючи все це на увазі, я придумав дизайн, що складається з концентратора Rollup і змінної кількості дочірніх Rollup. Концентратор Rollup є і реєстром, і балансувальником навантаження для всіх підзведених пакетів, але не обробляє смарт-контракт. Смарт-контракти обробляються в підгрупах.
У наступному розділі я проведу вас через приблизний дизайн, пояснюючи 5 міркувань, які я згадав вище.
Огляд дизайну
Система складається з двох основних компонентів: концентратора Rollup і sub-Rollup. Система концентратора Rollup складається з двох основних компонентів: концентратора Rollup і підпорядкованих компонентів. Концентратор Rollup — це Rollup, який містить усі реєстри смарт-контрактів усіх підзведених пакетів і вирішує, який Rollup відповідає за який смарт-контракт. Крім того, концентратор Rollup містить реєстр усіх сортувальників для іншого дочірнього Rollup. Дочірні ланцюги відповідають за виконання транзакцій для смарт-контрактів, призначених їм концентратором Rollup у реєстрі смарт-контрактів. Реєстр сортувальника містить два основні компоненти для кожної системи сортувальника: концентратор зведення та дочірній зведення. Зведений концентратор — це зведений пакет, який містить усі реєстри смарт-контрактів усіх підзведених пакетів і визначає, який зведений пакет відповідає за який смарт-контракт. Крім того, концентратор Rollup містить реєстр усіх секвенсорів для іншого дочірнього Rollup. Дочірні ланцюги відповідають за виконання транзакцій для смарт-контрактів, призначених їм концентратором Rollup у реєстрі смарт-контрактів. Реєстр секвенсора містить кожну кінцеву точку RPC секвенсора та адресу DA.
Реєстр секвенсора діє як відображення глобальних адрес смарт-контрактів на адреси смарт-контрактів. Це використовується для маршрутизації викликів RPC до певного RPC секвенсора, що відповідає запитаному або оновленому смарт-контракту.
Реєстр смарт-контрактів
Реєстр смарт-контрактів діє як відображення глобальних адрес смарт-контрактів на адреси смарт-контрактів.
Зведений ланцюжок
Дочірній ланцюжок зазвичай має корінь стану, і цей маршрут стану можна оновити, викликавши смарт-контракт напряму, або його можна оновити, коли концентратор Rollup призначає смарт-контракт іншому Rollup, у цьому випадку смарт-контракт слід видалити. , а його додають до інших смарт-контрактів.
Уніфікований RPC
Мета: не потрібно підключатися до нового ланцюга для кожного зведення та зробити перехресні транзакції прозорими для користувачів.
Уніфікований RPC відновлює взаємодію користувача з одним ланцюжком у мережі з кількома зведеними пакетами, і користувачам не потрібно підключатися до різних мереж, щоб використовувати різні зведені пакети.
Система використовує реєстр зведених секвенсорів із концентратора Rollup, щоб знайти кінцеву точку RPC для секвенсора, який відповідає конкретному смарт-контракту. Потім запит надсилається безпосередньо секвенсору. Кілька транзакцій можна завершити, надсилаючи запити до різних зведених пакетів. Перегляньте наступні розділи, щоб дізнатися більше.
як працювати
Концентратор Rollup підтримує реєстр секвенсорів для всіх дочірніх ланцюжків.
Коли користувач хоче подати нову транзакцію, гаманець користувача запитує реєстр смарт-контрактів, щоб отримати RollupID смарт-контракту, і запитує реєстр секвенсора, щоб отримати кінцеву точку RPC секвенсора в тому ж Rollup.
Потім транзакція надсилається до кінцевої точки RPC секвенсера.
Балансування навантаження
Мета: збалансувати витрати на всі зведені програми
Балансування навантаження дозволяє збалансувати навантаження в Rollup. Коли система засмічується, для обробки навантаження можуть бути створені нові зведені пакети. Коли немає особливої користі, Rollup можна видалити, щоб заощадити ресурси. Крім того, система може уникнути стрибків комісії, перемістивши смарт-контракти з високим попитом у транзакціях на зведені з більш доступною ємністю.
Кожної епохи центр зведення оцінює завантаження всіх зведених даних у системі. Епохи мають тривати кілька годин (можливо, від 6 до 24 годин), щоб уникнути масштабного перерозподілу смарт-контрактів.
Центр зведення може вирішувати, які смарт-контракти перерозповсюджувати, а також коли генерувати чи видаляти зведені пакети, що можна вирішувати автономно за допомогою управління або історії споживання газу різними смарт-контрактами.
Центр зведення перевіряє, чи є навантаження транзакцій у будь-якому зведених даних вище середнього (тобто комісії високі) або нижче середнього (тобто комісії низькі).
Якщо навантаження на зведення вище середнього, концентратор зведення оцінює, які смарт-контракти споживають найбільше газу, і перерозподіляє їх на інше зведення, яке може впоратися з додатковим навантаженням. Після цього смарт-контракт буде вилучено з початкового стану зведення.
Якщо середнє навантаження всіх зведених пакетів вище середнього, концентратор зведених даних створить новий зведений пакет і призначить йому деякі смарт-контракти. Подібним чином, якщо середнє навантаження всіх зведених пакетів нижче середнього, концентратор зведених даних видалить зведений пакет і перепризначить його розумні контракти іншим зведеним пакетам.
Зведені ланцюжки повинні переглядати концентратор зведених кожну епоху, завантажувати сховище для будь-яких нових смарт-контрактів, призначених їм, і видаляти всі смарт-контракти, які більше не відповідають за них.
Примітка. Завантаження сховища для деяких смарт-контрактів може бути непростою справою. По-перше, стан недоступний на рівні DA і має досить великий розмір. Це обмежує мінімальний час епохи та вимагає пільгового періоду для підготовки сховища смарт-контрактів.
Сортування стимулів
Мета: використовувати частину винагород у рідному токені для стимулювання резервних секвенсорів.
Більшість зведених пакетів сьогодні побудовано на єдиному ланцюжку, яким керує один або кілька замовників, з метою максимізації часу безвідмовної роботи зведеного пакета. Навпаки, у системі з декількома зведеннями існує кілька незалежних підзведень, кожна з яких має бути онлайн, щоб залишатися активними в загальній системі.
Секвенсери природним чином заохочуються приєднатися до зведених програм для збору MEV, але краще забезпечити відповідні винагороди для цих секвенсерів, оскільки вони більш послідовні та не мають недоречних стимулів, як MEV. Ці винагороди мають надходити від монетарної політики концентратора Rollup.
Крім того, добре мати кілька замовників у режимі очікування та готових до входу, ці замовники можуть приєднатися до системи, коли попит на транзакції зростає, і залишити систему, коли немає обчислювальних ресурсів.
Резервні замовники залишатимуться в черзі замовників і отримають невелику винагороду за наявність. Коли вони обмінюються в Rollup, вони отримають винагороду в повному обсязі. Винагороди надходитимуть від механізму спалювання комісій центру Rollup.
як використовувати
Замовники можуть приєднатися до черги замовників концентратора Rollup, надавши фінансову гарантію (подібно до поточної системи Rollup).
Сортувальники в черзі повинні надати докази DA, що вони мають статус концентратора зведення та можуть читати в будь-який час, щоб приєднатися до зведення.
Коли вони нададуть докази, вони отримають частину винагороди, якою є рідні токени системи. Цей маркер є дескриптором концентратора зведення.
Якщо концентратор Rollup вирішить, що їм потрібен новий Rollup, вони будуть призначені та отримають повну винагороду. Ця винагорода визначається загальною сумою комісій, спожитих системою.
Перехресні зведені транзакції
Ціль: зведені транзакції мають бути миттєвими та прозорими для користувачів.
Перехресна транзакція Rollup між Rollup A та Rollup B повинна складатися з двох частин: 1) транзакція на Rollup A 2) транзакція на Rollup B. Це відбудеться лише тоді, коли транзакція на Rollup A буде успішною та остаточною.
Для швидкого підтвердження гаманці користувачів можуть перевірити, чи трансакція надіслана на базовий рівень DA, і підтвердити дійсність за допомогою ZK. Якщо транзакція включена та дійсна, то секвенсор повинен дійти такого ж висновку для цієї конкретної транзакції.
Ця ідея належить Мустафі Аль-Басаму та Sovereign Labs.
як використовувати
Користувач надсилає транзакцію, яка включає три зведені пакети, скажімо RollupA, B і C.
Давайте подумаємо про конкретний приклад: Rollup A має смарт-контракт стейблкойна, Rollup B має DEX, а Rollup C має протокол кредитування.У цьому прикладі користувач хоче обміняти свій стейблкоїн на інший токен і внести договір позики.
Користувачі повинні спочатку надіслати транзакцію Rollup A, щоб перенести стейблкойни в DEX на Rollup B.
Потім вони можуть подати транзакцію Rollup B DEX, яка обмінює стейблкойн на потрібний токен на Rollup B.
У свою чергу, токен мав бути переданий до RollupC, тому користувач подав третю транзакцію, яка зробила саме це.
Нарешті, користувач відправляє 4-ту й останню транзакцію, вносячи токени в протокол кредитування.
Light Node і Block Explorer
Мета: легкі вузли повинні мати можливість перевіряти смарт-контракти в усіх зведених пакетах, а дослідники блоків повинні забезпечувати уніфіковане уявлення про ланцюг.
Система блокчейн повинна дозволяти будь-кому запускати вузол і перевіряти сам ланцюжок. У цій мультизведеній конструкції, де смарт-контракти постійно перепризначаються іншим підзведеним групам, має бути спосіб відстеження цих конкретних смарт-контрактів. Це зміна мислення від перевірки одного або кількох ланцюжків до перевірки одного чи кількох розумних контрактів. Легкі вузли можуть використовувати докази ZK для перевірки всіх дочірніх зведень за низькою ціною.
Вузли зведення мають підтримувати режим перевірки разом із режимом секвенсора.
Режим перевірки перевіряє стан одного смарт-контракту, на відміну від режиму секвенсора, який передає пакети транзакцій на рівень DA.
Якщо смарт-контракт змінює субкластер, валідаторам потрібно лише оновити субкластер, який вони прослуховують, оскільки вони вже володіли сховищем смарт-контракту до перерозподілу.
Смарт-контракти мають оброблятися в одному зведеному пакеті за раз. Оскільки вони обмежені зведенням, валідатори з однаковою специфікацією повинні мати можливість відстежувати та перевіряти їх.
Легкі вузли можуть використовувати докази ZK для перевірки стану ланцюга за низькими витратами.
Провідники блоків є невід’ємною частиною системи блокчейн. Вони полегшують запити балансу для рідних активів, запити смарт-контрактів і зберігають історію транзакцій від першого блоку до поточного блоку. У цій системі з кількома зведеннями провідник блоків має забезпечувати уніфікований перегляд усіх підзведень.
Провідник блоків має підтримувати запит балансу концентратора Rollup (для власних активів) та історію транзакцій усіх підзведених пакетів.
Подібно до єдиної системи зведення, дослідники блоків використовують для цього індекс. Система з декількома зведеннями повинна індексувати всі зведення, щоб надавати послуги запитів для будь-якого смарт-контракту в системі.
Якщо концентратор зведення вирішить збільшити кількість дочірніх зведень, провідник блоків має бути готовий це впоратися. Вони повинні забезпечувати більшу ємність підзведень або мати систему оркестровки контейнерів (наприклад, Kubernetes) для автоматичного масштабування підзведень.
Вони повинні використовувати номери блоків із рівня DA, щоб підтримувати узгодженість у всіх зведеннях.
на закінчення
Наведений вище дизайн наразі є лише ідеєю, і я, можливо, ніколи не реалізую її далі, але сподіваюся, що ця ідея вас зацікавить. Якщо дизайн пройде, я очікую, що його використовуватимуть у проектах Rollup і наближатимуть можливості масштабування до EIP-4844, Celestia або Avail.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Майбутнє розширення потужностей: концепція дизайну системи Multi-Rollup
Автор: AndreasTzionis; Джерело: ethresear.ch; Упорядник: Yvonne, MarsBit
Довгий час у мене завжди була ідея вирішити деякі проблеми, з якими зараз стикається Rollup, за допомогою мультизведеного (multi-Rollup) дизайну. Приблизно півтора року я думав, що хтось побудує її, але ніколи не заглиблювався в деталі такої системи та не розглядав їх.
Минув деякий час, і, здається, немає єдиного дизайну, який би вирішив проблему, яку я описав у цій публікації, тому я заповню якнайбільше деталей про цю систему, сподіваючись, що хтось зможе взяти натхнення з нього, або навіть з існуючого зведеного Запозичте деякі ідеї.
представити
Однією з проблем, з якими сьогодні стикається Rollup, є взаємодія з користувачем. У багатьох дизайнах Rollups є окремими екосистемами з різними характеристиками. Існують способи взаємодії, але з’єднання кількох різнорідних систем є досить складним завданням. Крім того, важко змусити користувачів зареєструватися для всіх цих зведених пакетів. Вони повинні розуміти кожен Rollup окремо, оцінювати відповідні смарт-контракти, підключати свої гаманці до нових кінцевих точок RPC, підключати активи до ланцюга тощо.
Що, якби існував один дизайн зведення, який міг би забезпечити єдиний досвід для всіх зведень? Як це буде виглядати?
Я ставив собі це питання і прийшов до таких п’яти ідей:
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-24cc855280-dd1a6f-6d2ef1)
Маючи все це на увазі, я придумав дизайн, що складається з концентратора Rollup і змінної кількості дочірніх Rollup. Концентратор Rollup є і реєстром, і балансувальником навантаження для всіх підзведених пакетів, але не обробляє смарт-контракт. Смарт-контракти обробляються в підгрупах.
У наступному розділі я проведу вас через приблизний дизайн, пояснюючи 5 міркувань, які я згадав вище.
Огляд дизайну
Система складається з двох основних компонентів: концентратора Rollup і sub-Rollup. Система концентратора Rollup складається з двох основних компонентів: концентратора Rollup і підпорядкованих компонентів. Концентратор Rollup — це Rollup, який містить усі реєстри смарт-контрактів усіх підзведених пакетів і вирішує, який Rollup відповідає за який смарт-контракт. Крім того, концентратор Rollup містить реєстр усіх сортувальників для іншого дочірнього Rollup. Дочірні ланцюги відповідають за виконання транзакцій для смарт-контрактів, призначених їм концентратором Rollup у реєстрі смарт-контрактів. Реєстр сортувальника містить два основні компоненти для кожної системи сортувальника: концентратор зведення та дочірній зведення. Зведений концентратор — це зведений пакет, який містить усі реєстри смарт-контрактів усіх підзведених пакетів і визначає, який зведений пакет відповідає за який смарт-контракт. Крім того, концентратор Rollup містить реєстр усіх секвенсорів для іншого дочірнього Rollup. Дочірні ланцюги відповідають за виконання транзакцій для смарт-контрактів, призначених їм концентратором Rollup у реєстрі смарт-контрактів. Реєстр секвенсора містить кожну кінцеву точку RPC секвенсора та адресу DA.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-30f0cf6d9f-dd1a6f-6d2ef1)
Реєстр секвенсорів
Реєстр секвенсора діє як відображення глобальних адрес смарт-контрактів на адреси смарт-контрактів. Це використовується для маршрутизації викликів RPC до певного RPC секвенсора, що відповідає запитаному або оновленому смарт-контракту.
Реєстр смарт-контрактів
Реєстр смарт-контрактів діє як відображення глобальних адрес смарт-контрактів на адреси смарт-контрактів.
Зведений ланцюжок
Дочірній ланцюжок зазвичай має корінь стану, і цей маршрут стану можна оновити, викликавши смарт-контракт напряму, або його можна оновити, коли концентратор Rollup призначає смарт-контракт іншому Rollup, у цьому випадку смарт-контракт слід видалити. , а його додають до інших смарт-контрактів.
Уніфікований RPC
Мета: не потрібно підключатися до нового ланцюга для кожного зведення та зробити перехресні транзакції прозорими для користувачів.
Уніфікований RPC відновлює взаємодію користувача з одним ланцюжком у мережі з кількома зведеними пакетами, і користувачам не потрібно підключатися до різних мереж, щоб використовувати різні зведені пакети.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-74756eed1e-dd1a6f-6d2ef1)
Система використовує реєстр зведених секвенсорів із концентратора Rollup, щоб знайти кінцеву точку RPC для секвенсора, який відповідає конкретному смарт-контракту. Потім запит надсилається безпосередньо секвенсору. Кілька транзакцій можна завершити, надсилаючи запити до різних зведених пакетів. Перегляньте наступні розділи, щоб дізнатися більше.
як працювати
Концентратор Rollup підтримує реєстр секвенсорів для всіх дочірніх ланцюжків.
Коли користувач хоче подати нову транзакцію, гаманець користувача запитує реєстр смарт-контрактів, щоб отримати RollupID смарт-контракту, і запитує реєстр секвенсора, щоб отримати кінцеву точку RPC секвенсора в тому ж Rollup.
Потім транзакція надсилається до кінцевої точки RPC секвенсера.
Балансування навантаження
Мета: збалансувати витрати на всі зведені програми
Балансування навантаження дозволяє збалансувати навантаження в Rollup. Коли система засмічується, для обробки навантаження можуть бути створені нові зведені пакети. Коли немає особливої користі, Rollup можна видалити, щоб заощадити ресурси. Крім того, система може уникнути стрибків комісії, перемістивши смарт-контракти з високим попитом у транзакціях на зведені з більш доступною ємністю.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-632aa78015-dd1a6f-6d2ef1)
як працювати
Кожної епохи центр зведення оцінює завантаження всіх зведених даних у системі. Епохи мають тривати кілька годин (можливо, від 6 до 24 годин), щоб уникнути масштабного перерозподілу смарт-контрактів.
Центр зведення може вирішувати, які смарт-контракти перерозповсюджувати, а також коли генерувати чи видаляти зведені пакети, що можна вирішувати автономно за допомогою управління або історії споживання газу різними смарт-контрактами.
Центр зведення перевіряє, чи є навантаження транзакцій у будь-якому зведених даних вище середнього (тобто комісії високі) або нижче середнього (тобто комісії низькі).
Якщо навантаження на зведення вище середнього, концентратор зведення оцінює, які смарт-контракти споживають найбільше газу, і перерозподіляє їх на інше зведення, яке може впоратися з додатковим навантаженням. Після цього смарт-контракт буде вилучено з початкового стану зведення.
Якщо середнє навантаження всіх зведених пакетів вище середнього, концентратор зведених даних створить новий зведений пакет і призначить йому деякі смарт-контракти. Подібним чином, якщо середнє навантаження всіх зведених пакетів нижче середнього, концентратор зведених даних видалить зведений пакет і перепризначить його розумні контракти іншим зведеним пакетам.
Зведені ланцюжки повинні переглядати концентратор зведених кожну епоху, завантажувати сховище для будь-яких нових смарт-контрактів, призначених їм, і видаляти всі смарт-контракти, які більше не відповідають за них.
Примітка. Завантаження сховища для деяких смарт-контрактів може бути непростою справою. По-перше, стан недоступний на рівні DA і має досить великий розмір. Це обмежує мінімальний час епохи та вимагає пільгового періоду для підготовки сховища смарт-контрактів.
Сортування стимулів
Мета: використовувати частину винагород у рідному токені для стимулювання резервних секвенсорів.
Більшість зведених пакетів сьогодні побудовано на єдиному ланцюжку, яким керує один або кілька замовників, з метою максимізації часу безвідмовної роботи зведеного пакета. Навпаки, у системі з декількома зведеннями існує кілька незалежних підзведень, кожна з яких має бути онлайн, щоб залишатися активними в загальній системі.
Секвенсери природним чином заохочуються приєднатися до зведених програм для збору MEV, але краще забезпечити відповідні винагороди для цих секвенсерів, оскільки вони більш послідовні та не мають недоречних стимулів, як MEV. Ці винагороди мають надходити від монетарної політики концентратора Rollup.
Крім того, добре мати кілька замовників у режимі очікування та готових до входу, ці замовники можуть приєднатися до системи, коли попит на транзакції зростає, і залишити систему, коли немає обчислювальних ресурсів.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-02c28a977e-dd1a6f-6d2ef1)
Резервні замовники залишатимуться в черзі замовників і отримають невелику винагороду за наявність. Коли вони обмінюються в Rollup, вони отримають винагороду в повному обсязі. Винагороди надходитимуть від механізму спалювання комісій центру Rollup.
як використовувати
Замовники можуть приєднатися до черги замовників концентратора Rollup, надавши фінансову гарантію (подібно до поточної системи Rollup).
Сортувальники в черзі повинні надати докази DA, що вони мають статус концентратора зведення та можуть читати в будь-який час, щоб приєднатися до зведення.
Коли вони нададуть докази, вони отримають частину винагороди, якою є рідні токени системи. Цей маркер є дескриптором концентратора зведення.
Якщо концентратор Rollup вирішить, що їм потрібен новий Rollup, вони будуть призначені та отримають повну винагороду. Ця винагорода визначається загальною сумою комісій, спожитих системою.
Перехресні зведені транзакції
Ціль: зведені транзакції мають бути миттєвими та прозорими для користувачів.
Перехресна транзакція Rollup між Rollup A та Rollup B повинна складатися з двох частин: 1) транзакція на Rollup A 2) транзакція на Rollup B. Це відбудеться лише тоді, коли транзакція на Rollup A буде успішною та остаточною.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-6899964b00-dd1a6f-6d2ef1)
Для швидкого підтвердження гаманці користувачів можуть перевірити, чи трансакція надіслана на базовий рівень DA, і підтвердити дійсність за допомогою ZK. Якщо транзакція включена та дійсна, то секвенсор повинен дійти такого ж висновку для цієї конкретної транзакції.
Ця ідея належить Мустафі Аль-Басаму та Sovereign Labs.
як використовувати
Користувач надсилає транзакцію, яка включає три зведені пакети, скажімо RollupA, B і C.
Давайте подумаємо про конкретний приклад: Rollup A має смарт-контракт стейблкойна, Rollup B має DEX, а Rollup C має протокол кредитування.У цьому прикладі користувач хоче обміняти свій стейблкоїн на інший токен і внести договір позики.
Користувачі повинні спочатку надіслати транзакцію Rollup A, щоб перенести стейблкойни в DEX на Rollup B.
Потім вони можуть подати транзакцію Rollup B DEX, яка обмінює стейблкойн на потрібний токен на Rollup B.
У свою чергу, токен мав бути переданий до RollupC, тому користувач подав третю транзакцію, яка зробила саме це.
Нарешті, користувач відправляє 4-ту й останню транзакцію, вносячи токени в протокол кредитування.
Light Node і Block Explorer
Мета: легкі вузли повинні мати можливість перевіряти смарт-контракти в усіх зведених пакетах, а дослідники блоків повинні забезпечувати уніфіковане уявлення про ланцюг.
Система блокчейн повинна дозволяти будь-кому запускати вузол і перевіряти сам ланцюжок. У цій мультизведеній конструкції, де смарт-контракти постійно перепризначаються іншим підзведеним групам, має бути спосіб відстеження цих конкретних смарт-контрактів. Це зміна мислення від перевірки одного або кількох ланцюжків до перевірки одного чи кількох розумних контрактів. Легкі вузли можуть використовувати докази ZK для перевірки всіх дочірніх зведень за низькою ціною.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-69f308abb1-dd1a6f-6d2ef1)
Як це працює (легкий клієнт)
Вузли зведення мають підтримувати режим перевірки разом із режимом секвенсора.
Режим перевірки перевіряє стан одного смарт-контракту, на відміну від режиму секвенсора, який передає пакети транзакцій на рівень DA.
Якщо смарт-контракт змінює субкластер, валідаторам потрібно лише оновити субкластер, який вони прослуховують, оскільки вони вже володіли сховищем смарт-контракту до перерозподілу.
Смарт-контракти мають оброблятися в одному зведеному пакеті за раз. Оскільки вони обмежені зведенням, валідатори з однаковою специфікацією повинні мати можливість відстежувати та перевіряти їх.
Легкі вузли можуть використовувати докази ZK для перевірки стану ланцюга за низькими витратами.
Провідники блоків є невід’ємною частиною системи блокчейн. Вони полегшують запити балансу для рідних активів, запити смарт-контрактів і зберігають історію транзакцій від першого блоку до поточного блоку. У цій системі з кількома зведеннями провідник блоків має забезпечувати уніфікований перегляд усіх підзведень.
! [Rollup] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-217876ee66-dd1a6f-6d2ef1)
Як це працює (провідник блоків)
Провідник блоків має підтримувати запит балансу концентратора Rollup (для власних активів) та історію транзакцій усіх підзведених пакетів.
Подібно до єдиної системи зведення, дослідники блоків використовують для цього індекс. Система з декількома зведеннями повинна індексувати всі зведення, щоб надавати послуги запитів для будь-якого смарт-контракту в системі.
Якщо концентратор зведення вирішить збільшити кількість дочірніх зведень, провідник блоків має бути готовий це впоратися. Вони повинні забезпечувати більшу ємність підзведень або мати систему оркестровки контейнерів (наприклад, Kubernetes) для автоматичного масштабування підзведень.
Вони повинні використовувати номери блоків із рівня DA, щоб підтримувати узгодженість у всіх зведеннях.
на закінчення
Наведений вище дизайн наразі є лише ідеєю, і я, можливо, ніколи не реалізую її далі, але сподіваюся, що ця ідея вас зацікавить. Якщо дизайн пройде, я очікую, що його використовуватимуть у проектах Rollup і наближатимуть можливості масштабування до EIP-4844, Celestia або Avail.