У міру того, як використання Rollups збільшується та розміщуються додатки екосистеми, витрати на міграцію для користувачів зростатимуть, а централізовані замовники отримають монопольний вплив на ціноутворення. Контролери централізованих замовників мають право максимізувати отримання вартості (MEV) від користувачів як безпосередньо (наприклад, через комісію), так і опосередковано (наприклад, через початкові транзакції, сендвіч-атаки тощо). — Еспресо
Як зазначає команда Espresso, централізовані Rollups зрештою зіткнуться з монопольним ціноутворенням і проблемами з MEV. Крім того, централізовані зведені за своєю суттю порушують компонування, що призводить до фрагментованих зведених. **
Однак майже всі поточні зведені пакети все ще централізовані, оскільки створення децентралізованого, масштабованого зведеного пакету без дозволів надзвичайно складне. Інша причина полягає в тому, що запуск централізованих зведених пакетів може допомогти інкубувати екосистему та захопити частку ринку.
І коли ми обговорюємо децентралізовані зведені пакети, особливо zkRollups, існує два рівні децентралізації. Перший - це децентралізація перевірки, а другий - децентралізація замовника. Щоб досягти повної децентралізації, також необхідно вирішити проблему координації між замовником і перевірячем.
У зв’язку з тенденцією до модуляції наразі існує три основних типи учасників децентралізованого зведення. Перша категорія спрямована на досягнення повністю децентралізованих зведених пакетів і пропонує повне рішення. Друга категорія - це протоколи, призначені для вирішення мереж пруверів. Нарешті, є кілька рішень, які працюють для децентралізації сортувальника.
Зведені децентралізовані
У zkRollups Polygon і Starknet запропонували рішення для децентралізації своїх Rollups.
Багатокутник
До введення POE (Proof of Efficiency) Polygon zkEVM прийняв POD (Proof of Donation), дозволяючи сортувальнику брати участь у торгах за можливість створити наступну партію транзакцій. Однак це створює проблему, коли одна зловмисна сторона може контролювати всю мережу, зробивши найвищу ставку.
Після прийняття POE замовник і перевірка будуть брати участь у бездозвільній мережі найефективніше за власних апаратних умов. Будь-хто може приєднатися до Polygon zkEVM, якщо це має економічний сенс.
У Polygon zkEVM для сортувальника потрібно 16 ГБ оперативної пам’яті та 4-ядерний ЦП, а для перевірки — 1 ТБ оперативної пам’яті та 128-ядерний ЦП. Крім того, існує роль, яка називається агрегатором, яка відповідає за збір даних L1, надсилання їх перевіряючому, отримання підтвердження та подання його L1. Ми можемо розглядати агрегатор і довідник як один і той самий суб’єкт, оскільки відносини між агрегатором і доводником дуже прості, і агрегатор платить довіднику за надання доказу.
Ця архітектура дуже проста: будь-який замовник може пакувати транзакції на основі попереднього стану на L1 без дозволу та оновлювати відповідний стан. У той же час будь-який агрегатор може надати підтвердження для перевірки оновленого стану.
У POE ефективність відноситься не тільки до ефективності мережі учасників, які конкурують один з одним, але також до економічної ефективності секвенсора та самодостатності. У L2 замовник і перевіряльник ділять комісію за транзакцію, а замовник сплачує пакетну комісію агрегатору за створення доказу. Це гарантує, що учасники мають економічну мотивацію робити внесок у ефективність мережі, що призводить до більш надійної та стійкої екосистеми.
сортувальник
Дохід: комісія за транзакцію L2
Вартість: batchFee (розраховується в $MATIC) + комісія за транзакцію L1 (виклик методу sequenceBatches)
Агрегатор (Prover)
Дохід: партійна комісія (розраховується в $MATIC)
Вартість: вартість підтвердження + комісія за транзакцію L1 (виклик методу verifyBatchesTrustedAggregator)
Координатор: batchFee
вихідні параметри
пакетна комісія= 1 $MATIC
veryBatchTimeTarget = 30 хвилин. Це цільовий час для пакета перевірки. Протокол оновить змінну batchFee, щоб досягти цього цільового часу.
множникBatchFee = 1002. Це множник пакетної комісії в діапазоні від 1000 до 1024 із 3 знаками після коми.
Регулятор
diffBatches: кількість агрегованих пакетів > 30 хвилин мінус кількість пакетів <= 30 хвилин. Максимальне значення 12.
Процес узгодження
Збільште винагороду за агрегацію, щоб стимулювати агрегаторів, коли diffBatches > 0.
Коли diffBatches < 0, зменшіть винагороду за агрегацію, щоб придушити агрегатор і сповільнити процес агрегації.
Starknet
Starknet також прагне створити масштабований зведений пакет із швидким підтвердженням без дозволу. Хоча остаточна специфікація децентралізованого рішення ще не досягнута, вони опублікували кілька чернеток на форумі кілька місяців тому.
Порівняно з простим механізмом Polygon zkEVM, схема Starknet є складнішою, оскільки вона включає консенсус L2 і ланцюговий протокол підтвердження наявності в мережі підтвердження.
сортувальник
Замість простого додавання рівня консенсусу в рівень замовника Starknet пропонує консенсусний протокол подвійної книги. У цьому протоколі L2 забезпечує швидку відповідь як живий протокол, тоді як контрольні точки L1 забезпечують остаточне підтвердження як безпечний протокол.
Для живого протоколу L2 можуть бути прийняті різні механізми консенсусу, наприклад стійкі до Sybil системи PoS, такі як Tendermint або DAG. З іншого боку, безпечний протокол L1 передбачає кілька контрактів, які обслуговують управління частками, перевірку доказів і оновлення статусу відповідно.
Типовий робочий процес консенсусної угоди подвійної книги виглядає наступним чином:
По-перше, використовуйте вихід L2 живої книги як вхідні дані безпечної книги L1, щоб створити перевірену реальну книгу.
Потім візьміть перевірену оперативну книгу як вхідні дані та знову введіть її в чистий консенсусний протокол L2, щоб переконатися, що перевірена жива книга завжди є префіксом поточної книги.
Повторіть описаний вище процес.
Під час створення консенсусного протоколу подвійної книги існує компроміс між вартістю та затримкою. Ідеальне рішення має на меті досягнення низьких витрат і швидкого остаточного затвердження.
Щоб зменшити витрати на газ на L2, Starknet ділить контрольні точки на «хвилинний рівень» і «годинний рівень». Для контрольних точок «хвилинного рівня» лише сам стан закріплюється за ланцюжком, тоді як решта даних (підтвердження дійсності, доступність даних тощо) надсилається через мережу StarkNet L2. Ці дані зберігаються та перевіряються повними вузлами StarkNet. З іншого боку, «погодинні» контрольно-пропускні пункти публічно підтверджені на L1. Обидва типи контрольно-пропускних пунктів забезпечують однакове остаточне підтвердження. Для контрольних точок «хвилинного рівня» підтвердження дійсності перевіряється повними вузлами StarkNet і може бути видано будь-яким вузлом на L1, щоб надати остаточність L1 контрольним точкам «хвилинного рівня». Таким чином, перевірка повинна створити невеликі докази для широкого розповсюдження в мережі L2.
Щоб ще більше зменшити затримку, Starknet пропонує протокол виборів лідера, щоб визначити лідера заздалегідь. Основна логіка полягає в наступному: лідер поточної епохи i заздалегідь визначений на основі кількості ставок L1 і деякої випадковості. Зокрема, в епосі i-2 метод лідера_вибору розміщує сортувальники лексикографічно на основі кількості зобов’язань в епосі i-3. Потім надішліть транзакцію, щоб оновити nonce і вибрати точку навмання. Сортувальник, що відповідає положенню, де падає точка, буде лідером епохи i.
Сертифікатор
У рамках модуля POE існує відкрите змагання між учасниками, яке може призвести до ситуації, коли переможець отримує все. Starknet намагається створити механізм конкуренції без ризику централізації. Ось кілька варіантів:
Ротація: це може частково вирішити проблему централізації, але може не створити стимулів для пошуку найкращої особи для підтвердження роботи.
На основі ставок: сортувальник визначає ймовірність бути обраним перевіряючим на основі суми, яку він робить.
Схема Commit-Reveal: перший коммітент повинен заставити токени, щоб отримати коротку монопольну можливість, а потім створити докази протягом цього часового вікна. Щоб уникнути DDoS-атак, якщо перший не зможе вчасно згенерувати докази, додаткові токени, необхідні другому, зростатимуть експоненціально. Хоча за цим механізмом мережа може втратити машину з найкращою продуктивністю, але можна культивувати більше перевірок.
На додаток до конкуренції серед перевіряючих, необхідно знизити бар’єр входу, щоб більше перевіряючих могли брати участь у мережі. Starknet пропонує складний протокол, що використовує рекурсивні докази, які називаються зв’язаними доказами протоколів.
У протоколах proof-of-chain сам блокчейн розділений на кілька різних форків. Таким чином докази можуть бути не тільки рекурсивними, але й генерація доказів може бути одночасною. Наприклад, у налаштуваннях із 3 гілками 12 чорних блоків поділено на 3 ряди, кожен рядок представляє гілку. Ми можемо розглядати кожну гілку як підланцюг, де кожен блок повинен підтверджувати попередній блок. З точки зору всього ланцюга, слот n повинен підтвердити слот n-3. Інтервал у 3 блоки дає достатньо часу для замовника, щоб заздалегідь розрахувати та придбати докази. Це чимось схоже на шардинг, де зловмиснику потрібно контролювати лише одну гілку, щоб контролювати всю мережу перевірок.
Щоб об’єднати ці гілки разом, Starknet пропонує технологію переплетення, яка може об’єднати кілька вузлів разом для спільної перевірки легітимності транзакцій і забезпечення узгодженості та надійності записів транзакцій.
Одне з рішень полягає в тому, щоб кожен слот об’єднувався з кількома гілками одночасно. Інше рішення полягає в тому, щоб по черзі спробувати кожну гілку об’єднати з іншими гілками, тим самим зменшуючи навантаження на доказ. Звичайно, це також відкрита проблема, і в майбутньому можуть бути кращі рішення.
координація
Щоб активно гарантувати, що перевірка може мати достатній простір для прибутку, Starknet пропонує метод посилання на схему EIP1559: установіть базову плату як нижню межу ціни ресурсу перевірки, активно проводите пошук цін, а сортувальник може використовувати підказки мотивувати того, хто доводить. Таким чином, перевіряльнику завжди будуть переплачувати, і лише крайні випадки вплинуть на процес перевірки. В іншому випадку, якщо правер отримує плату, близьку до ринкової ціни, незначні коливання можуть спровокувати блокування пруера.
Децентралізація сертифікатора
З точки зору Rollups, верифікатор легше досягти децентралізації, ніж сортувальник. Крім того, поточний прувер є вузьким місцем у продуктивності, і йому потрібно не відставати від швидкості дозування сортувальника. Якщо децентралізацію сортувальника не вирішено, децентралізований прувер також може надавати послуги для централізованого сортувальника.
Насправді не тільки Rollups, zkBridge і zkOracle також потребують мережі перевірки. Усі вони потребують сильної розподіленої мережі перевірників.
У довгостроковій перспективі мережа прувера, яка може вмістити різну обчислювальну потужність, є більш стійкою, інакше найефективніші машини монополізують ринок.
Доказовий ринок
Деякі протоколи не координують відносини між секвенсором і прувером, а безпосередньо абстрагують координацію в ринок доказів. На цьому ринку докази є товарами, докази є виробниками доказів, а протоколи є споживачами доказів. Ринкова рівновага найбільш ефективна під впливом «невидимої руки».
Шахта
Міна створила ринок доказів під назвою Snarketplace, де торгують доказами Снарка. Найменшою одиницею тут є доказ Snark однієї транзакції. Mina використовує рекурсивне підтвердження дерева стану під назвою Scan State.
Стан сканування – це ліс двійкових дерев, де кожна транзакція є вузлом. У верхній частині дерева створюється єдиний доказ, який може підтвердити всі транзакції в дереві. У засобу перевірки є два завдання: перше — створити докази, а друге — об’єднати докази.
Після того, як перевірка завершить роботу та подасть заявку, виробник блоків протоколу Mina вибере учасника з найнижчою ціною. Це також рівноважна ціна, оскільки учасники торгів подадуть пропозиції, що перевищуватимуть вартість доказів, а виробники блоків не будуть купувати докази, які не варті грошей.
=нуль; Фундамент
Ринок доказів Mina розроблений для власного протоколу, тоді як =nil; Foundation пропонує загальний ринок доказів для обслуговування всього ринку.
Сервіс Market складається з трьох компонентів: DROP DATABASE, zkLLVM і Proof Market.
DROP DATABASE: це протокол системи керування базами даних, який можна розглядати як рівень DA.
Proof Market: це програма, яка працює на DROP DATABASE, подібно до того, що деякі називають «децентралізованою біржею», стійкою до zk.
zkLLVM: це компілятор, який перетворює мови програмування високого рівня на вхідні дані для перевірених обчислювальних протоколів.
Кожне підтвердження складається з різних входів і схем, тому кожне підтвердження є унікальним. Схема визначає тип доказу, подібно до того, як "пара транзакцій" визначається у фінансових термінах. Крім того, різні системи перевірки містять більше схем.
Робочий процес виглядає наступним чином: сторона попиту на перевірку може написати код на мові програмування високого рівня, а потім передати його в =nil;zkLLVM через ланцюжок інструментів, генеруючи єдину схему, яка стане унікальною торговою парою на ринку.
Що стосується попиту на перевірку, вони можуть знайти компроміс між вартістю та часом. Довірювачі також враховуватимуть свою обчислювальну потужність і дохід. Тому на ринку буде різна обчислювальна потужність, висока обчислювальна потужність генеруватиме докази швидше, але з вищою ціною, тоді як низька обчислювальна потужність генеруватиме докази повільніше, але дешевше.
ДВОХОКІВНЕ КОМІТ
Нещодавно Opside запропонувала двоетапну схему фіксації для децентралізації мережі перевірки. Схема розділяє подання доказів на дві фази, щоб уникнути ситуації, коли найшвидший доказ завжди виграє.
Крок 1: Надішліть хеш доказу нульового знання T-го блоку
Починаючи з блоку T+11, новим перевіркам більше не дозволяється подавати хеші.
Крок 2. Надішліть підтвердження нульового знання
Після блоку T+11 будь-який перевіряльник може подати доказ нульового знання. Якщо принаймні одне підтвердження з нульовим знанням проходить перевірку, воно буде використано для перевірки всіх наданих хешів, а перевірений довідник отримає відповідну винагороду за PoW пропорційно сумі іпотеки.
Якщо жодне підтвердження з нульовим знанням не буде перевірено до T+20-го блоку, усі перевірячі, які надали хеші, будуть оштрафовані. Потім знову відкрийте сортувальник, ви можете надіслати новий хеш, поверніться до кроку 1.
Цей метод може вмістити різну обчислювальну потужність. Однак необхідна застава все ще вводить рівень централізації.
Децентралізація сортувальника
Децентралізація замовників складніша, ніж валідаторів. Це пов’язано з тим, що сортувальник має повноваження пакувати та організовувати транзакції, і необхідно враховувати такі питання, як MEV та розподіл доходу.
З огляду на те, що Ethereum віддаватиме пріоритет швидкості над швидкістю реагування, рішення L2 повинні доповнювати цей компроміс, віддаючи пріоритет швидкості реагування над жвавістю. Однак, порівняно з централізованими сортувальниками, децентралізовані сортувальники за своєю суттю жертвують швидкістю реагування. Тому для вирішення цієї дилеми необхідно впровадити різні оптимізації.
Наразі існує три різні пропозиції децентралізованого сортувальника. Перше рішення реалізується шляхом оптимізації механізму консенсусу. Друга схема передбачає мережу спільних секвенсорів. Третя схема заснована на валідаторах L1.
консенсус
Протокол консенсусу в першу чергу відповідає за впорядкування транзакцій і забезпечення їх доступності, а не за їх виконання. Однак безпосереднє додавання ще одного консенсусного рівня, як згадувалося раніше, непросте рішення.
Щоб покращити швидкість реагування, загальним підходом є використання меншого набору валідаторів. Наприклад, Algorand і Polkadot використовують випадково відібрані менші комітети для групування транзакцій. Усі вузли використовують випадкові маяки та випадкову функцію, яку можна перевірити (VRF), з ймовірністю бути включеними до комітету в певний період, пропорційною сумі їх ставки.
Щоб зменшити мережевий трафік, можна використовувати менші комітети доступності даних (DA). Або скористайтеся VID (Verifiable Information Dispersal). VID поширює код стирання даних усім вузлам, які беруть участь у консенсусі, так що будь-яка підмножина вузлів, які мають достатньо високий коефіцієнт застави, може співпрацювати для відновлення даних. Компромісом цього підходу є зменшення складності трансляції, але збільшення складності відновлення даних.
Для формування набору валідаторів Arbitrum вибрав авторитетні організації, такі як ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) IFF і Unit 410. Компроміс у цьому підході полягає в тому, щоб компенсувати брак кількості шляхом підвищення якості децентралізації.
Спільна мережа секвенсора
Сортувальники відіграють важливу роль у модульних блокчейнах, особливо в Rollups. Кожен Rollup зазвичай створює власну мережу сортувальників. Однак такий підхід не тільки створює проблеми з надлишковістю, але й перешкоджає комбінуванню. Щоб вирішити цю проблему, деякі протоколи пропонують створити спільну мережу сортувальника Rollup. Цей підхід зменшує складність досягнення атомарності, компонування та сумісності, функцій, які відчайдушно потрібні користувачам і розробникам у відкритих блокчейнах без дозволу. Крім того, це також усуває потребу в окремому легкому клієнті для мережі замовника.
Астрія
Astria розробляє блокчейн проміжного програмного забезпечення для екосистеми Celestia Rollup, яка включає власну колекцію розподілених замовників. Цей набір замовників відповідає за прийняття транзакцій від кількох зведених пакетів і запис їх на базовий рівень без їх виконання.
Роль Astria в основному зосереджена на впорядкуванні транзакцій і працює незалежно від базового рівня та Rollup. Дані транзакцій зберігаються на базовому рівні (наприклад, Celestia), тоді як повні вузли Rollup підтримують стан і виконують операції. Це гарантує, що Astria буде відокремлено від Rollup.
На завершення Astria надає два рівні зобов’язань:
«М'яке зобов'язання»: дозволяє Rollup надавати кінцевим користувачам швидкі підтвердження блокування.
«Тверда прихильність»: швидкість така ж, як у базового рівня, що забезпечує вищий рівень безпеки та остаточності.
Еспресо
Espresso зробила значний внесок у сферу технологій без знань. Їх остання розробка — комплексне рішення для децентралізованих сортувальників, яке можна застосувати до Optimistic Rollups і zkRollups.
Децентралізована мережа замовників складається з:
Консенсус HotShot: віддавайте пріоритет високій пропускній здатності та швидкій остаточності над динамічною доступністю.
Espresso DA: поєднання рішення DA на основі комітетів і VID, де вузли з високою пропускною здатністю передають дані всім іншим вузлам. Доступність кожного окремого блоку також підтримується невеликим довільно обраним комітетом. Ідентифікатори VID забезпечують надійне, але повільніше резервне копіювання, гарантуючи доступність, доки не буде порушено досить високий відсоток ваги всіх вузлів.
Зведений REST API: Ethereum сумісний із JSON-RPC.
Контракт секвенсора: перевіряйте консенсус HotShot (тобто діяйте як легкий клієнт) і записуйте контрольні точки (тобто зробіть криптографічне зобов’язання для транзакції), а також керуйте таблицею застави HotShot.
Мережа P2P: протокол Gossip.
Порівняно з Astria, Espresso пропонує DA. Тому робочий процес буде дещо іншим, а саме:
Користувач створює та надсилає транзакцію до Rollup.
Транзакція поширюється через мережу замовника та зберігається в mempool.
Визначте лідера за допомогою механізму застави HotShot, запропонуйте блок і поширте його виконавцям Rollup і перевіряльникам.
Лідер надсилає транзакцію до Комітету з доступності даних і отримує сертифікат DA як зворотний зв’язок.
Лідер також надсилає зобов’язання щодо блоку в контракт Layer 1 Sorter разом із сертифікатом, який контракт використовує для перевірки блоку.
Espresso представляє протокол Gossip для доказів, щоб забезпечити більш гнучку взаємодію з користувачем. Він надає три варіанти остаточності транзакції:
Швидко: користувачі можуть довіряти серверу Rollup, який виконав транзакцію та створив підтвердження, або вони можуть скористатися низькою затримкою HotShot для виконання транзакції.
Помірний: користувач може почекати деякий час, поки буде згенеровано доказ, а потім перевірити його.
Повільно: користувачі можуть чекати оновлень перевіреного стану L1, щоб отримати оновлений стан без будь-яких припущень довіри чи розрахунків.
На додаток до вищезгаданої оптимізації, Espresso також планує залучити весь набір валідатора Ethereum до участі в роботі протоколу замовника Espresso. Використання того самого набору валідаторів забезпечить аналогічну безпеку, а обмін значеннями з валідаторами L1 буде більш безпечним. Крім того, Espresso також може скористатися перевагами рішення для переставлення ETH, наданого EigenLayer.
Радіус
Radius створює ненадійний рівень спільного впорядкування на основі доказів з нульовим знанням, зосереджуючись на вирішенні проблеми MEV у L2, оскільки дохід L2 в основному надходить від блокового простору. Компромісом, який слід враховувати, є баланс між доходом MEV і L2. Метою Radius є усунення MEV, який є шкідливим для користувачів, і пропонує дворівневий сервіс.
Верхній рівень націлений на звичайні транзакції користувачів і забезпечує криптографічний захист від небажаного MEV за допомогою головоломок блокування часу. Зокрема, у ньому використовується технологія відкладеного шифрування з можливістю практичної перевірки (PVDE), яка генерує докази з нульовим знанням для головоломок із блокуванням часу на основі RSA за 5 секунд. Цей метод забезпечує практичне рішення для захисту користувачів від шкідливих MEV. Коротше кажучи, вміст транзакції не може бути відомий, доки секвенсор не визначить порядок транзакцій.
Базовий рівень призначений для розробників блоків і дозволяє їм брати участь у прибутковій діяльності, одночасно пом’якшуючи негативний вплив MEV.
Зведення на основі
Based Rollup — це концепція, нещодавно запропонована Джастіном Дрейком, де автори блоків L1 співпрацюють із пошукачами та розробниками L1, щоб включити блоки зведення в наступний блок L1 без дозволу. Його можна розглядати як мережу спільних секвенсорів на L1. Переваги та недоліки Based Rollup очевидні.
З позитивного боку, Based Rollup використовує переваги жвавості та децентралізації, які забезпечує L1, і його реалізація проста та ефективна. Based Rollup також економічно сумісний з L1. Однак це не означає, що Based Rollup порушує його суверенітет. Хоча MEV передано L1, Based Rollup все ще може володіти маркерами управління та стягувати базову комісію. Виходячи з гіпотези, Based Rollup може скористатися цими перевагами, досягти домінування та, зрештою, максимізувати віддачу.
на завершення
Дивлячись на запропоновані пропозиції, можна побачити, що децентралізація Rollup ще має пройти довгий шлях. Деякі з цих пропозицій все ще знаходяться на стадії чернетки та потребують подальшого обговорення, тоді як інші мають лише завершені попередні специфікації. Усі ці сценарії необхідно впровадити та ретельно перевірити.
Хоча деякі зведені пакети можуть явно не пропонувати відповідне децентралізоване рішення, вони часто включають механізми виходу для вирішення окремих точок відмови через централізовані замовники. Наприклад, zkSync надає метод FullExit, який дозволяє користувачам виводити свої кошти безпосередньо з L1. Коли система переходить в режим виходу і не може обробити нові блоки, користувач може почати операцію виведення.
Щоб забезпечити стійкість до цензури, ці зведені пакети часто також дозволяють користувачам надсилати транзакції безпосередньо на L1. Наприклад, zkSync використовує чергу пріоритетів для таких транзакцій, надісланих на L1. Подібним чином Polygon zkEVM включає пакетний метод примусової дії в контракті L1. Якщо агрегування не відбувається протягом тижня, користувач може викликати цей метод на L1 і надати байтовий масив транзакції та послуги BathFee для перевірки.
Безсумнівно те, що в осяжному майбутньому децентралізація Rollup буде комбінованим рішенням, яке може включати вищезазначені важливі рішення або деякі інші інноваційні варіанти.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Розуміння децентралізованих зведених пакетів в одній статті
Оригінальна назва: "Decentralized Rollups"
У міру того, як використання Rollups збільшується та розміщуються додатки екосистеми, витрати на міграцію для користувачів зростатимуть, а централізовані замовники отримають монопольний вплив на ціноутворення. Контролери централізованих замовників мають право максимізувати отримання вартості (MEV) від користувачів як безпосередньо (наприклад, через комісію), так і опосередковано (наприклад, через початкові транзакції, сендвіч-атаки тощо). — Еспресо
Як зазначає команда Espresso, централізовані Rollups зрештою зіткнуться з монопольним ціноутворенням і проблемами з MEV. Крім того, централізовані зведені за своєю суттю порушують компонування, що призводить до фрагментованих зведених. **
Однак майже всі поточні зведені пакети все ще централізовані, оскільки створення децентралізованого, масштабованого зведеного пакету без дозволів надзвичайно складне. Інша причина полягає в тому, що запуск централізованих зведених пакетів може допомогти інкубувати екосистему та захопити частку ринку.
І коли ми обговорюємо децентралізовані зведені пакети, особливо zkRollups, існує два рівні децентралізації. Перший - це децентралізація перевірки, а другий - децентралізація замовника. Щоб досягти повної децентралізації, також необхідно вирішити проблему координації між замовником і перевірячем.
У зв’язку з тенденцією до модуляції наразі існує три основних типи учасників децентралізованого зведення. Перша категорія спрямована на досягнення повністю децентралізованих зведених пакетів і пропонує повне рішення. Друга категорія - це протоколи, призначені для вирішення мереж пруверів. Нарешті, є кілька рішень, які працюють для децентралізації сортувальника.
Зведені децентралізовані
У zkRollups Polygon і Starknet запропонували рішення для децентралізації своїх Rollups.
Багатокутник
До введення POE (Proof of Efficiency) Polygon zkEVM прийняв POD (Proof of Donation), дозволяючи сортувальнику брати участь у торгах за можливість створити наступну партію транзакцій. Однак це створює проблему, коли одна зловмисна сторона може контролювати всю мережу, зробивши найвищу ставку.
Після прийняття POE замовник і перевірка будуть брати участь у бездозвільній мережі найефективніше за власних апаратних умов. Будь-хто може приєднатися до Polygon zkEVM, якщо це має економічний сенс.
У Polygon zkEVM для сортувальника потрібно 16 ГБ оперативної пам’яті та 4-ядерний ЦП, а для перевірки — 1 ТБ оперативної пам’яті та 128-ядерний ЦП. Крім того, існує роль, яка називається агрегатором, яка відповідає за збір даних L1, надсилання їх перевіряючому, отримання підтвердження та подання його L1. Ми можемо розглядати агрегатор і довідник як один і той самий суб’єкт, оскільки відносини між агрегатором і доводником дуже прості, і агрегатор платить довіднику за надання доказу.
Ця архітектура дуже проста: будь-який замовник може пакувати транзакції на основі попереднього стану на L1 без дозволу та оновлювати відповідний стан. У той же час будь-який агрегатор може надати підтвердження для перевірки оновленого стану.
У POE ефективність відноситься не тільки до ефективності мережі учасників, які конкурують один з одним, але також до економічної ефективності секвенсора та самодостатності. У L2 замовник і перевіряльник ділять комісію за транзакцію, а замовник сплачує пакетну комісію агрегатору за створення доказу. Це гарантує, що учасники мають економічну мотивацію робити внесок у ефективність мережі, що призводить до більш надійної та стійкої екосистеми.
сортувальник
Агрегатор (Prover)
Координатор: batchFee
Starknet
Starknet також прагне створити масштабований зведений пакет із швидким підтвердженням без дозволу. Хоча остаточна специфікація децентралізованого рішення ще не досягнута, вони опублікували кілька чернеток на форумі кілька місяців тому.
Порівняно з простим механізмом Polygon zkEVM, схема Starknet є складнішою, оскільки вона включає консенсус L2 і ланцюговий протокол підтвердження наявності в мережі підтвердження.
сортувальник
Замість простого додавання рівня консенсусу в рівень замовника Starknet пропонує консенсусний протокол подвійної книги. У цьому протоколі L2 забезпечує швидку відповідь як живий протокол, тоді як контрольні точки L1 забезпечують остаточне підтвердження як безпечний протокол.
Для живого протоколу L2 можуть бути прийняті різні механізми консенсусу, наприклад стійкі до Sybil системи PoS, такі як Tendermint або DAG. З іншого боку, безпечний протокол L1 передбачає кілька контрактів, які обслуговують управління частками, перевірку доказів і оновлення статусу відповідно.
Типовий робочий процес консенсусної угоди подвійної книги виглядає наступним чином:
По-перше, використовуйте вихід L2 живої книги як вхідні дані безпечної книги L1, щоб створити перевірену реальну книгу.
Потім візьміть перевірену оперативну книгу як вхідні дані та знову введіть її в чистий консенсусний протокол L2, щоб переконатися, що перевірена жива книга завжди є префіксом поточної книги.
Повторіть описаний вище процес.
Під час створення консенсусного протоколу подвійної книги існує компроміс між вартістю та затримкою. Ідеальне рішення має на меті досягнення низьких витрат і швидкого остаточного затвердження.
Щоб зменшити витрати на газ на L2, Starknet ділить контрольні точки на «хвилинний рівень» і «годинний рівень». Для контрольних точок «хвилинного рівня» лише сам стан закріплюється за ланцюжком, тоді як решта даних (підтвердження дійсності, доступність даних тощо) надсилається через мережу StarkNet L2. Ці дані зберігаються та перевіряються повними вузлами StarkNet. З іншого боку, «погодинні» контрольно-пропускні пункти публічно підтверджені на L1. Обидва типи контрольно-пропускних пунктів забезпечують однакове остаточне підтвердження. Для контрольних точок «хвилинного рівня» підтвердження дійсності перевіряється повними вузлами StarkNet і може бути видано будь-яким вузлом на L1, щоб надати остаточність L1 контрольним точкам «хвилинного рівня». Таким чином, перевірка повинна створити невеликі докази для широкого розповсюдження в мережі L2.
Щоб ще більше зменшити затримку, Starknet пропонує протокол виборів лідера, щоб визначити лідера заздалегідь. Основна логіка полягає в наступному: лідер поточної епохи i заздалегідь визначений на основі кількості ставок L1 і деякої випадковості. Зокрема, в епосі i-2 метод лідера_вибору розміщує сортувальники лексикографічно на основі кількості зобов’язань в епосі i-3. Потім надішліть транзакцію, щоб оновити nonce і вибрати точку навмання. Сортувальник, що відповідає положенню, де падає точка, буде лідером епохи i.
Сертифікатор
У рамках модуля POE існує відкрите змагання між учасниками, яке може призвести до ситуації, коли переможець отримує все. Starknet намагається створити механізм конкуренції без ризику централізації. Ось кілька варіантів:
На додаток до конкуренції серед перевіряючих, необхідно знизити бар’єр входу, щоб більше перевіряючих могли брати участь у мережі. Starknet пропонує складний протокол, що використовує рекурсивні докази, які називаються зв’язаними доказами протоколів.
У протоколах proof-of-chain сам блокчейн розділений на кілька різних форків. Таким чином докази можуть бути не тільки рекурсивними, але й генерація доказів може бути одночасною. Наприклад, у налаштуваннях із 3 гілками 12 чорних блоків поділено на 3 ряди, кожен рядок представляє гілку. Ми можемо розглядати кожну гілку як підланцюг, де кожен блок повинен підтверджувати попередній блок. З точки зору всього ланцюга, слот n повинен підтвердити слот n-3. Інтервал у 3 блоки дає достатньо часу для замовника, щоб заздалегідь розрахувати та придбати докази. Це чимось схоже на шардинг, де зловмиснику потрібно контролювати лише одну гілку, щоб контролювати всю мережу перевірок.
Щоб об’єднати ці гілки разом, Starknet пропонує технологію переплетення, яка може об’єднати кілька вузлів разом для спільної перевірки легітимності транзакцій і забезпечення узгодженості та надійності записів транзакцій.
Одне з рішень полягає в тому, щоб кожен слот об’єднувався з кількома гілками одночасно. Інше рішення полягає в тому, щоб по черзі спробувати кожну гілку об’єднати з іншими гілками, тим самим зменшуючи навантаження на доказ. Звичайно, це також відкрита проблема, і в майбутньому можуть бути кращі рішення.
координація
Щоб активно гарантувати, що перевірка може мати достатній простір для прибутку, Starknet пропонує метод посилання на схему EIP1559: установіть базову плату як нижню межу ціни ресурсу перевірки, активно проводите пошук цін, а сортувальник може використовувати підказки мотивувати того, хто доводить. Таким чином, перевіряльнику завжди будуть переплачувати, і лише крайні випадки вплинуть на процес перевірки. В іншому випадку, якщо правер отримує плату, близьку до ринкової ціни, незначні коливання можуть спровокувати блокування пруера.
Децентралізація сертифікатора
З точки зору Rollups, верифікатор легше досягти децентралізації, ніж сортувальник. Крім того, поточний прувер є вузьким місцем у продуктивності, і йому потрібно не відставати від швидкості дозування сортувальника. Якщо децентралізацію сортувальника не вирішено, децентралізований прувер також може надавати послуги для централізованого сортувальника.
Насправді не тільки Rollups, zkBridge і zkOracle також потребують мережі перевірки. Усі вони потребують сильної розподіленої мережі перевірників.
У довгостроковій перспективі мережа прувера, яка може вмістити різну обчислювальну потужність, є більш стійкою, інакше найефективніші машини монополізують ринок.
Доказовий ринок
Деякі протоколи не координують відносини між секвенсором і прувером, а безпосередньо абстрагують координацію в ринок доказів. На цьому ринку докази є товарами, докази є виробниками доказів, а протоколи є споживачами доказів. Ринкова рівновага найбільш ефективна під впливом «невидимої руки».
Шахта
Міна створила ринок доказів під назвою Snarketplace, де торгують доказами Снарка. Найменшою одиницею тут є доказ Snark однієї транзакції. Mina використовує рекурсивне підтвердження дерева стану під назвою Scan State.
Стан сканування – це ліс двійкових дерев, де кожна транзакція є вузлом. У верхній частині дерева створюється єдиний доказ, який може підтвердити всі транзакції в дереві. У засобу перевірки є два завдання: перше — створити докази, а друге — об’єднати докази.
Після того, як перевірка завершить роботу та подасть заявку, виробник блоків протоколу Mina вибере учасника з найнижчою ціною. Це також рівноважна ціна, оскільки учасники торгів подадуть пропозиції, що перевищуватимуть вартість доказів, а виробники блоків не будуть купувати докази, які не варті грошей.
=нуль; Фундамент
Ринок доказів Mina розроблений для власного протоколу, тоді як =nil; Foundation пропонує загальний ринок доказів для обслуговування всього ринку.
Сервіс Market складається з трьох компонентів: DROP DATABASE, zkLLVM і Proof Market.
Кожне підтвердження складається з різних входів і схем, тому кожне підтвердження є унікальним. Схема визначає тип доказу, подібно до того, як "пара транзакцій" визначається у фінансових термінах. Крім того, різні системи перевірки містять більше схем.
Робочий процес виглядає наступним чином: сторона попиту на перевірку може написати код на мові програмування високого рівня, а потім передати його в =nil;zkLLVM через ланцюжок інструментів, генеруючи єдину схему, яка стане унікальною торговою парою на ринку.
Що стосується попиту на перевірку, вони можуть знайти компроміс між вартістю та часом. Довірювачі також враховуватимуть свою обчислювальну потужність і дохід. Тому на ринку буде різна обчислювальна потужність, висока обчислювальна потужність генеруватиме докази швидше, але з вищою ціною, тоді як низька обчислювальна потужність генеруватиме докази повільніше, але дешевше.
ДВОХОКІВНЕ КОМІТ
Нещодавно Opside запропонувала двоетапну схему фіксації для децентралізації мережі перевірки. Схема розділяє подання доказів на дві фази, щоб уникнути ситуації, коли найшвидший доказ завжди виграє.
Цей метод може вмістити різну обчислювальну потужність. Однак необхідна застава все ще вводить рівень централізації.
Децентралізація сортувальника
Децентралізація замовників складніша, ніж валідаторів. Це пов’язано з тим, що сортувальник має повноваження пакувати та організовувати транзакції, і необхідно враховувати такі питання, як MEV та розподіл доходу.
З огляду на те, що Ethereum віддаватиме пріоритет швидкості над швидкістю реагування, рішення L2 повинні доповнювати цей компроміс, віддаючи пріоритет швидкості реагування над жвавістю. Однак, порівняно з централізованими сортувальниками, децентралізовані сортувальники за своєю суттю жертвують швидкістю реагування. Тому для вирішення цієї дилеми необхідно впровадити різні оптимізації.
Наразі існує три різні пропозиції децентралізованого сортувальника. Перше рішення реалізується шляхом оптимізації механізму консенсусу. Друга схема передбачає мережу спільних секвенсорів. Третя схема заснована на валідаторах L1.
консенсус
Протокол консенсусу в першу чергу відповідає за впорядкування транзакцій і забезпечення їх доступності, а не за їх виконання. Однак безпосереднє додавання ще одного консенсусного рівня, як згадувалося раніше, непросте рішення.
Щоб покращити швидкість реагування, загальним підходом є використання меншого набору валідаторів. Наприклад, Algorand і Polkadot використовують випадково відібрані менші комітети для групування транзакцій. Усі вузли використовують випадкові маяки та випадкову функцію, яку можна перевірити (VRF), з ймовірністю бути включеними до комітету в певний період, пропорційною сумі їх ставки.
Щоб зменшити мережевий трафік, можна використовувати менші комітети доступності даних (DA). Або скористайтеся VID (Verifiable Information Dispersal). VID поширює код стирання даних усім вузлам, які беруть участь у консенсусі, так що будь-яка підмножина вузлів, які мають достатньо високий коефіцієнт застави, може співпрацювати для відновлення даних. Компромісом цього підходу є зменшення складності трансляції, але збільшення складності відновлення даних.
Для формування набору валідаторів Arbitrum вибрав авторитетні організації, такі як ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Distributed Ledger Research Center (DLRC) IFF і Unit 410. Компроміс у цьому підході полягає в тому, щоб компенсувати брак кількості шляхом підвищення якості децентралізації.
Спільна мережа секвенсора
Сортувальники відіграють важливу роль у модульних блокчейнах, особливо в Rollups. Кожен Rollup зазвичай створює власну мережу сортувальників. Однак такий підхід не тільки створює проблеми з надлишковістю, але й перешкоджає комбінуванню. Щоб вирішити цю проблему, деякі протоколи пропонують створити спільну мережу сортувальника Rollup. Цей підхід зменшує складність досягнення атомарності, компонування та сумісності, функцій, які відчайдушно потрібні користувачам і розробникам у відкритих блокчейнах без дозволу. Крім того, це також усуває потребу в окремому легкому клієнті для мережі замовника.
Астрія
Astria розробляє блокчейн проміжного програмного забезпечення для екосистеми Celestia Rollup, яка включає власну колекцію розподілених замовників. Цей набір замовників відповідає за прийняття транзакцій від кількох зведених пакетів і запис їх на базовий рівень без їх виконання.
Роль Astria в основному зосереджена на впорядкуванні транзакцій і працює незалежно від базового рівня та Rollup. Дані транзакцій зберігаються на базовому рівні (наприклад, Celestia), тоді як повні вузли Rollup підтримують стан і виконують операції. Це гарантує, що Astria буде відокремлено від Rollup.
На завершення Astria надає два рівні зобов’язань:
Еспресо
Espresso зробила значний внесок у сферу технологій без знань. Їх остання розробка — комплексне рішення для децентралізованих сортувальників, яке можна застосувати до Optimistic Rollups і zkRollups.
Децентралізована мережа замовників складається з:
Порівняно з Astria, Espresso пропонує DA. Тому робочий процес буде дещо іншим, а саме:
Користувач створює та надсилає транзакцію до Rollup.
Транзакція поширюється через мережу замовника та зберігається в mempool.
Визначте лідера за допомогою механізму застави HotShot, запропонуйте блок і поширте його виконавцям Rollup і перевіряльникам.
Лідер надсилає транзакцію до Комітету з доступності даних і отримує сертифікат DA як зворотний зв’язок.
Лідер також надсилає зобов’язання щодо блоку в контракт Layer 1 Sorter разом із сертифікатом, який контракт використовує для перевірки блоку.
Espresso представляє протокол Gossip для доказів, щоб забезпечити більш гнучку взаємодію з користувачем. Він надає три варіанти остаточності транзакції:
На додаток до вищезгаданої оптимізації, Espresso також планує залучити весь набір валідатора Ethereum до участі в роботі протоколу замовника Espresso. Використання того самого набору валідаторів забезпечить аналогічну безпеку, а обмін значеннями з валідаторами L1 буде більш безпечним. Крім того, Espresso також може скористатися перевагами рішення для переставлення ETH, наданого EigenLayer.
Радіус
Radius створює ненадійний рівень спільного впорядкування на основі доказів з нульовим знанням, зосереджуючись на вирішенні проблеми MEV у L2, оскільки дохід L2 в основному надходить від блокового простору. Компромісом, який слід враховувати, є баланс між доходом MEV і L2. Метою Radius є усунення MEV, який є шкідливим для користувачів, і пропонує дворівневий сервіс.
Верхній рівень націлений на звичайні транзакції користувачів і забезпечує криптографічний захист від небажаного MEV за допомогою головоломок блокування часу. Зокрема, у ньому використовується технологія відкладеного шифрування з можливістю практичної перевірки (PVDE), яка генерує докази з нульовим знанням для головоломок із блокуванням часу на основі RSA за 5 секунд. Цей метод забезпечує практичне рішення для захисту користувачів від шкідливих MEV. Коротше кажучи, вміст транзакції не може бути відомий, доки секвенсор не визначить порядок транзакцій.
Базовий рівень призначений для розробників блоків і дозволяє їм брати участь у прибутковій діяльності, одночасно пом’якшуючи негативний вплив MEV.
Зведення на основі
Based Rollup — це концепція, нещодавно запропонована Джастіном Дрейком, де автори блоків L1 співпрацюють із пошукачами та розробниками L1, щоб включити блоки зведення в наступний блок L1 без дозволу. Його можна розглядати як мережу спільних секвенсорів на L1. Переваги та недоліки Based Rollup очевидні.
З позитивного боку, Based Rollup використовує переваги жвавості та децентралізації, які забезпечує L1, і його реалізація проста та ефективна. Based Rollup також економічно сумісний з L1. Однак це не означає, що Based Rollup порушує його суверенітет. Хоча MEV передано L1, Based Rollup все ще може володіти маркерами управління та стягувати базову комісію. Виходячи з гіпотези, Based Rollup може скористатися цими перевагами, досягти домінування та, зрештою, максимізувати віддачу.
на завершення
Дивлячись на запропоновані пропозиції, можна побачити, що децентралізація Rollup ще має пройти довгий шлях. Деякі з цих пропозицій все ще знаходяться на стадії чернетки та потребують подальшого обговорення, тоді як інші мають лише завершені попередні специфікації. Усі ці сценарії необхідно впровадити та ретельно перевірити.
Хоча деякі зведені пакети можуть явно не пропонувати відповідне децентралізоване рішення, вони часто включають механізми виходу для вирішення окремих точок відмови через централізовані замовники. Наприклад, zkSync надає метод FullExit, який дозволяє користувачам виводити свої кошти безпосередньо з L1. Коли система переходить в режим виходу і не може обробити нові блоки, користувач може почати операцію виведення.
Щоб забезпечити стійкість до цензури, ці зведені пакети часто також дозволяють користувачам надсилати транзакції безпосередньо на L1. Наприклад, zkSync використовує чергу пріоритетів для таких транзакцій, надісланих на L1. Подібним чином Polygon zkEVM включає пакетний метод примусової дії в контракті L1. Якщо агрегування не відбувається протягом тижня, користувач може викликати цей метод на L1 і надати байтовий масив транзакції та послуги BathFee для перевірки.
Безсумнівно те, що в осяжному майбутньому децентралізація Rollup буде комбінованим рішенням, яке може включати вищезазначені важливі рішення або деякі інші інноваційні варіанти.