Вступ: Ця стаття складається з розпорошених заяв дослідника Celestia Нешкью про аналіз моделі Rollup, включаючи 4 нові варіанти Rollup. Раніше, в статті " Дослідник Celestia проаналізував 6 варіантів Rollup: Sequencer=Aggregator+Header Generator«, він перерахував 6 різних моделей Rollup, і ця стаття є новою абстракцією 4 типів моделей Rollup на основі цієї статті.

Раніше NashQ розділив секвенційний Секвенер на два модулі, Агрегатор + Виробник заголовків, та пройшов через життєвий цикл транзакційних інструкцій, щоб пояснити, як працює Celestia Sovereign Rollup, досліджуючи стійкість до цензури та активність різних варіантів Rollup, а також мінімальну конфігурацію для користувача, який має бути мінімізований відносно довіри (тобто, бути безпечним у відношенні до довіри, які типи вузлів Rollup має запустити користувач).

Варіант 7: Базовий Rollup + Кілька виробників заголовків + "найвищий протокол MEV"

У цій варіанті Rollup користувач мережі Rollup напряму публікує дані транзакції на блок DA, а потім Виробник заголовків відповідає за впорядкування транзакцій та MEV видобувається ним. Очевидно, що процес агрегації/включення транзакцій у варіант Rollup 7 є таким самим, як у раніше введеного Based Rollup, який обробляється на рівні DA (користувачі напряму публікують свої транзакції на рівень DA), але відсортування транзакцій відрізняється від Based Rollup тим, що вузли рівня DA не відповідають за сортування, це відбувається на рівні HP (Виробник заголовків).

Припустимо, що є три HP, які конкурують один з одним і дотримуються протоколу розподілу MEV під назвою «MEV найвищого протоколу». Цей протокол запропонований протоколом пропуску екосистеми Cosmos, який відрізняється від схеми Ether PBS тим, що розробники блоків платять додаткові «чайові» валідаторам мережі блокчейн, а блоки, побудовані найбільш чайовими будівельниками, приймаються валідаторами. Блоки, побудовані найкращими будівельниками, будуть прийняті валідаторами. У той же час, SKIP Protocol висуває концепцію «Sovereign MEV», яка має намір дозволити всім валідаторам і спільноті публічної мережі ланцюга мати автономію розподілу MEV, а також вирішити проблему посилення централізації будівельників за рахунок ефекту маховика в Ethernet PBS (але це не є основою даної статті). ).

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

Крім того, Заголовок пакета, опублікований HP, повинен відповідати повному пакету транзакцій на рівні DA.

Якщо у заголовку, опублікованому HP, є помилка, наприклад, результат виконання транзакції Stateroot неправильний або він не містить певної транзакції в Пакеті (втрачена транзакція), чесний вузол повного Rollup розповсюджує доказ шахрайства шахрайства на легкий вузол. Однак зазвичай (оптимістично) легкий вузол може прийняти заголовок, опублікований HP, і вважати, що у ньому немає проблем.

Аналіз стійкості до цензури: 2 точки існують в цьому Rollup, де можливий цензурний аналіз транзакцій. Перша існує на рівні DA, де він може переглядати вміст транзакцій та відхиляти включення певних транзакцій користувачів. Друге місце все ще знаходиться на рівні DA, воно може переглядати заголовок, надісланий HP, і відмовлятися включати певний заголовок, щоб узгодити з заголовком монополізувати MEV через атаку цензури.

У той ж час послідовність транзакцій обробляється HP, і через наявність доказів шахрайства (які можуть бути використані проти випадку відкидання транзакцій HP), сам HP відмовляється запускати атаки цензури, але може підкупляти вузли шару DA зробити це (або запустити деякі вузли шару DA самостійно). Рішення полягає в тому, щоб збільшити період часу, протягом якого послідовність транзакцій Rollup остаточно узгоджується, щоб заголовок, відхилений зловмисним вузлом шару DA, міг бути включений в ланцюг чесним вузлом шару DA вчасно до закінчення періоду часу, що в свою чергу збільшує складність атаки цензури вузла шару DA.

Вправа: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Якщо шар DA має активний дефект, то Rollup також матиме активний дефект. На цій підставі Rollup матиме активний дефект лише у випадку, якщо всі HP мають активний дефект.

Варіант 8: ZK Rollup зі спільним агрегатором + Децентралізований підтверджувач

Варіант 8 використовує Спільний агрегатор (SA) для включення транзакцій + упорядкування, де SA публікує пакет послідовності транзакцій на рівень DA, і теоретично порядок транзакцій не змінюється після надсилання послідовності транзакцій на рівень DA.

І перед тим, як Партія буде відправлена на рівень DA, Спільний агрегатор SA може спочатку розіслати Партію + Заголовок SA на повний вузол і Доведення, а також Заголовок SA на легкий вузол, за винятком того, що на цей момент Партія, яка не знаходиться на рівні DA, все ще нестабільна, і може бути замінена у будь-який момент.

Важливо зауважити, що Заголовок, опублікований Спільним агрегатором SA, не є тим же самим, що й Пакетний заголовок, опублікований HP. У заголовку SA містяться криптографічні докази, щоб забезпечити, що Пакет, який вузол Rollup читає з рівня DA, був дійсно згенерований SA, а не підроблений ним.

Доказувач читає партію транзакцій Batch з рівня DA (а також синхронізується безпосередньо зі спільним агрегатором), генерує доказ ZK Proof+Batch Header та публікує його на рівні DA. Очевидно, Доказувач діє як HP.

Для легкого вузла Rollup після отримання ZKProof послідовність транзакцій, що містяться у цьому партії, буде завершена. Звісно, Prover також може транслювати ZKP через мережу Rollup p2p під ланцюгом DA, щоб його можна було отримати легкими вузлами швидше, але в цей час ZKP ще не був відправлений на рівень DA і не має «остаточності».

Стійкість до цензури: у варіанті 8 шар DA не може здійснювати цензурні атаки на деякі конкретні транзакції ручки, але може здійснювати лише партійні цензурні атаки на всю партію транзакцій, надіслану спільним агрегатором. У той же час спільний агрегатор може відмовитися від упаковки певних транзакцій користувачів.

Активний: L = L_da && L_sa && L_pm. Якщо будь-яка частина цієї варіанту не вдасться активно, то Rollup також не вдасться активно. Якщо провідник зазнає невдачі, то легкий вузол не зможе ефективно синхронізувати прогрес журналу Rollup. Але оскільки повний вузол синхронізує всю послідовність транзакцій пакетом, він може відстежувати прогрес книги. На цей момент повний вузол не порушується, і всі легкі вузли не вдаються, що еквівалентно раніше описаному випадку Rollup зі спільним агрегатором.

Мінімальна конфігурація для мінімізації довіри: легкі вузли DA tier + легкі вузли спільної агрегації мережі + легкі вузли Rollup

Варіант 9: Спільний агрегатор + Децентралізований підтверджувач + ZK-Rollup з кількома DAs

Варіант 9 фактично ґрунтується на вищеописаному розгортанні варіанту 8, за винятком того, що в ньому є більше одного рівня DA, які можуть ефективно покращити активність Rollup. У варіанті 9 загальний агрегатор SA може опублікувати послідовність транзакцій Batch на будь-який рівень DA, і він може вибрати різні рівні DA для публікації даних відповідно до своїх потреб, щоб динамічно оптимізувати відповідні параметри Rollup, такі як: вартість даних, безпека, активність, затримка транзакції та закінчення.

Залежно від потреб зведеного проектора можна налаштувати найдешевший, найбезпечніший, найактивніший і найшвидший зведений проектор, а також вибрати шар DA з найвищою пропускною здатністю. Взагалі кажучи, пакет певної висоти блоку зведення (наприклад, 10 000-й) не обов'язково повинен існувати на різних шарах DA одночасно, але якщо вони існують, їх вміст повинен бути однаковим. Якщо два пакети з однаковою висотою та різним вмістом присутні на різних шарах DA, це означає, що спільний агрегатор навмисно бере участь у форку реєстру.

Тут ми обираємо такий самий децентралізований ринок Prover, як у варіанті 8, де Prover виступає як виробник заголовків та публікує пакетний заголовок та ZKProof. на цьому етапі Prover повинен конкурувати через механізм аукціону підказок, згаданий у варіанті 7 (запропонований протоколом SKIP).

Швидкість розрахунків угод (швидкість остаточного підтвердження) варіанту 9 залежить від швидкості роботи найшвидшого шару DA з блоків.

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

Діяльність: L = ( L_da1 || L_da2) && L_sa && L_pm.

Варіант 9 більш активний у порівнянні з попередніми варіантами. До тих пір, поки у всіх мережах рівня DA немає збою активності, все може протікати нормально.

Мінімальна конфігурація для мінімізації довіри: легкі ноди в різних шарах DA + легкі вузли мережі спільних агрегаторів + легкі вузли Rollup.

Очевидно, що чим більше шарів DA ми використовуємо, тим більше легких вузлів ми повинні запустити. Але вигоди від цього можуть перекрити його витрати.

Варіант 10: Два ZK-Rollups + Децентралізований доведувач з онлайновим легким вузлом на кожен інший (моститься)

Варіант 10 є розширенням Варіанту 5 з метою створення 2 ZK-Rollups, які можуть мости між собою. Порівняно з Варіантом 5 (заснований Rollup+ZKP+децентралізований Prover), Варіант 10 має додаткову роль ретранслятора-ретрансляції, який обгортає Batch Header+ZK-Proof у одну транзакцію. Просто відправляючи цю транзакцію на Rollup1 light node, де працює Rollup2, доводиться, що Batch певної висоти є дійсним. Звичайно, Rollup2 також повинен працювати зі світловим вузлом шару DA.

Це обов'язкова умова для того, щоб довіра до кросчейн-мостів була зведена до мінімуму. Однак, якщо ви переходите з Ether Rollup (SC Rollup на основі смарт-контракту) на Ether, більше немає необхідності запускати легкий вузол DA-рівня Rollup, оскільки DA-рівень є самим Ether. Це дуже відрізняється від Sovereign Rollup від Celestia, де Rollups повинні запускати легкі вузли шарів DA один одного, щоб перетинатися один з одним.

Коли Релейер відправляє міжланцюжкову транзакцію, вона обробляється агрегатором 2 Rollup2 та HP2. Ми додаємо обидва до графа, щоб зрозуміти, як вузли в Rollup2 обробляють міжланцюжкові транзакції.

Повторювач Релеєра Rollup 2 отримає заголовок партії та ZKP Rollup 2 та надішле його назад до Rollup 1. У Rollup 1 також є легкий вузол для Rollup 2 та легкий вузол для шару DA.

Ми можемо спростити модель. Припустимо, що два Rollups використовують один і той же Спільний агрегатор та Виробник заголовків, іншими словами, вони використовують накладені DA-шари.

У цьому випадку Реле може бути визнано законним напряму. Оскільки Заголовок пакета та ДК-доказ були опубліковані HP на тому ж рівні DA, дані, такі як Заголовок та ZKP іншого Rollup, можуть бути прочитані безпосередньо на рівні DA, і вже не потрібно передавати їх Реле через Спільний агрегатор.

Очевидно, Rollups, які використовують той самий DA-шар, не потребують надійних вузлів (багато місткі міжланцюгові мости покладаються на вузли-пересувальники). Це може вирішити проблему безпеки міжланцюжкових мостів (з цієї точки зору, міжланцюжкова взаємодія між SC Rollups в Ethernet є безпечнішою, ніж міжланцюжкова взаємодія між різними громадськими ланцюгами).

На цей момент мінімальна конфігурація для мінімізації довіри: світловий вузол DA-рівня + світловий вузол Rollup.

Заява:

1. Ця стаття перепублікована з [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], авторські права належать оригінальному автору [NashQ, Celestia], якщо у вас є які-небудь зауваження до перепублікації, будь ласка, зв'яжітьсякоманда Gate Learn, команда буде розглянута згідно з відповідним процесом якнайшвидше.
2. Попередження: Погляди та думки, висловлені в цій статті, відображають особисті погляди автора і не є жодною інвестиційною порадою.
3. Статті інших мов перекладаються командою Gate Learn і не можуть бути відтворені, розповсюджені або скопійовані без посилання на Gate.io.