У цьому документі аналізуються ключові технології спільних секвенсорів: високостійкі до цензури, прості в розгортанні, сумісні, швидкі для визначення та миттєві. Теорія агрегації відкриває для неї нову перспективу, а вертикальна інтеграція спрямовує її подальший розвиток.
Оригінальна назва: "The Shared Sequencer"
Автор: MAVEN11
Компіляція: Kxp, BlockBeats
Уявіть собі, що було б, якби Rollup «з коробки» міг досягти високого рівня стійкості до цензури, простоти розгортання, сумісності, швидкого завершення, жвавості та демократизації MEV. Це може здатися великою метою, але з появою спільного секвенсора вона незабаром може стати реальністю. Однак не всі зведені пакети однакові, тому ми повинні розглянути, як розподілити винагороди та MEV у спільній мережі секвенсора. У цій статті ми досліджуємо, як реалізуються спільні мережі рейтингу, і властивості, яких можна досягти.
Shared Sequencer Networks спочатку представив Алекс Беккет, пізніше Еван Форбс (та Радіус) з команд Celestia та Espresso, а також нову статтю Джона Шарбоно, яка детальніше висвітлює цю тему. Джош, Джордан та їх команда Astria будують першу спільну мережу секвенсора, готову до виробництва. Мережа спільних замовників Astria — це модульний блокчейн, який агрегує та впорядковує транзакції Rollup без їх виконання.
У налаштуваннях Astria сортувальник надсилає впорядковані блоки на рівень DA, а також на вузли Rollup. Зведені отримують гарантії м’якої остаточності від замовника та гарантії жорсткої остаточності від рівня DA (після завершення блоків), а потім вони виконають дійсні транзакції.
Спільна мережа секвенсора — це, по суті, група секвенсорів, сумісних із Rollup, і, як випливає з назви, вона може надавати послуги для різних Rollup. Це має різні компроміси та властивості, які ми детально розглянемо пізніше. Спочатку ми повинні описати найважливіші властивості сортувальника (або набору сортувальників). У Rollup основною вимогою до секвенсора або групи секвенсорів є стійкість до цензури або живучість (деякі з яких походять від базового рівня, а також безпека). Це означає, що дійсна транзакція, надіслана замовнику, повинна бути включена в ланцюжок протягом кінцевого часу (параметр тайм-ауту). Спільній групі замовників потрібно лише переконатися, що транзакції включені в блоки (тобто crLists).
Задовольнити опір цензури та миттєвість водночас досить важко, як ми окреслили в Modular MEV Part II. За допомогою консенсусного алгоритму, такого як Tendermint, ви можете забезпечити відновлення після атаки. Однак у разі нападу ви втрачаєте миттєвість. По суті, вимагати від усіх інших колаторів підписувати блок, а не вибирати спеціальну майстерноду, ймовірно, не є оптимальним. Хоча це підвищує стійкість до цензури, це відбувається за рахунок «централізації» та вилучення MEV до однієї головної вузли. Інший доступний механізм сортування можна порівняти з Duality's Multiplicity, який є їхнім маленьким інструментом для не-мастернод (або сортувальників) для включення інших транзакцій у блоки. Загалом, у більшості консенсусних протоколів важко досягти стійкості до цензури та негайності після атаки.
Ще один консенсусний алгоритм, який можна використовувати, це HotStuff 2, який забезпечує негайність у разі атаки.
Це дозволяє уникнути очікування максимальної мережевої затримки (тайм-ауту) у разі цензури або непідписаного для вибору нової головної вузли. Причина, по якій він може бути цікавим алгоритмом консенсусу для децентралізованого набору замовників, полягає в тому, що він вирішує проблему негайності в консенсусі без додавання додаткового етапу. Якщо майстерноді відомий найвищий лок (найбільша кількість учасників, які погоджуються на певний вихід) і може переконати чесні сторони, проблема вирішена. Якщо ні, чесна майстернода після певного моменту може взяти на себе відповідальність за пуш, допомагаючи наступній майстерноді. Наприклад, вузлу Hotstuff не потрібно підтверджувати повідомлення про перемикання перед сповіщенням нового головного, але він може безпосередньо перейти до нового перегляду та сповістити нового головного.
Різниця з Tendermint полягає в тому, що, хоча обидва є двофазними (Hotstuff1 має три, Hotstuff2 має два), Tendermint має лінійний зв’язок, але не реагує, тоді як Hotstuff2 є реактивним. Якщо є ланцюжок чесних майстернод, протокол відповідає позитивно, оскільки всі кроки, крім пропозиції першої майстерноди, залежать від отримання кількості інформації з попереднього кроку. У налаштуванні спільного замовлення це дозволяє протоколу досягти кращої миттєвості без повернення до нижнього рівня, не скасовуючи цю можливість.
Побудова спільних груп сортувальника
Групі замовників дозволено надсилати транзакції на рівень розрахунків (рівень, на якому знаходиться Rollup). Ви можете приєднатися до цієї групи сортування за умови виконання певних вимог і не досягнуто необхідної кількості виробників блоків. Це оптимізує затримку, пропускну здатність тощо. Ці вимоги подібні до тих, які потрібні, щоб стати валідатором блокчейну. Наприклад, ви повинні відповідати певним вимогам до обладнання, а також початковий депозит, особливо якщо ви хочете запропонувати впевненість у фінансових умовах.
Спільна група замовників (або будь-яка децентралізована група замовників) складається з кількох компонентів, які працюють разом, щоб забезпечити правильну обробку транзакцій, зокрема:
Надайте JSON-RPC для кожного зведеного пакета для подання транзакції (для неповних операторів вузла) на вузол як пул пам’яті, а потім побудуйте та сортуйте. У mempool необхідний певний механізм для визначення черги, а також процесу вибору транзакцій, щоб забезпечити ефективну побудову блоків.
Алгоритм побудови блоків/пакетів, відповідальний за обробку транзакцій у черзі та перетворення їх у блоки чи пакети. Цей крок також може включати стиснення для зменшення кінцевого розміру блоку (так зване стиснення даних). Як згадувалося, це має бути окремо від Proposer, по суті PBS. Дані можна стискати різними способами, наприклад:
Немає кодування RLP - однак це може потребувати децентралізованого набору сортувальників, щоб допомогти нормалізувати передачу даних між вузлами, таким чином заощаджуючи простір.
Опустіть nonce (унікальний номер перевірки даних у певному блоці) - його можна перерахувати під час виконання, дивлячись на попередній стан ланцюжка.
Спрощення ціни на газ - установіть газ на основі фіксованого діапазону цін.
Газове спрощення - Окрім ціни на газ, існує також система нумерації газу.
Замінити адресу на індекс. Зведення може зберігати індекс зіставленої адреси замість повної адреси.
Значення, виражені в науковій нотації - поля значень у транзакціях Ethereum позначаються у вей, тому значення великі. Ви не можете опускати числові поля або зводити їх до фіксованого набору значень. Однак ви можете записати це в науковій нотації, щоб оптимізувати зберігання даних:
Відсутність полів даних: поля даних не потрібні для простих переказів, але потрібні для складніших транзакцій.
Замініть окремі підписи зведеними підписами BLS: підписи є найбільшим компонентом транзакцій Ethereum. Замість того, щоб зберігати кожен підпис, ви можете зберігати зведені підписи BLS для певної кількості транзакцій. Ви також можете перевірити сукупний підпис BLS щодо набору повідомлень і набору відправників, щоб переконатися в його дійсності.
Використовуйте поле «Від» як індекс: як і поле «Кому», ви можете використовувати поле «Від» як індекс для зіставлення.
Цікава концепція «модульного» дизайну полягає в тому, що ви можете вносити коригування та компроміси за потреби, щоб змусити його працювати для вашого Rollup.
Одноранговий рівень дозволить замовникам отримувати транзакції від інших замовників і поширювати блоки після створення. Цей крок має вирішальне значення для забезпечення ефективної роботи спільного секвенсора в кількох зведеннях.
Алгоритм головної ротації для спільних наборів упорядників (консенсус не потрібен у разі обрання єдиного головного). Ви можете встановити лише алгоритм ротації головного вузла або скористатися маршрутом створення кількох одночасних блоків, запропонованим Duality.
Алгоритми консенсусу, такі як вищезгаданий Tendermint або Hotstuff2, можуть гарантувати, що вузли Rollup узгоджуються з послідовністю, запропонованою реєстром.
Клієнт RPC для надсилання блоків/пакетів на базовий консенсусний рівень DA+, щоб блоки/пакети можна було безпечно додавати до рівня DA, забезпечуючи «остаточну» завершеність і роблячи всі дані транзакцій доступними в ланцюжку.
Розділіть ролі будівельників і виробників блоків, щоб забезпечити справедливість і послідовність і уникнути крадіжки MEV. Також видаляє виконане сортування, що важливо для оптимізації ефективності, зменшення PGA та збільшення CR.
*Вузли зведення отримують упорядковані блоки від сортувальника для м’якого подання та отримують упорядковані блоки рівня DA для жорсткого подання. *
Calldata спочатку публікується в базовій мережі, де виконується консенсус, щоб гарантувати транзакції користувачів і зведення. Потім вузол Rollup виконує транзакцію та надсилає функцію переходу стану в канонічний ланцюжок Rollup. Мережа спільних замовників надає Rollup миттєвість і стійкість до цензури. Зведені зберігають свій суверенітет, оскільки всі дані транзакцій зберігаються на базовому рівні, що дозволяє їм у будь-який час розгалужуватися від спільного замовника. Корінь стану функції переходу стану зведення (STF) обчислюється з коренів транзакції (вхідних даних), надісланих із спільного замовника на рівень DA. У Celestia корені стану генеруються, коли дані додаються до ланцюжка та досягається консенсус. Оскільки у вас уже є корінь транзакції (і всі доступні дані), Celestia може надати легким клієнтам (вузли зведення, що працюють на Celestia) з невеликим підтвердженням включення.
Щоб забезпечити очікувану користувачами взаємодію з користувачами, вузли зведення отримують упорядковані блоки (які також надсилаються на рівень DA). Це може надати Rollup м’які детерміновані гарантії — гарантії того, що блоки врешті-решт будуть упорядковані в порядку на рівні DA, після чого вузли Rollup виконують транзакції та надають нові корені стану.
Створення блоку та слот
Щоб визначити час створення блоку, секвенсору необхідно встановити слот. Секвенсор повинен надсилати пакети через фіксовані проміжки часу (зазвичай X секунд), де X — час інтервалу. Це гарантує оперативну та ефективну обробку транзакцій, оскільки в іншому випадку майстер-нода для певного слота закінчиться та втратить винагороду за підписання (і винагороду за виконання). Наприклад, час блокування Celestia (згідно зі специфікаціями GitHub) становить близько 15 секунд. Оскільки це відомо, ми можемо зробити деякі припущення щодо того, скільки «слотів/блоків» ми можемо мати від спільного набору координаторів до рівня DA та вузлів зведення завантажуються в завершені блоки. У цьому відношенні ми можемо посилатися на оптимізовані Tendermint або Hotstuff2.
У межах одного слота ми можемо надсилати кілька пакетів транзакцій за умови, що дизайн включає механізми для повних вузлів Rollup для ефективної обробки їх в один блок (протягом цього періоду часу та параметрів тайм-ауту). Це допомагає додатково оптимізувати створення блоків і забезпечує швидку обробку транзакцій. Крім того, слоти також можна використовувати для полегшення вибору головних вузлів сортувальника. Наприклад, ви можете випадковим чином вибрати головний вузол слота з пулу ставки на основі ваги ставки. Зробити це таким чином, щоб зберегти конфіденційність і застосувати щось на кшталт таємних виборів лідера, щоб мінімізувати цензуру, є найкращим варіантом; або навіть налаштування технології розподіленої перевірки, як-от рішення на зразок Obol/SSV. Затримка та час слота мають великий вплив на надсилання блоків і збірки протоколу. Тому нам потрібно подивитися, як це впливає на систему. Bloxroute має кілька чудових досліджень і даних, зокрема щодо Ethereum. У MEV-Boost виробники блоків, що беруть участь (валідатори або секвенсори у випадку Rollup), запитують GetHeader у ретранслятора. Це дає їм значення ставки блоку, яке є вартістю конкретного блоку. Це може бути блок найвищої вартості, отриманий щоразу. Для кожного слота валідатори зазвичай запитують GetHeader приблизно через 400 мс після початку слоту - через велику кількість валідаторів ретрансляторам часто потрібно надсилати численні запити. Це також може статися з великими спільними групами сортувальників. Це означає, що вам потрібна інфраструктура для полегшення цього процесу.
Ретранслятори також допомагають розділити будівельників і виробників блоків, одночасно перевіряючи, що будівельники створили правильні блоки. Вони також перевіряють правильність сплати комісій і діють як захист від DoS. Крім того, вони в основному є зберігачами блоків і займаються реєстрацією валідаторів. Це особливо важливо в архітектурі необмеженого секвенсора, оскільки вам потрібно відстежувати, хто брав участь, а хто ні (наприклад, рівень синхронізації, про який йшлося раніше).
Що стосується часу блокування (тобто блокування, надісланого творцями), то воно зазвичай становить приблизно 200 мілісекунд. Здебільшого вони починають працювати до/після приблизно 200 мс, хоча, як і GetHeader, є значні варіації. Якщо розробник надсилає блок до кількох ретрансляторів, це спричинить значну затримку. Bloxroute також розглянув, що відбувається, коли блоки надсилаються на кілька ретрансляторів. Як і можна було очікувати, затримка для розповсюдження блоку на більше реле буде більшою. У середньому другому ретранслятору знадобилося 99 мілісекунд, щоб витратити блок, третьому — 122 мілісекунди, а четвертому — 342 мілісекунди.
За останні кілька місяців ми, напевно, дізналися, що RPC дуже важливий для блокчейнів. Це величезний тягар без належної інфраструктури, і наявність відповідної опції RPC також є критично важливою. У цьому випадку RPC важливий для роздрібних інвесторів, які надсилають свої транзакції в RPC (і публічний mempool). Bloxroute провів невеликий тест із 20 транзакцій, надісланих до різних RPC, і виміряв час, потрібний для включення кожної транзакції в блок.
Джерело: Bloxroute Labs
Цікаво, що деякі RPC не включають транзакції до кількох блоків пізніше, залежно від того, який конструктор переможе в наступному блоці. Якщо RPC надсилає транзакцію більшій кількості розробників, то ймовірність швидкого включення вища. Хоча ініціатори транзакцій можуть використовувати свою унікальну позицію для потоку замовлень для націлювання на конкретних розробників або навіть для створення власних блоків.
Їх продуктивність також цікава в статистиці продуктивності ретрансляції Ethereum. Це допомагає нам отримати глибше розуміння того, як працює PBS у світі кількох валідаторів/будівників/ретрансляторів, чого ми сподіваємося досягти завдяки зведеному оновленню. Metrika має чудову статистику з цього приводу, і всі точки даних належать їм.
Важливо зауважити, що пропущені ставки виникають, коли очікується, що ретранслятор зробить ставку, але не робить ставку. Цільові очікування надходять від валідаторів, зареєстрованих у певному реле для будь-якого слота. Це не помилка реле як така, і вона не обробляється таким чином на рівні протоколу.
Джерело: app.metrika.co
Якщо виникає збій (наприклад, реле, що обслуговує недійсний блок), і воно є відповідальним, це буде зараховано як збій. Зазвичай це трапляється рідко і здебільшого пов’язано з помилками в налаштуваннях реєстрації (тобто ліміти на газ або комісії, які не відповідають реєстрації для певного валідатора). Ще рідше трапляються збої рівня консенсусу, які не відповідають правилам рівня консенсусу Ethereum, наприклад неправильні слоти або батьківські хеші, не узгоджені з попереднім блоком тощо.
З точки зору затримки (наприклад, часу, необхідного валідатору для отримання заголовка блоку, створеного конструктором), дані дуже послідовні. Хоча є деякі викиди, наприклад, географічне розташування запитаного ретранслятора відрізняється від обраного валідатора.
Джерело: app.metrika.co
Що стосується будівельників, то загальна кількість будівельників на MEV-boost становить приблизно 84, причому три найкращі будівельники будують близько 65% побудованих блоків. Хоча це може ввести в оману, оскільки це також найдавніші будівельники. Результати будуть аналогічними, якщо скоротити часові рамки. Кількість фактично активних будівельників значно менша: 35 за останні 30 днів і 24 за останній тиждень. Конкуренція жорстка, і зазвичай перемагає найсильніший будівельник. Ексклюзивний потік замовлень може вже існувати, що лише погіршить ситуацію. Ми очікуємо, що розподіл розробників залишатиметься відносно централізованим (оскільки це змагання за оптимальний потік замовлень і оптимізацію апаратного забезпечення), якщо ми не внесемо серйозних змін у налаштування. Хоча це не фундаментальна проблема, це все ж централізуюча сила в стеку, і ми хотіли б почути ідеї щодо того, як кинути виклик статус-кво тут. Якщо ви зацікавлені в глибшому дослідженні цієї (серйозної) проблеми, ми настійно рекомендуємо прочитати статті Quintus про потік замовлень, аукціони та централізацію.
Що стосується ролі Builder у майбутньому стеку модульності, ми майже впевнені (принаймні в налаштуваннях Cosmos SDK) ми побачимо налаштування Builder Modules, схоже на Skip/Mekatek. Іншим рішенням є налаштування типу SUAVE, наприклад спеціальна глобальна мережа розробників, що надає послуги блокової побудови та налаштування ставок будь-якій кількості мереж для забезпечення PBS. Пізніше ми детальніше розглянемо це рішення та дамо деякі відповіді на запитання, які тут не розглянуті.
Щодо реле, ми настійно рекомендуємо прочитати статтю Анкіта Чіплункара з Frontier Research і Майка Нойдера з Ethereum Foundation під назвою «Оптимістичні реле і де їх знайти». У цій публікації детально описано, як працюють реле в MEV-boost, їхні поточні компроміси та експлуатаційні витрати, а також деякі зміни, які можуть підвищити ефективність. Цікаво, що за підрахунками Flashbot, запуск реле в MEV-Boost наразі коштує близько 100 000 доларів США на рік.
Детермінований
Перш ніж ми поговоримо про детермінізм модульних блокчейнів (як вони зараз виглядають), давайте поглянемо на нашу попередню статтю «Модульний MEV». Зауважте, що це не «офіційний» і не вичерпний погляд на остаточність, але ми вважаємо, що він найточніше представляє нюанси остаточності зведення для полегшення розуміння.
Pending_On_L2: Замовник зведення представляє м’яке зобов’язання щодо того, що транзакцію користувача врешті-решт буде прийнято та завершено на базовому рівні безпеки.
Finality_On_L2: секвенсор прийняв функцію переходу стану зведення, і блок додано до канонічного ланцюга зведення.
Очікує_On_L1: функція переходу введення або виведення/стану транзакції була опублікована в L1, але підтвердження дійсності ще не видано, або період арбітражу ще не закінчився - для цього потрібен Ethereum протягом двох послідовних епох. Це момент, на якому більшість Optimistic Rollups кажуть, що вони досягли завершеності, але на цьому етапі все ще існує довільний 7-денний період перевірки відповідно до специфікації перехресного мосту.
Finality_On_L1: для Optimistic Rollup арбітражний період закінчився, або опублікований і перевірений доказ дійсності підтверджено супербільшістю протягом двох послідовних епох.
Тепер, у Sovereign Shared Sort Rollup, це виглядає дещо інакше, давайте спробуємо пояснити це за допомогою діаграми:
У цьому випадку теоретично ми можемо отримати детермінізм на L1 перед L2 тощо? Так, у цьому випадку L2 є суверенним. Це припускається, що немає доказів шахрайства та періодів оскарження, або ви використовуєте підтвердження дійсності.
Отже, як ми досягаємо цих рівнів остаточності? Завершеність блоку досягається, коли до канонічного ланцюга додається блок, який неможливо вилучити. Однак тут є свої нюанси в залежності від повних або світлих вузлів. У випадку впорядкованого блоку він є детермінованим, коли його включено до блоку рівня DA. Блоки (з коренями стану) підтримуються повними вузлами/валідаторами Rollup, що дає їм гарантію дійсного кореня стану, отриманого з упорядкованих блоків базового рівня. Для детермінізму за межами повних вузлів (наприклад, для легких клієнтів або крос-ланцюгових мостів) ви повинні бути впевнені в дійсності цього кореня стану. Тут ви можете скористатися одним із методів, описаних нижче. Крім того, інший підхід полягає в тому, щоб валідатори відповідали за правильний доказ кореня стану (оптимістичний шлях) через зобов’язання та подальший доказ шахрайства. Додатково можна надати підтвердження дійсності (ЗК).
Різні способи досягнення остаточності блоку:
Через підтвердження роботи (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) та інші імовірнісні методи.
Доказовий метод за допомогою достатньої кількості членів комітету, які підписують блоки. (наприклад, Tendermint 2/3, Hotshot2 або інші типи PBFT)
Залежить від упорядкування транзакцій/блоків на рівні DA та його правил, а саме правил вибору канонічного ланцюга та розгалуження.
Ми можемо досягти різних типів остаточності за допомогою різних механізмів.
Одним із типів остаточності є «м’яка остаточність» (наприклад, незавершена), яка може бути досягнута шляхом обрання одного лідера. У цьому випадку кожен слот матиме лише один або нуль блоків (зафіксованих чи ні), і рівень синхронізації може безпечно вважати послідовність транзакцій у цих блоках.
Іншим типом остаточності є «доказова остаточність», яка надає сильніші гарантії (по суті остаточна), ніж м’яка остаточність. Щоб досягти доведеної остаточності, більшість замовників повинні підписати блок, висловлюючи таким чином свою згоду з тим, що блок є канонічним. Хоча цей підхід хороший, він може бути непотрібним, якщо було реалізовано єдиний вибір лідера, оскільки він, по суті, гарантує впорядкування блоків. Очевидно, це залежить від конкретного реалізованого алгоритму виборів лідера. Наприклад, це 51% виконання, 66% впровадження чи єдиний лідер (бажано випадкові (VRF) і таємні вибори). Якщо ви хочете дізнатися більше про детермінізм в Ethereum, прочитайте цю статтю, яку ми настійно рекомендуємо, і статтю, яку ми порекомендуємо пізніше для необмежених наборів сортувальників.
ліцензований, напівліцензований або без дозволу
Щоб запобігти потенційним DoS-атакам, необхідно встановити економічні бар’єри, щоб приєднатися до групи замовників і відправити транзакції на рівень замовників. В обмежених (кінцева кількість сортувальників) і необмежених (необмежена кількість сортувальників) групах необхідно встановити економічні бар’єри для надсилання пакетів на рівень DA, щоб запобігти уповільненню або DDoS-атаці рівня синхронізації (розповсюдження блоків між сортувальниками). . Однак сам рівень DA також забезпечує певний захист, оскільки надсилання даних на нього вимагає певних витрат (da_fee). Гарантійний депозит, необхідний для приєднання до необмеженої групи, має покривати будь-які додаткові витрати, необхідні для запобігання спаму на рівні синхронізації. З іншого боку, маржа, необхідна для приєднання до обмеженої групи, залежатиме від попиту (збалансованого з точки зору витрат/доходу).
Для необмеженого набору сортувальників ми не можемо досягти доведеної остаточності на рівні сортувальника (оскільки ми ніколи не знаємо точно, скільки є активних голосуючих/підписувачів). З іншого боку, в обмеженій групі коортерів доведена остаточність може бути досягнута більшістю коортерів, які підписують блоки. Для цього потрібно, щоб рівень синхронізації був у курсі рівня секвенсора та кількості секвенсорів, які активні в будь-який момент часу, що створює додаткові витрати. У обмеженому наборі сортувальників (наприклад, до 100) ви також можете оптимізувати кількість сортувальників, щоб покращити «продуктивність», але за рахунок децентралізації та стійкості до цензури. Важливість обмежених груп та економічних гарантій для забезпечення "швидкої" доказової визначеності також є детерміністською.
Типи необмеженого сортувальника та обмеженого сортувальника також відображаються в традиційних блокчейнах. Наприклад, PoS (Casper+LMD-GHOST) в Ethereum використовує необмежений тип, тоді як ланцюжок на основі Cosmos SDK/Tendermint приймає обмежений тип. Цікава думка: чи очікуємо ми побачити економіку, подібну до доказу частки, і варіанти від спільноти навколо спільних замовників? У зв’язку з цим ми спостерігаємо рух у бік централізації деяких організацій (тому необмеженість не має особливого значення, якщо у вас уже є кілька великих постачальників/пулів доказів участі). Незважаючи на те, що вони «приховують» централізацію, зрештою, ви все одно можете майніти, якщо хочете. З ідеологічної точки зору вибір майже завжди має бути необмеженим, але пам’ятайте, що економічні принципи все одно роблять їх дуже схожими. Незалежно від того, ким є учасники, економіка того, що ви платите, має бути однаковою, наприклад, вартість DA та вартість апаратного забезпечення (хоча це може бути зменшено кількістю підтверджень частки, які ви розподіляєте, і досвіду, а також ефективність функціонування інфраструктури). Навіть у обмеженому світі PoS ми бачили, як група постачальників інфраструктури стала найбільшим і найпоширенішим валідатором майже в усіх мережах. У більшості ланцюжків Cosmos залежності між валідаторами вже дуже великі, і це, безумовно, становить небезпеку для децентралізації та стійкості цих ланцюгів до цензури. Проте зовсім інший факт полягає в тому, що будь-який роздрібний інвестор може зробити ставку на будь-яку суму за допомогою будь-якого валідатора, який він вибере. На жаль, це зазвичай призначається у верхній частині списку, і життя продовжується. Ми знову запитуємо: чи очікуємо ми подібної економічної моделі в модульному світі? Хочеться, щоб це було не так, але зі спеціалізацією вам часто потрібен найкращий варіант – і вони, як правило, є професійними постачальниками доказів частки. Ми також розглянемо ці економічні питання в окремому розділі пізніше.
Однак одна важлива річ, про яку слід пам’ятати в усіх цих питаннях, полягає в тому, що найважливішою є автентифікація кінцевого користувача, яка доступна будь-кому, незалежно від того, де вони знаходяться (навіть у Гізі) через легкі клієнти та піраміду DAS).
Джерело: @JosephALChami
Ось компроміси та переваги обмежених і необмежених сортувальників:
Необмежений набір сортувальників:
*Будь-хто з достатньою кількістю облігацій/стейкінгу може стати сортувальником = високий ступінь децентралізації
Неможливо мати єдиний вибір лідера, оскільки сортувальник по суті нескінченний.
Неодноосібний вибір лідера через VRF можливий, але важко визначити параметри VRF, оскільки невідомо, скільки буде замовників. Це також мають бути таємні вибори лідера, якщо це можливо, щоб уникнути атак DoS.
Відсутність виборів лідера = марна витрата ресурсів. Проблема: будівництво блоків — це, по суті, безкоштовне змагання, виграє той, хто подає перший дійсний блок/партію, а всі інші програють. · · · Немає доведеної впевненості на рівні замовника, лише ймовірнісні: наприклад, LMD Ghost+Casper
Завершеність досягається лише після запису пакетів на рівень DA (обмежується лише базовим часом блоку, 15 секунд у випадку Celestia).
Необмежені набори «краще» стійкі до цензури, ніж обмежені набори.
Обмежений набір сортувальників:
Це одне з рішень Ethereum для детермінізму одного слота та наявності комітету супер-більшості.
Існує обмеження на кількість секвенсорів, дозволених у будь-який момент часу.
Обмежені множини складніші за необмежені.
Єдині вибори лідера можуть бути реалізовані, забезпечуючи сильну детерміновану гарантію для рівня сортувальника.
Рівень синхронізації повинен розуміти набір упорядників, щоб визначити, які блоки дійсні.
Запис наборів сортувальників (або змін наборів) до блоків шару розрахунків (таких як правила вибору розгалуження), які записуються на рівень DA, дозволяє рівню синхронізації самостійно визначати набір сортувальників. Наприклад, це те, що робить зведений пакет Sovereign Labs: зміни колекції записуються в доказ дійсності, опублікований на рівні DA.
Сильні гарантії завершеності рівня замовника можуть не знадобитися, якщо рівень DA достатньо швидкий (проте більшість поточних неоптимізованих налаштувань рівня розрахунків мають принаймні 10+ секунд часу блокування).
Існує значний простір для того, як відстежувати ці набори сортувальників і додавати або видаляти нових учасників. Наприклад, чи буде це досягнуто за допомогою управління Tokenholder (як щодо багатьох різних токенів і зведених пакетів, що використовують колекції?). Це означає, що сигналізація про зміни поза мережею може бути можливою через соціальний консенсус (наприклад, візьмемо Ethereum як приклад). Однак пам’ятайте, що фактичний консенсус у ланцюзі чітко встановлений, і штрафи за порушення правил консенсусу вже існують.
Економічний механізм для спільних сортувальників
Економіка спільного використання мережі секвенсорів передбачає кілька цікавих варіантів. Як ми обговорювали раніше, валідатори в спільній мережі замовників не дуже відрізняються від типових валідаторів L1. Мережа, в якій він бере участь, просто більш оптимізована для виконання одного завдання, яке полягає в отриманні намірів (раніше PBS), а отже, пропонуванні та замовлення транзакцій. Як і у «звичайних» валідаторів, є компоненти доходів і витрат. З обох сторін рівняння існує велика гнучкість у мережах, у яких беруть участь валідатори, подібно до звичайного L1.
Дохід надходить від користувачів або Rollups, з якими вони зрештою хочуть взаємодіяти, сплачуючи певну плату за використання спільного секвенсора. Ця комісія може бути відсотком від вилученого MEV (введені цифри може бути важко підрахувати), міжланцюговим переказом вартості, газом або фіксованою комісією за взаємодію. Найбільш відповідним рішенням для отримання прибутку може бути сплата спільному замовнику меншої вартості, ніж додаткова вартість, отримана через спільного замовника Rollup, разом із перевагами спільної безпеки та ліквідності. Але недоліком цього є те, що важко кількісно оцінити переваги децентралізації іншої частини стека. Однак, оскільки спільна мережа замовників розростається у власну екосистему, її здатність отримувати комісію може збільшуватися. Це значною мірою пояснюється їх властивою здатністю легко агрегувати з певною економією на масштабі. У міру того, як до мережі приєднується більше зведених пакетів і додатків, все більше і більше міждомених MEV зможуть видобувати.
З точки зору вартості, спільні мережі замовлення також мають конкуруючі варіанти. Вони можуть легко фінансувати використання своєї мережі, фінансуючи витрати на публікацію на рівні DA або навіть вартість взаємодії з програмами на Rollup. Це схоже на стратегію, яку використовують компанії Web 2.0, де ви берете на себе початкові втрати від залучення користувачів (або згортання), сподіваючись, що їхній довгостроковий дохід перевищить комісію. Інший більш новий або Crypto-native метод полягає в тому, щоб дозволити Rollup сплачувати комісії DA за допомогою рідного токена. Тут спільний рівень сортувальника несе ризик ціноутворення між маркером, необхідним для публікації даних на рівні DA, і рідним маркером Rollup. По суті, це все ще спільний сортувальник початкових витрат, але він створює узгодженість екосистеми шляхом отримання маркера «постачальника» (тобто Rollup). Це дещо схоже на будівництво складу, яке ми пояснювали в документі AppChain, і різні форми DA можна використовувати для зниження витрат. Різні рівні DA пропонуватимуть різні ціни через використання, можливість користувачів легко перевіряти через легкий клієнт або просто вибирати інший розмір блоку. Нарешті, спільний замовник також може групувати транзакції перед публікацією на рівні DA. У випадку ZKR це може зменшити транзакційні витрати через певну кількість балансів транзакцій, а з точки зору ORU ви можете виконувати різні оптимізації газу пакетної обробки, які ми зараз можемо бачити в різних зведених пакетах. Це зменшить кількість даних, які необхідно опублікувати на рівні DA, таким чином зменшуючи вартість спільної мережі секвенсора та підвищуючи прибутковість усієї мережі. Це відбуватиметься за рахунок обмеження сумісності та зміни часу завершення блоку (детермінізм на L1, як згадувалося раніше).
Загалом, економіка спільного використання мережі секвенсорів дозволяє проводити деякі цікаві експерименти та стратегії початкового завантаження. Ми вважаємо, що ключовою відмінністю буде розмір екосистеми, тому кількість міждомених MEV є більшою, ніж аспект вартості. Ми також настійно рекомендуємо ознайомитися з дописом у блозі команди Espresso про спільних замовників, вони також розповідають про економічні компроміси (і позитивні сторони) цих типів мереж. Щоб показати, чому Rollup мотивований скористатися перевагами спільних сортувальників (крім економіки), ми можемо розглянути це з точки зору теорії агрегації.
Теорія агрегації та спільні сортувальники
Інший спосіб описати властивості, створені спільними сортувальниками, — через призму теорії агрегації. Теорія агрегації стосується концепції того, як платформа або агрегатор систематично інтегрує інші платформи та їхніх користувачів, щоб привернути значну увагу користувачів. По суті, ви переміщуєте гру від розподілу дефіцитного ресурсу (наприклад, блокового простору) до необхідності контролювати надлишок ресурсу (знову ж таки, блоковий простір має сенс у цьому прикладі). Теорія агрегації фактично об’єднує постачальників і продукти (тобто Rollup і Blockspace) у суперкористувацький досвід для обслуговування агрегованої бази користувачів. У міру того, як мережевий ефект цих агрегаторів зростає, цей зв’язок стає все більш ексклюзивним. Коли це відбувається, користувацький досвід стає ключовою відмінністю між подібними налаштуваннями. Якщо є стимули для залучення нових користувачів (наприклад, хороша взаємодія з користувачами та краща сумісність), малоймовірно, що Rollup переміститься у власну мережу чи інше налаштування, оскільки мережеві ефекти стимулюють нових постачальників і нових користувачів. Це створює ефект маховика не лише з точки зору постачальника та користувача, але й з точки зору сукупної стійкості до цензури.
Джерело: Теорія агрегації 2015, Бен Томпсон
У царині спільних сортувальників теорію агрегації можна розглядати як «комбінації» та об’єднання різних зведених пакетів, усі з яких використовують однакові вертикалі стека, надаючи можливості собі та іншим, одночасно дозволяючи користувачам отримати той самий досвід.
Постачальники (такі як Rollups) теоретично не є винятковими для спільного набору коортерів, але на практиці спільний набір coorter, його зведення та користувачі отримують вигоду від серії циклів мережевих ефектів, які призводять до збільшення використання цих зведень. Ці переваги спрощують інтеграцію Rollups і користувачів у спільний стек, оскільки вони можуть більше втратити, якщо не беруть участі. Хоча ці переваги може бути важко помітити, коли у вас є лише два зведені пакети, які спільно використовують один набір секвенсорів, вони стають більш очевидними, коли ви додаєте все більше і більше зведених пакетів і користувачів до рівняння. Спільні набори сортувальників мають пряме відношення до користувачів, оскільки вони впорядковують свої транзакції, навіть якщо самі користувачі не знають, що вони з ними взаємодіють, оскільки, з їх точки зору, вони просто використовують зведені пакети, з якими у них є причина взаємодіяти ( Це означає, що замовлення/сортувальники стають ексклюзивними). Єдиною ціною цих сортувальників є вартість апаратного забезпечення для їх запуску, якщо простір блоку та токени, які його захищають, є цінними для кінцевого користувача. Комісії за транзакції оцифровані, сплачуються з гаманців користувачів і, можливо, у майбутньому можуть бути навіть абстраговані за допомогою таких вдосконалень, як хости платежів у абстракції облікового запису (однак комусь доведеться нести витрати на DA, замовлення та виконання).
Це має більше сенсу, якщо взяти до уваги попередню компанію Джоша та Джордана в Астрії – Google. З моменту свого створення продукти Google надихалися ідеєю AT, зокрема в Пошуку Google, який створюється шляхом модульування окремих сторінок і статей, що робить їх прямим доступом через вікно глобального пошуку.
У випадку спільного набору сортувальників користувачі, які використовують Rollup (ті, хто спільно використовує набір сортувальників), мають усе нижчі витрати на придбання, оскільки зі збільшенням кількості постачальників (Rollup) їх, швидше за все, приверне набір . Це означає, що в більшості випадків агрегатор (або мультиагрегатор) має можливий взаємовигідний ефект, оскільки цінність агрегатора зростає зі збільшенням кількості постачальників (звичайно, за умови, що досвід користувача хороший). Навпаки, в одній послідовній мережі залучення клієнтів обмежується однією мережею та її програмами. Якщо користувачі хочуть використовувати програму Rollup на іншому Rollup, їм доведеться (у межах поточних обмежень) повністю вийти з мережі. Це означає, що прихильність користувачів і цінність не дуже високі, а також це означає, що в будь-який момент, якщо інша екосистема Rollup високо цінується (або має більше стимулів), капітал може бути втрачений.
Резюме атрибутів і компромісів
Атрибути
Спільний набір сортувальників — це зведена мережа, яка об’єднує та сортує транзакції для кількох зведених даних. Ці зведені пакети використовують той самий сортувальник. Таке об’єднання ресурсів означає, що зведені пакети отримають сильнішу економічну безпеку та можливості боротьби з цензурою, що може забезпечити швидкі м’які детерміновані гарантії та умовні крос-зведені транзакції.
Прямо зараз є багато шуму щодо атомарності серед Rollups, які використовують той самий набір сортувальників, здебільшого навколо того, чи є він атомарним за замовчуванням, а це не так. Проте, якщо розглянуті зведені реалізують функції переходу стану (STF) одна одної як залежності між ними, включаючи умовні транзакції, тоді вони справді можуть досягти атомарності між ними - за умови, що їх вирівнювання слотів/блоків (як із спільними наборами сортувальника). У цьому випадку, щоб отримати атомарну сумісність, вам справді потрібно лише запустити легкий клієнт ланцюжка B на ланцюжку A і навпаки (подібно до того, як працює IBC). Для подальшого посилення сумісності заходів безпеки (крім довіри до єдиного повного вузла як легкого вузла), ви можете запровадити ZKP (Proof of State), щоб вирішити «проблему оракула» щодо забезпечення правильності стану. Це дасть змогу чіткіше побачити, чи умовна транзакція чи щось подібне натрапило на канонічний перехресний міст між ними. Докази шахрайства також є можливістю, але, очевидно, залишить період оскарження (це означає, що третя сторона прийде, щоб покрити вартість цього ризику). Крім того, у випадку легких клієнтів (а не повних вузлів) він буде відставати принаймні на один блок через очікування заголовка підпису + вікна захисту від шахрайства (якщо таке є).
Ми вважаємо, що проблему «перехресного мосту», швидше за все, можна вирішити за допомогою легких клієнтів і доказів з нульовим знанням. Проблема з використанням полегшеного клієнта (а не смарт-контракту) у цьому випадку полягає в тому, що хардфорки (оновлення тощо) на стороні вузла Rollup повинні координуватись один з одним, щоб підтримувати роботу свого мосту (подібно до того, як IBC потребує ввімкнення той самий модуль стану ). Якщо ви хочете глибше зануритися в цю конкретну тему (і як її вирішити), ми настійно рекомендуємо переглянути цю презентацію.
Причина, по якій спільні замовники настільки добре масштабуються, полягає в тому, що вони не виконують і не зберігають жодного стану (як це роблять сьогодні централізовані замовники). Те саме стосується самих вузлів зведення (якщо вони не хочуть мати атомарність між собою, наприклад, легкий клієнт/підтвердження стану). Ці вузли виконують лише ті транзакції, які дійсні для їхнього зведення, і будь-які умовні міждоменні транзакції, які є дійсними для них. Якщо вузол зведення має виконувати та зберігати стан для кількох зведень, це перешкоджає масштабованості та знижує децентралізацію (і, отже, опір цензурі). Це також підсилює концепцію поділу виробника на блоки (PBS). Хоча нам ще потрібно повністю розділити будівельників і блок-виробників. У поточному налаштуванні замовники по суті є конструктором і виробником блоків (хоча вони не виконують транзакції). Ідеальним налаштуванням може бути таке, коли замовник існує лише для того, щоб сліпо підписувати блоки з високооптимізованого налаштування конструктора та гарантувати, що блоки реалізовано правильно (одночасно забезпечуючи високий ступінь економічної визначеності та стійкість до цензури щодо цієї сертифікації). Таким чином вони можуть забезпечити високий рівень безпеки та зобов’язань, щоб гарантувати м’яку завершеність для вузлів зведення.
Для перехресних умовних транзакцій вони також існують, щоб допомогти вузлам зведення (виконавцям) надавати корені проміжного стану, забезпечуючи атомарність між зведеннями.
компроміс
Вищезгаданий параметр тайм-ауту має деякі цікаві ефекти на MEV і включення транзакцій, залежно від механізму головної вузли/консенсусу набору замовника. Наприклад, якщо параметр тайм-ауту описується як відносно короткий у нашій ланцюжковій статті для конкретної програми, важливо, щоб виробники блоків децентралізованого набору замовників публікували дані якомога швидше. У такому світі ви можете спостерігати конкуренцію між «валідаторами», які змагаються за те, щоб стати головними вузлами, і роблять ставки на рівні DA за простір блоків, доки це не стане прибутковим.
Як писав Еван у своїй оригінальній публікації про ледачого замовника на форумах Celestia, очікування публікації транзакцій на базовому рівні (у цьому випадку Celestia) перед їх виконанням є дуже неефективним. Оскільки тепер ви обмежені часом блокування базового рівня, який занадто довгий, щоб чекати на досвід користувача. Для кращої взаємодії з користувачем спільний замовник надає зведеним пакетам м’які детерміновані зобов’язання (як описано раніше), які надають користувачам досвід, до якого вони звикли в існуючих централізованих зведених пакетах (зберігаючи при цьому децентралізацію та високу стійкість до цензури). М’які зобов’язання – це, по суті, лише зобов’язання щодо остаточного порядку транзакцій, але підкріплені серйозними економічними гарантіями та швидким завершенням після випуску. Це також покривається доказами шахрайства (як зазначено у вступі). Фактична жорстка остаточність досягається після публікації всіх даних транзакцій на базовому рівні (це означає, що L1 фактично досягає швидшої остаточності). Це залежить від того, використовує Rollup докази шахрайства чи докази нульового знання для перевірки доказів суверенітету, що відбувається на Rollup. Причина бажання цього розділення полягає в тому, щоб усунути величезне вузьке місце переходів станів від сортувальника. Натомість вузли зведення мають справу лише з дійсними для них вузлами (це означає, що ми повинні додати умовні транзакції, підтвердження стану або легку перевірку вузла для належної сумісності). Жорсткий детермінізм усе ще залежить від базового рівня (але це може досягати 15 секунд на Celestia, а також є детермінованим у Tendermint), що дає нам відносно швидкі гарантії жорсткого детермінізму на Rollup.
Використовуйте докази з нульовим знанням у мережі, щоб оптимізувати перевірку, розмір транзакції (наприклад, публікувати лише відмінності в стані, але це додає вищий рівень довіри, доки не буде опубліковано ZKP). Як згадувалося раніше, ці підтвердження стану можна використовувати, щоб дозволити підключеним ланцюжкам/зведеним системам мати легшу та швидшу взаємодію (не чекаючи вікон викликів).
Недоліком цих умовних транзакцій є те, що вони, ймовірно, будуть дорожчими, вимагаючи вищих витрат на перевірку та видачу (наприклад, вартість перевірки заголовка блоку Tendermint, яка субсидується в ланцюжку Cosmos), і додадуть деяку затримку системі ( але все одно швидше, ніж ізольовані зведення набагато швидше). Атомарність, досягнута вертикально спільною інтеграцією, може компенсувати ці проблеми.
Під час початкової фази нового зведення використання спільного набору сортувальників має великий сенс, і переваги, які ви отримуєте як постачальник, швидше за все, переважать деякі компроміси, які ви можете «змушені» піти на рівні рову. Однак для вже зрілого Роллапа, де багато транзакцій і економічної діяльності, мабуть, немає сенсу відмовлятися від частини рову.
Це викликає питання, чи потрібен нам подібний економічний/транзакційний (на зведення) зважений перерозподіл вилученого MEV, щоб змусити вже зрілі зведені приєднатися до спільного набору – чи навіть утримати надзвичайно зрілі зведені від створення власної мережі. Все це досить теоретично, але це, безперечно, цікавий процес мислення щодо того, як MEV у спільних вертикальних світах будуть представлені між багатьма зведеними пакетами з різними рівнями активності. Наприклад, якщо унікальний зведений пакет, який створює цінність, ділиться частиною цих прибутків з іншими (ймовірно, не приносячи великої «вартості») через набір секвенсорів, тоді у них повинні бути додаткові причини переходити до власної окремої системи. У Sreeram від EigenLayr є також деякі думки щодо цього, які ми також рекомендуємо прочитати.
Це стає дедалі важливішим, якщо врахувати, що розробка нових ланцюгів потребує значних технічних витрат для шукачів, тому стандартизація та надання певного суверенітету над «своїми» MEV може бути хорошим місцем для початку. На практиці в MEV домінуючий інтерфейс (або програмне забезпечення) може перемогти, але насправді монетизувати це програмне забезпечення за допомогою критичних частин інфраструктури дуже складно (що призводить до централізації). На ринковому рівні те, що надає спільний замовник, — це в основному загальний фонд для кількох постачальників із централізованим аукціоном, що може призвести до здоровішої конкуренції.
Проблема полягає в тому, що якщо два зведених пакети використовують сортувальники в спільному наборі, тоді можна вибрати зведений пакет із «менш економічною» цінністю (A), щоб запропонувати зведений пакет із високою сумою MEV + комісії зі зведеного пакету (B). . З точки зору Rollup B, вони фактично втрачають певну цінність, яку за ізольованого підходу вони залишили б собі.
Розгляд компромісів взаємодії
Ще одна примітка про компроміси, пов’язані з сумісністю, і інший спосіб вирішення деяких проблем:
Метою спільної мережі замовників є надання канонічної гарантії для кількох ланцюжків, що, очевидно, є великою перевагою в цьому випадку. Це можна поєднати з механізмом, який гарантує ефективні переходи між зведеними пакетами. Це може бути підхід на основі комітету (наприклад, PoS), надійні докази (оптимістичний підхід) або наш кращий підхід – ZKP, підтверджений підписами комітету. Оскільки спільні сортувальники є «лінивими», вони створюють лише суперблоки для сортування транзакцій кількох зведених пакетів, а виконання конкретної транзакції залишається за певним зведеним пакетом. Докази стану (наприклад, Лагранжа, Аксіоми чи Геродота тощо) є всіма можливими рішеннями для потенційного отримання доказів остаточності через суверенні зведення. Ви навіть можете додати докази економічно гарантованої остаточності через такі речі, як пули ставок, EigenLayr тощо. Основна ідея полягає в тому, що загальний сортувальник забезпечує економічну гарантію впорядкування, а докази дійсності, створені в результаті цього сортування, є детермінованими. Основна ідея полягає в тому, що Rollups можуть виконувати транзакції синхронно один з одним. Наприклад, мережа з двох вузлів зведення може умовно знати, що обидві історії зведення дійсні через ZKP і доступні дані (дані, опубліковані на ефективному рівні DA). Публікуючи єдиний префікс блоку зведення з обох мереж A і B, вузол зведення може встановлювати два зведення одночасно. Одне, що слід зазначити, це те, що умовні транзакції перехресного зведення споживають ресурси з двох окремих систем через спільне виконання, тому атомарні (або синхронні) транзакції перехресного зведення, ймовірно, будуть дорожчими, ніж внутрішні транзакції з одним зведенням.
Succinct також охопив крос-ланцюгові «атомарні» транзакції між зведеними пакетами зі спільними замовниками (і спільними засобами перевірки шахрайства) в екосистемі гіперланцюга Optimism, які можна переглянути тут. Крім того, як каже Бо Ду з Polymer: «Міжланцюгові атомарні транзакції схожі на отримання блокувань між шардами бази даних під час запису».
Майбутнє вертикальної інтеграції
Можливу внутрішню роботу ланцюгів SUAVE вже детально досліджували Джон Шарбоно та інші, тому ми не будемо вдаватися в подробиці. Якщо ви хочете отримати більш детальний опис, ви можете переглянути його статтю. Тим не менш, ми вважаємо, що вертикальна інтеграція заслуговує окремого вступу, щоб підкреслити, наскільки ми можемо бути модульними (і чому), а також представити деякі проблеми та проблеми, пов’язані з вертикальною інтеграцією.
Хоча поточна спільна схема замовників Astria, Espresso та Radius дуже модульна, замовники все ще діють як будівельники та виробники блоків (хоча у випадку Astria вони не виконують транзакції). Astria також активно вбудовувала PBS у свою архітектуру з самого початку.
Якщо PBS не вбудовано в протокол, існує кілька способів реалізації PBS (хоча і з різним ступенем децентралізації). Такі продукти, як SUAVE, використовують офлайн-моделі, такі як MEV-Boost, або впроваджують модулі побудови, такі як модулі Cosmos SDK, створені Mekatek і Skip.
Варто зазначити, що жоден із цих методів не є взаємовиключним. У вас є можливість використовувати кілька різних методів і дозволити кожному висловити свої переваги. Таким чином, ви можете мати виконавців, які змагаються за заміщення цих вакансій. Додавання додаткових параметрів завжди добре (і це відповідає нашій вірі в модульність). Тим не менш, різні реалізації матимуть різні компроміси. Наприклад, у такому випадку, як SUAVE, ви можете додати захист конфіденційності за допомогою технології SGX або Crypto, а також додати до правди економічну безпеку Crypto, замість того, щоб покладатися на повністю надійного централізованого розробника PBS. (Дякую Джону Шарбоно за його відгук тут).
Вертикальна інтеграція в ланцюг розробників забезпечує справедливість без використання ярликів, додавання затримок і зниження продуктивності. Таким чином, ланцюжок конструкторів потребує високої оптимізації та може потребувати дорогого та потужного апаратного забезпечення (що призводить до централізації). Це означає, що для перевірки кінцевого користувача нам, ймовірно, знадобляться якісь легкі вузли (хоча їм доведеться довіряти повним вузлам) або використовувати підтвердження типу стану, щоб переконатися, що ланцюжок і користувачі мають доказ того, що налаштування ставок заповнені, а блоки правильні Construct.
Такий ланцюжок може бути дуже важким для стану (ми хочемо уникнути цього), хоча ці транзакції з важким станом будуть мати пріоритет за допомогою смарт-контрактів. У випадку пріоритетної ставки вона або заповнюється, або не заповнюється (протягом короткого періоду часу), оскільки ставки зазвичай дійсні лише протягом короткого періоду часу, залежно від уподобань. Це означає, що ми зможемо реалізувати дуже ефективне (і раннє) закінчення стану для ставок, що дозволить нам обрізати дані та підтримувати ланцюжок «чистим». Ця дата закінчення терміну дії має бути достатньо довгою, щоб ставки могли бути заповнені першими, але якщо її занадто знизити, досягти форвардних ф’ючерсів на блок-пространство буде практично неможливо. Нам не потрібно оновлювати та отримувати прострочені контракти про ставки, оскільки вони не повинні існувати вічно (на відміну від додатків) – це можна зробити, надавши підтвердження стану/сховища, коли ставки заповнені, або за допомогою рішень для зберігання DAS (наприклад, запропонованих рішення Joachim Neu), щоб зробити його більш «безпечним» і надійним.
Як згадувалося раніше, необхідність перевірки «автентичності» SUAVE може бути обмежена «jusha» (просунутими користувачами) платформи, оскільки більшість користувачів і клієнтів SUAVE можуть отримати від неї значні економічні вигоди. Це може змусити нас дозволити людям запускати повні вузли, лише якщо вони хочуть перевірити, хоча це виключає переважну більшість людей (можна сказати, що їм не потрібно перевіряти). Це (на нашу думку) протилежність Crypto, де ми б віддавали перевагу реалізації «ненадійної» перевірки SUAVE через перевірку стану або легкі клієнтські реалізації.
Причина, по якій це потрібно, полягає в тому, що ви хочете переконатися, що ваш пріоритет ставки було заповнено правильно та що блок було заповнено правильною інформацією під час оплати (щоб уникнути повторного набору та інших помилок). По суті, це проблема оракула - насправді її можна вирішити за допомогою підтвердження стану (як у випадку з усіма SUAVE). Однак ці докази стану викликають іншу проблему під час перетину ланцюжків, як передавати цю інформацію між ланцюгами таким чином, щоб вона не була підроблена або прихована? Це може вимагати проходження сильної економічної остаточності (наприклад, запропонованої Lagrangian), і в цьому випадку ви можете використовувати валідатори EigenLayr, щоб підтвердити остаточність і автентичність ланцюжка, і мати дуже сильні економічні обмеження. Тоді це породжує іншу проблему (наприклад, у контракті про торгах передбачено, що «машина оракула» — у даному випадку особа, яка здійснює повторну заставу — визначила закладений токен і забезпечила економічне зобов’язання — але як ми досягнемо консенсусу між Зовнішніми, які скорочують це? Хоча ви можете написати критерії скорочення, це не є консенсусом, що означає, що соціальне скорочення використовуватиметься за допомогою смарт-контрактів (що майже ніколи не буває «чесним» і може спричинити проблеми). Зараз це стосується EigenLayr. Одна з найбільших проблем із форфейтингом .
Отже, що це нас залишає? Можливо, до тих пір, поки ми не отримаємо «недовірливе» розбивання за межі консенсусу, таким ланцюгам, як SUAVE, можуть знадобитися власні алгоритми консенсусу та криптоекономічна безпека, щоб підтвердити переваги ставок і побудувати надійність блоків. Однак це означає додавання більшої кількості векторів криптоекономічної атаки, особливо якщо Rollup цінність його будівельних блоків набагато вища, ніж його власна криптоекономічна безпека.
Крім того, у ланцюгах типу SUAVE та міждомених MEV ще є багато можливостей для розробки. Ось деякі можливі напрямки досліджень:
Зіставлення намірів і системи на основі намірів
Опукла оптимізація в торгівлі кількома активами
DSL
Перерозподіл MEV
Відкладена війна
Проблема масштабування з одним набором акторів, але її потрібно створити для кількох автоматів зведення
Вираз переваги
Щодо виразу переваги, щоб взаємодіяти зі смарт-контрактом у EVM, необхідно надіслати виклик контракту (повідомлення) певній функції за адресою розгорнутого коду, що містить інструкцію виконання. Хоча користувачі надають вхідні дані, вони можуть не контролювати вихідні дані через можливу постійність.
Навпаки, системи проектування вираження переваг (такі як SUAVE та Anoma) вимагають від користувачів лише підписати переваги заставою, яка виплачується розробникам і виробникам блоків, якщо вподобання шукача виконуються. Для складної комбінаторної логіки, такої як послідовності транзакцій для шукачів і конструкторів MEV, може знадобитися реалізація різних мов і віртуальних машин. Це новий дизайнерський простір, який останнім часом привернув багато уваги, особливо архітектура Anoma. Крім того, ми настійно рекомендуємо цю коротку статтю.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
4D детальний спільний сортувальник: принцип роботи, теорія агрегації та вертикальна інтеграція
Оригінальна назва: "The Shared Sequencer"
Автор: MAVEN11
Компіляція: Kxp, BlockBeats
Уявіть собі, що було б, якби Rollup «з коробки» міг досягти високого рівня стійкості до цензури, простоти розгортання, сумісності, швидкого завершення, жвавості та демократизації MEV. Це може здатися великою метою, але з появою спільного секвенсора вона незабаром може стати реальністю. Однак не всі зведені пакети однакові, тому ми повинні розглянути, як розподілити винагороди та MEV у спільній мережі секвенсора. У цій статті ми досліджуємо, як реалізуються спільні мережі рейтингу, і властивості, яких можна досягти.
Shared Sequencer Networks спочатку представив Алекс Беккет, пізніше Еван Форбс (та Радіус) з команд Celestia та Espresso, а також нову статтю Джона Шарбоно, яка детальніше висвітлює цю тему. Джош, Джордан та їх команда Astria будують першу спільну мережу секвенсора, готову до виробництва. Мережа спільних замовників Astria — це модульний блокчейн, який агрегує та впорядковує транзакції Rollup без їх виконання.
У налаштуваннях Astria сортувальник надсилає впорядковані блоки на рівень DA, а також на вузли Rollup. Зведені отримують гарантії м’якої остаточності від замовника та гарантії жорсткої остаточності від рівня DA (після завершення блоків), а потім вони виконають дійсні транзакції.
Спільна мережа секвенсора — це, по суті, група секвенсорів, сумісних із Rollup, і, як випливає з назви, вона може надавати послуги для різних Rollup. Це має різні компроміси та властивості, які ми детально розглянемо пізніше. Спочатку ми повинні описати найважливіші властивості сортувальника (або набору сортувальників). У Rollup основною вимогою до секвенсора або групи секвенсорів є стійкість до цензури або живучість (деякі з яких походять від базового рівня, а також безпека). Це означає, що дійсна транзакція, надіслана замовнику, повинна бути включена в ланцюжок протягом кінцевого часу (параметр тайм-ауту). Спільній групі замовників потрібно лише переконатися, що транзакції включені в блоки (тобто crLists).
Задовольнити опір цензури та миттєвість водночас досить важко, як ми окреслили в Modular MEV Part II. За допомогою консенсусного алгоритму, такого як Tendermint, ви можете забезпечити відновлення після атаки. Однак у разі нападу ви втрачаєте миттєвість. По суті, вимагати від усіх інших колаторів підписувати блок, а не вибирати спеціальну майстерноду, ймовірно, не є оптимальним. Хоча це підвищує стійкість до цензури, це відбувається за рахунок «централізації» та вилучення MEV до однієї головної вузли. Інший доступний механізм сортування можна порівняти з Duality's Multiplicity, який є їхнім маленьким інструментом для не-мастернод (або сортувальників) для включення інших транзакцій у блоки. Загалом, у більшості консенсусних протоколів важко досягти стійкості до цензури та негайності після атаки.
Ще один консенсусний алгоритм, який можна використовувати, це HotStuff 2, який забезпечує негайність у разі атаки.
Це дозволяє уникнути очікування максимальної мережевої затримки (тайм-ауту) у разі цензури або непідписаного для вибору нової головної вузли. Причина, по якій він може бути цікавим алгоритмом консенсусу для децентралізованого набору замовників, полягає в тому, що він вирішує проблему негайності в консенсусі без додавання додаткового етапу. Якщо майстерноді відомий найвищий лок (найбільша кількість учасників, які погоджуються на певний вихід) і може переконати чесні сторони, проблема вирішена. Якщо ні, чесна майстернода після певного моменту може взяти на себе відповідальність за пуш, допомагаючи наступній майстерноді. Наприклад, вузлу Hotstuff не потрібно підтверджувати повідомлення про перемикання перед сповіщенням нового головного, але він може безпосередньо перейти до нового перегляду та сповістити нового головного.
Різниця з Tendermint полягає в тому, що, хоча обидва є двофазними (Hotstuff1 має три, Hotstuff2 має два), Tendermint має лінійний зв’язок, але не реагує, тоді як Hotstuff2 є реактивним. Якщо є ланцюжок чесних майстернод, протокол відповідає позитивно, оскільки всі кроки, крім пропозиції першої майстерноди, залежать від отримання кількості інформації з попереднього кроку. У налаштуванні спільного замовлення це дозволяє протоколу досягти кращої миттєвості без повернення до нижнього рівня, не скасовуючи цю можливість.
Побудова спільних груп сортувальника
Групі замовників дозволено надсилати транзакції на рівень розрахунків (рівень, на якому знаходиться Rollup). Ви можете приєднатися до цієї групи сортування за умови виконання певних вимог і не досягнуто необхідної кількості виробників блоків. Це оптимізує затримку, пропускну здатність тощо. Ці вимоги подібні до тих, які потрібні, щоб стати валідатором блокчейну. Наприклад, ви повинні відповідати певним вимогам до обладнання, а також початковий депозит, особливо якщо ви хочете запропонувати впевненість у фінансових умовах.
Спільна група замовників (або будь-яка децентралізована група замовників) складається з кількох компонентів, які працюють разом, щоб забезпечити правильну обробку транзакцій, зокрема:
Надайте JSON-RPC для кожного зведеного пакета для подання транзакції (для неповних операторів вузла) на вузол як пул пам’яті, а потім побудуйте та сортуйте. У mempool необхідний певний механізм для визначення черги, а також процесу вибору транзакцій, щоб забезпечити ефективну побудову блоків.
Алгоритм побудови блоків/пакетів, відповідальний за обробку транзакцій у черзі та перетворення їх у блоки чи пакети. Цей крок також може включати стиснення для зменшення кінцевого розміру блоку (так зване стиснення даних). Як згадувалося, це має бути окремо від Proposer, по суті PBS. Дані можна стискати різними способами, наприклад:
Відсутність полів даних: поля даних не потрібні для простих переказів, але потрібні для складніших транзакцій.
Замініть окремі підписи зведеними підписами BLS: підписи є найбільшим компонентом транзакцій Ethereum. Замість того, щоб зберігати кожен підпис, ви можете зберігати зведені підписи BLS для певної кількості транзакцій. Ви також можете перевірити сукупний підпис BLS щодо набору повідомлень і набору відправників, щоб переконатися в його дійсності.
Використовуйте поле «Від» як індекс: як і поле «Кому», ви можете використовувати поле «Від» як індекс для зіставлення.
Цікава концепція «модульного» дизайну полягає в тому, що ви можете вносити коригування та компроміси за потреби, щоб змусити його працювати для вашого Rollup.
Алгоритм головної ротації для спільних наборів упорядників (консенсус не потрібен у разі обрання єдиного головного). Ви можете встановити лише алгоритм ротації головного вузла або скористатися маршрутом створення кількох одночасних блоків, запропонованим Duality.
Алгоритми консенсусу, такі як вищезгаданий Tendermint або Hotstuff2, можуть гарантувати, що вузли Rollup узгоджуються з послідовністю, запропонованою реєстром.
Клієнт RPC для надсилання блоків/пакетів на базовий консенсусний рівень DA+, щоб блоки/пакети можна було безпечно додавати до рівня DA, забезпечуючи «остаточну» завершеність і роблячи всі дані транзакцій доступними в ланцюжку.
Розділіть ролі будівельників і виробників блоків, щоб забезпечити справедливість і послідовність і уникнути крадіжки MEV. Також видаляє виконане сортування, що важливо для оптимізації ефективності, зменшення PGA та збільшення CR.
*Вузли зведення отримують упорядковані блоки від сортувальника для м’якого подання та отримують упорядковані блоки рівня DA для жорсткого подання. *
Calldata спочатку публікується в базовій мережі, де виконується консенсус, щоб гарантувати транзакції користувачів і зведення. Потім вузол Rollup виконує транзакцію та надсилає функцію переходу стану в канонічний ланцюжок Rollup. Мережа спільних замовників надає Rollup миттєвість і стійкість до цензури. Зведені зберігають свій суверенітет, оскільки всі дані транзакцій зберігаються на базовому рівні, що дозволяє їм у будь-який час розгалужуватися від спільного замовника. Корінь стану функції переходу стану зведення (STF) обчислюється з коренів транзакції (вхідних даних), надісланих із спільного замовника на рівень DA. У Celestia корені стану генеруються, коли дані додаються до ланцюжка та досягається консенсус. Оскільки у вас уже є корінь транзакції (і всі доступні дані), Celestia може надати легким клієнтам (вузли зведення, що працюють на Celestia) з невеликим підтвердженням включення.
Щоб забезпечити очікувану користувачами взаємодію з користувачами, вузли зведення отримують упорядковані блоки (які також надсилаються на рівень DA). Це може надати Rollup м’які детерміновані гарантії — гарантії того, що блоки врешті-решт будуть упорядковані в порядку на рівні DA, після чого вузли Rollup виконують транзакції та надають нові корені стану.
Створення блоку та слот
Щоб визначити час створення блоку, секвенсору необхідно встановити слот. Секвенсор повинен надсилати пакети через фіксовані проміжки часу (зазвичай X секунд), де X — час інтервалу. Це гарантує оперативну та ефективну обробку транзакцій, оскільки в іншому випадку майстер-нода для певного слота закінчиться та втратить винагороду за підписання (і винагороду за виконання). Наприклад, час блокування Celestia (згідно зі специфікаціями GitHub) становить близько 15 секунд. Оскільки це відомо, ми можемо зробити деякі припущення щодо того, скільки «слотів/блоків» ми можемо мати від спільного набору координаторів до рівня DA та вузлів зведення завантажуються в завершені блоки. У цьому відношенні ми можемо посилатися на оптимізовані Tendermint або Hotstuff2.
У межах одного слота ми можемо надсилати кілька пакетів транзакцій за умови, що дизайн включає механізми для повних вузлів Rollup для ефективної обробки їх в один блок (протягом цього періоду часу та параметрів тайм-ауту). Це допомагає додатково оптимізувати створення блоків і забезпечує швидку обробку транзакцій. Крім того, слоти також можна використовувати для полегшення вибору головних вузлів сортувальника. Наприклад, ви можете випадковим чином вибрати головний вузол слота з пулу ставки на основі ваги ставки. Зробити це таким чином, щоб зберегти конфіденційність і застосувати щось на кшталт таємних виборів лідера, щоб мінімізувати цензуру, є найкращим варіантом; або навіть налаштування технології розподіленої перевірки, як-от рішення на зразок Obol/SSV. Затримка та час слота мають великий вплив на надсилання блоків і збірки протоколу. Тому нам потрібно подивитися, як це впливає на систему. Bloxroute має кілька чудових досліджень і даних, зокрема щодо Ethereum. У MEV-Boost виробники блоків, що беруть участь (валідатори або секвенсори у випадку Rollup), запитують GetHeader у ретранслятора. Це дає їм значення ставки блоку, яке є вартістю конкретного блоку. Це може бути блок найвищої вартості, отриманий щоразу. Для кожного слота валідатори зазвичай запитують GetHeader приблизно через 400 мс після початку слоту - через велику кількість валідаторів ретрансляторам часто потрібно надсилати численні запити. Це також може статися з великими спільними групами сортувальників. Це означає, що вам потрібна інфраструктура для полегшення цього процесу.
Ретранслятори також допомагають розділити будівельників і виробників блоків, одночасно перевіряючи, що будівельники створили правильні блоки. Вони також перевіряють правильність сплати комісій і діють як захист від DoS. Крім того, вони в основному є зберігачами блоків і займаються реєстрацією валідаторів. Це особливо важливо в архітектурі необмеженого секвенсора, оскільки вам потрібно відстежувати, хто брав участь, а хто ні (наприклад, рівень синхронізації, про який йшлося раніше).
Що стосується часу блокування (тобто блокування, надісланого творцями), то воно зазвичай становить приблизно 200 мілісекунд. Здебільшого вони починають працювати до/після приблизно 200 мс, хоча, як і GetHeader, є значні варіації. Якщо розробник надсилає блок до кількох ретрансляторів, це спричинить значну затримку. Bloxroute також розглянув, що відбувається, коли блоки надсилаються на кілька ретрансляторів. Як і можна було очікувати, затримка для розповсюдження блоку на більше реле буде більшою. У середньому другому ретранслятору знадобилося 99 мілісекунд, щоб витратити блок, третьому — 122 мілісекунди, а четвертому — 342 мілісекунди.
За останні кілька місяців ми, напевно, дізналися, що RPC дуже важливий для блокчейнів. Це величезний тягар без належної інфраструктури, і наявність відповідної опції RPC також є критично важливою. У цьому випадку RPC важливий для роздрібних інвесторів, які надсилають свої транзакції в RPC (і публічний mempool). Bloxroute провів невеликий тест із 20 транзакцій, надісланих до різних RPC, і виміряв час, потрібний для включення кожної транзакції в блок.
Джерело: Bloxroute Labs
Цікаво, що деякі RPC не включають транзакції до кількох блоків пізніше, залежно від того, який конструктор переможе в наступному блоці. Якщо RPC надсилає транзакцію більшій кількості розробників, то ймовірність швидкого включення вища. Хоча ініціатори транзакцій можуть використовувати свою унікальну позицію для потоку замовлень для націлювання на конкретних розробників або навіть для створення власних блоків.
Їх продуктивність також цікава в статистиці продуктивності ретрансляції Ethereum. Це допомагає нам отримати глибше розуміння того, як працює PBS у світі кількох валідаторів/будівників/ретрансляторів, чого ми сподіваємося досягти завдяки зведеному оновленню. Metrika має чудову статистику з цього приводу, і всі точки даних належать їм.
Важливо зауважити, що пропущені ставки виникають, коли очікується, що ретранслятор зробить ставку, але не робить ставку. Цільові очікування надходять від валідаторів, зареєстрованих у певному реле для будь-якого слота. Це не помилка реле як така, і вона не обробляється таким чином на рівні протоколу.
Джерело: app.metrika.co
Якщо виникає збій (наприклад, реле, що обслуговує недійсний блок), і воно є відповідальним, це буде зараховано як збій. Зазвичай це трапляється рідко і здебільшого пов’язано з помилками в налаштуваннях реєстрації (тобто ліміти на газ або комісії, які не відповідають реєстрації для певного валідатора). Ще рідше трапляються збої рівня консенсусу, які не відповідають правилам рівня консенсусу Ethereum, наприклад неправильні слоти або батьківські хеші, не узгоджені з попереднім блоком тощо.
З точки зору затримки (наприклад, часу, необхідного валідатору для отримання заголовка блоку, створеного конструктором), дані дуже послідовні. Хоча є деякі викиди, наприклад, географічне розташування запитаного ретранслятора відрізняється від обраного валідатора.
Джерело: app.metrika.co
Що стосується будівельників, то загальна кількість будівельників на MEV-boost становить приблизно 84, причому три найкращі будівельники будують близько 65% побудованих блоків. Хоча це може ввести в оману, оскільки це також найдавніші будівельники. Результати будуть аналогічними, якщо скоротити часові рамки. Кількість фактично активних будівельників значно менша: 35 за останні 30 днів і 24 за останній тиждень. Конкуренція жорстка, і зазвичай перемагає найсильніший будівельник. Ексклюзивний потік замовлень може вже існувати, що лише погіршить ситуацію. Ми очікуємо, що розподіл розробників залишатиметься відносно централізованим (оскільки це змагання за оптимальний потік замовлень і оптимізацію апаратного забезпечення), якщо ми не внесемо серйозних змін у налаштування. Хоча це не фундаментальна проблема, це все ж централізуюча сила в стеку, і ми хотіли б почути ідеї щодо того, як кинути виклик статус-кво тут. Якщо ви зацікавлені в глибшому дослідженні цієї (серйозної) проблеми, ми настійно рекомендуємо прочитати статті Quintus про потік замовлень, аукціони та централізацію.
Що стосується ролі Builder у майбутньому стеку модульності, ми майже впевнені (принаймні в налаштуваннях Cosmos SDK) ми побачимо налаштування Builder Modules, схоже на Skip/Mekatek. Іншим рішенням є налаштування типу SUAVE, наприклад спеціальна глобальна мережа розробників, що надає послуги блокової побудови та налаштування ставок будь-якій кількості мереж для забезпечення PBS. Пізніше ми детальніше розглянемо це рішення та дамо деякі відповіді на запитання, які тут не розглянуті.
Щодо реле, ми настійно рекомендуємо прочитати статтю Анкіта Чіплункара з Frontier Research і Майка Нойдера з Ethereum Foundation під назвою «Оптимістичні реле і де їх знайти». У цій публікації детально описано, як працюють реле в MEV-boost, їхні поточні компроміси та експлуатаційні витрати, а також деякі зміни, які можуть підвищити ефективність. Цікаво, що за підрахунками Flashbot, запуск реле в MEV-Boost наразі коштує близько 100 000 доларів США на рік.
Детермінований
Перш ніж ми поговоримо про детермінізм модульних блокчейнів (як вони зараз виглядають), давайте поглянемо на нашу попередню статтю «Модульний MEV». Зауважте, що це не «офіційний» і не вичерпний погляд на остаточність, але ми вважаємо, що він найточніше представляє нюанси остаточності зведення для полегшення розуміння.
Pending_On_L2: Замовник зведення представляє м’яке зобов’язання щодо того, що транзакцію користувача врешті-решт буде прийнято та завершено на базовому рівні безпеки.
Finality_On_L2: секвенсор прийняв функцію переходу стану зведення, і блок додано до канонічного ланцюга зведення.
Очікує_On_L1: функція переходу введення або виведення/стану транзакції була опублікована в L1, але підтвердження дійсності ще не видано, або період арбітражу ще не закінчився - для цього потрібен Ethereum протягом двох послідовних епох. Це момент, на якому більшість Optimistic Rollups кажуть, що вони досягли завершеності, але на цьому етапі все ще існує довільний 7-денний період перевірки відповідно до специфікації перехресного мосту.
Finality_On_L1: для Optimistic Rollup арбітражний період закінчився, або опублікований і перевірений доказ дійсності підтверджено супербільшістю протягом двох послідовних епох.
Тепер, у Sovereign Shared Sort Rollup, це виглядає дещо інакше, давайте спробуємо пояснити це за допомогою діаграми:
У цьому випадку теоретично ми можемо отримати детермінізм на L1 перед L2 тощо? Так, у цьому випадку L2 є суверенним. Це припускається, що немає доказів шахрайства та періодів оскарження, або ви використовуєте підтвердження дійсності.
Отже, як ми досягаємо цих рівнів остаточності? Завершеність блоку досягається, коли до канонічного ланцюга додається блок, який неможливо вилучити. Однак тут є свої нюанси в залежності від повних або світлих вузлів. У випадку впорядкованого блоку він є детермінованим, коли його включено до блоку рівня DA. Блоки (з коренями стану) підтримуються повними вузлами/валідаторами Rollup, що дає їм гарантію дійсного кореня стану, отриманого з упорядкованих блоків базового рівня. Для детермінізму за межами повних вузлів (наприклад, для легких клієнтів або крос-ланцюгових мостів) ви повинні бути впевнені в дійсності цього кореня стану. Тут ви можете скористатися одним із методів, описаних нижче. Крім того, інший підхід полягає в тому, щоб валідатори відповідали за правильний доказ кореня стану (оптимістичний шлях) через зобов’язання та подальший доказ шахрайства. Додатково можна надати підтвердження дійсності (ЗК).
Різні способи досягнення остаточності блоку:
Через підтвердження роботи (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) та інші імовірнісні методи.
Доказовий метод за допомогою достатньої кількості членів комітету, які підписують блоки. (наприклад, Tendermint 2/3, Hotshot2 або інші типи PBFT)
Залежить від упорядкування транзакцій/блоків на рівні DA та його правил, а саме правил вибору канонічного ланцюга та розгалуження.
Ми можемо досягти різних типів остаточності за допомогою різних механізмів.
Одним із типів остаточності є «м’яка остаточність» (наприклад, незавершена), яка може бути досягнута шляхом обрання одного лідера. У цьому випадку кожен слот матиме лише один або нуль блоків (зафіксованих чи ні), і рівень синхронізації може безпечно вважати послідовність транзакцій у цих блоках.
Іншим типом остаточності є «доказова остаточність», яка надає сильніші гарантії (по суті остаточна), ніж м’яка остаточність. Щоб досягти доведеної остаточності, більшість замовників повинні підписати блок, висловлюючи таким чином свою згоду з тим, що блок є канонічним. Хоча цей підхід хороший, він може бути непотрібним, якщо було реалізовано єдиний вибір лідера, оскільки він, по суті, гарантує впорядкування блоків. Очевидно, це залежить від конкретного реалізованого алгоритму виборів лідера. Наприклад, це 51% виконання, 66% впровадження чи єдиний лідер (бажано випадкові (VRF) і таємні вибори). Якщо ви хочете дізнатися більше про детермінізм в Ethereum, прочитайте цю статтю, яку ми настійно рекомендуємо, і статтю, яку ми порекомендуємо пізніше для необмежених наборів сортувальників.
ліцензований, напівліцензований або без дозволу
Щоб запобігти потенційним DoS-атакам, необхідно встановити економічні бар’єри, щоб приєднатися до групи замовників і відправити транзакції на рівень замовників. В обмежених (кінцева кількість сортувальників) і необмежених (необмежена кількість сортувальників) групах необхідно встановити економічні бар’єри для надсилання пакетів на рівень DA, щоб запобігти уповільненню або DDoS-атаці рівня синхронізації (розповсюдження блоків між сортувальниками). . Однак сам рівень DA також забезпечує певний захист, оскільки надсилання даних на нього вимагає певних витрат (da_fee). Гарантійний депозит, необхідний для приєднання до необмеженої групи, має покривати будь-які додаткові витрати, необхідні для запобігання спаму на рівні синхронізації. З іншого боку, маржа, необхідна для приєднання до обмеженої групи, залежатиме від попиту (збалансованого з точки зору витрат/доходу).
Для необмеженого набору сортувальників ми не можемо досягти доведеної остаточності на рівні сортувальника (оскільки ми ніколи не знаємо точно, скільки є активних голосуючих/підписувачів). З іншого боку, в обмеженій групі коортерів доведена остаточність може бути досягнута більшістю коортерів, які підписують блоки. Для цього потрібно, щоб рівень синхронізації був у курсі рівня секвенсора та кількості секвенсорів, які активні в будь-який момент часу, що створює додаткові витрати. У обмеженому наборі сортувальників (наприклад, до 100) ви також можете оптимізувати кількість сортувальників, щоб покращити «продуктивність», але за рахунок децентралізації та стійкості до цензури. Важливість обмежених груп та економічних гарантій для забезпечення "швидкої" доказової визначеності також є детерміністською.
Типи необмеженого сортувальника та обмеженого сортувальника також відображаються в традиційних блокчейнах. Наприклад, PoS (Casper+LMD-GHOST) в Ethereum використовує необмежений тип, тоді як ланцюжок на основі Cosmos SDK/Tendermint приймає обмежений тип. Цікава думка: чи очікуємо ми побачити економіку, подібну до доказу частки, і варіанти від спільноти навколо спільних замовників? У зв’язку з цим ми спостерігаємо рух у бік централізації деяких організацій (тому необмеженість не має особливого значення, якщо у вас уже є кілька великих постачальників/пулів доказів участі). Незважаючи на те, що вони «приховують» централізацію, зрештою, ви все одно можете майніти, якщо хочете. З ідеологічної точки зору вибір майже завжди має бути необмеженим, але пам’ятайте, що економічні принципи все одно роблять їх дуже схожими. Незалежно від того, ким є учасники, економіка того, що ви платите, має бути однаковою, наприклад, вартість DA та вартість апаратного забезпечення (хоча це може бути зменшено кількістю підтверджень частки, які ви розподіляєте, і досвіду, а також ефективність функціонування інфраструктури). Навіть у обмеженому світі PoS ми бачили, як група постачальників інфраструктури стала найбільшим і найпоширенішим валідатором майже в усіх мережах. У більшості ланцюжків Cosmos залежності між валідаторами вже дуже великі, і це, безумовно, становить небезпеку для децентралізації та стійкості цих ланцюгів до цензури. Проте зовсім інший факт полягає в тому, що будь-який роздрібний інвестор може зробити ставку на будь-яку суму за допомогою будь-якого валідатора, який він вибере. На жаль, це зазвичай призначається у верхній частині списку, і життя продовжується. Ми знову запитуємо: чи очікуємо ми подібної економічної моделі в модульному світі? Хочеться, щоб це було не так, але зі спеціалізацією вам часто потрібен найкращий варіант – і вони, як правило, є професійними постачальниками доказів частки. Ми також розглянемо ці економічні питання в окремому розділі пізніше.
Однак одна важлива річ, про яку слід пам’ятати в усіх цих питаннях, полягає в тому, що найважливішою є автентифікація кінцевого користувача, яка доступна будь-кому, незалежно від того, де вони знаходяться (навіть у Гізі) через легкі клієнти та піраміду DAS).
Джерело: @JosephALChami
Ось компроміси та переваги обмежених і необмежених сортувальників:
Необмежений набір сортувальників:
*Будь-хто з достатньою кількістю облігацій/стейкінгу може стати сортувальником = високий ступінь децентралізації
Обмежений набір сортувальників:
Це одне з рішень Ethereum для детермінізму одного слота та наявності комітету супер-більшості.
Існує значний простір для того, як відстежувати ці набори сортувальників і додавати або видаляти нових учасників. Наприклад, чи буде це досягнуто за допомогою управління Tokenholder (як щодо багатьох різних токенів і зведених пакетів, що використовують колекції?). Це означає, що сигналізація про зміни поза мережею може бути можливою через соціальний консенсус (наприклад, візьмемо Ethereum як приклад). Однак пам’ятайте, що фактичний консенсус у ланцюзі чітко встановлений, і штрафи за порушення правил консенсусу вже існують.
Економічний механізм для спільних сортувальників
Економіка спільного використання мережі секвенсорів передбачає кілька цікавих варіантів. Як ми обговорювали раніше, валідатори в спільній мережі замовників не дуже відрізняються від типових валідаторів L1. Мережа, в якій він бере участь, просто більш оптимізована для виконання одного завдання, яке полягає в отриманні намірів (раніше PBS), а отже, пропонуванні та замовлення транзакцій. Як і у «звичайних» валідаторів, є компоненти доходів і витрат. З обох сторін рівняння існує велика гнучкість у мережах, у яких беруть участь валідатори, подібно до звичайного L1.
Дохід надходить від користувачів або Rollups, з якими вони зрештою хочуть взаємодіяти, сплачуючи певну плату за використання спільного секвенсора. Ця комісія може бути відсотком від вилученого MEV (введені цифри може бути важко підрахувати), міжланцюговим переказом вартості, газом або фіксованою комісією за взаємодію. Найбільш відповідним рішенням для отримання прибутку може бути сплата спільному замовнику меншої вартості, ніж додаткова вартість, отримана через спільного замовника Rollup, разом із перевагами спільної безпеки та ліквідності. Але недоліком цього є те, що важко кількісно оцінити переваги децентралізації іншої частини стека. Однак, оскільки спільна мережа замовників розростається у власну екосистему, її здатність отримувати комісію може збільшуватися. Це значною мірою пояснюється їх властивою здатністю легко агрегувати з певною економією на масштабі. У міру того, як до мережі приєднується більше зведених пакетів і додатків, все більше і більше міждомених MEV зможуть видобувати.
З точки зору вартості, спільні мережі замовлення також мають конкуруючі варіанти. Вони можуть легко фінансувати використання своєї мережі, фінансуючи витрати на публікацію на рівні DA або навіть вартість взаємодії з програмами на Rollup. Це схоже на стратегію, яку використовують компанії Web 2.0, де ви берете на себе початкові втрати від залучення користувачів (або згортання), сподіваючись, що їхній довгостроковий дохід перевищить комісію. Інший більш новий або Crypto-native метод полягає в тому, щоб дозволити Rollup сплачувати комісії DA за допомогою рідного токена. Тут спільний рівень сортувальника несе ризик ціноутворення між маркером, необхідним для публікації даних на рівні DA, і рідним маркером Rollup. По суті, це все ще спільний сортувальник початкових витрат, але він створює узгодженість екосистеми шляхом отримання маркера «постачальника» (тобто Rollup). Це дещо схоже на будівництво складу, яке ми пояснювали в документі AppChain, і різні форми DA можна використовувати для зниження витрат. Різні рівні DA пропонуватимуть різні ціни через використання, можливість користувачів легко перевіряти через легкий клієнт або просто вибирати інший розмір блоку. Нарешті, спільний замовник також може групувати транзакції перед публікацією на рівні DA. У випадку ZKR це може зменшити транзакційні витрати через певну кількість балансів транзакцій, а з точки зору ORU ви можете виконувати різні оптимізації газу пакетної обробки, які ми зараз можемо бачити в різних зведених пакетах. Це зменшить кількість даних, які необхідно опублікувати на рівні DA, таким чином зменшуючи вартість спільної мережі секвенсора та підвищуючи прибутковість усієї мережі. Це відбуватиметься за рахунок обмеження сумісності та зміни часу завершення блоку (детермінізм на L1, як згадувалося раніше).
Загалом, економіка спільного використання мережі секвенсорів дозволяє проводити деякі цікаві експерименти та стратегії початкового завантаження. Ми вважаємо, що ключовою відмінністю буде розмір екосистеми, тому кількість міждомених MEV є більшою, ніж аспект вартості. Ми також настійно рекомендуємо ознайомитися з дописом у блозі команди Espresso про спільних замовників, вони також розповідають про економічні компроміси (і позитивні сторони) цих типів мереж. Щоб показати, чому Rollup мотивований скористатися перевагами спільних сортувальників (крім економіки), ми можемо розглянути це з точки зору теорії агрегації.
Теорія агрегації та спільні сортувальники
Інший спосіб описати властивості, створені спільними сортувальниками, — через призму теорії агрегації. Теорія агрегації стосується концепції того, як платформа або агрегатор систематично інтегрує інші платформи та їхніх користувачів, щоб привернути значну увагу користувачів. По суті, ви переміщуєте гру від розподілу дефіцитного ресурсу (наприклад, блокового простору) до необхідності контролювати надлишок ресурсу (знову ж таки, блоковий простір має сенс у цьому прикладі). Теорія агрегації фактично об’єднує постачальників і продукти (тобто Rollup і Blockspace) у суперкористувацький досвід для обслуговування агрегованої бази користувачів. У міру того, як мережевий ефект цих агрегаторів зростає, цей зв’язок стає все більш ексклюзивним. Коли це відбувається, користувацький досвід стає ключовою відмінністю між подібними налаштуваннями. Якщо є стимули для залучення нових користувачів (наприклад, хороша взаємодія з користувачами та краща сумісність), малоймовірно, що Rollup переміститься у власну мережу чи інше налаштування, оскільки мережеві ефекти стимулюють нових постачальників і нових користувачів. Це створює ефект маховика не лише з точки зору постачальника та користувача, але й з точки зору сукупної стійкості до цензури.
Джерело: Теорія агрегації 2015, Бен Томпсон
У царині спільних сортувальників теорію агрегації можна розглядати як «комбінації» та об’єднання різних зведених пакетів, усі з яких використовують однакові вертикалі стека, надаючи можливості собі та іншим, одночасно дозволяючи користувачам отримати той самий досвід.
Постачальники (такі як Rollups) теоретично не є винятковими для спільного набору коортерів, але на практиці спільний набір coorter, його зведення та користувачі отримують вигоду від серії циклів мережевих ефектів, які призводять до збільшення використання цих зведень. Ці переваги спрощують інтеграцію Rollups і користувачів у спільний стек, оскільки вони можуть більше втратити, якщо не беруть участі. Хоча ці переваги може бути важко помітити, коли у вас є лише два зведені пакети, які спільно використовують один набір секвенсорів, вони стають більш очевидними, коли ви додаєте все більше і більше зведених пакетів і користувачів до рівняння. Спільні набори сортувальників мають пряме відношення до користувачів, оскільки вони впорядковують свої транзакції, навіть якщо самі користувачі не знають, що вони з ними взаємодіють, оскільки, з їх точки зору, вони просто використовують зведені пакети, з якими у них є причина взаємодіяти ( Це означає, що замовлення/сортувальники стають ексклюзивними). Єдиною ціною цих сортувальників є вартість апаратного забезпечення для їх запуску, якщо простір блоку та токени, які його захищають, є цінними для кінцевого користувача. Комісії за транзакції оцифровані, сплачуються з гаманців користувачів і, можливо, у майбутньому можуть бути навіть абстраговані за допомогою таких вдосконалень, як хости платежів у абстракції облікового запису (однак комусь доведеться нести витрати на DA, замовлення та виконання).
Це має більше сенсу, якщо взяти до уваги попередню компанію Джоша та Джордана в Астрії – Google. З моменту свого створення продукти Google надихалися ідеєю AT, зокрема в Пошуку Google, який створюється шляхом модульування окремих сторінок і статей, що робить їх прямим доступом через вікно глобального пошуку.
У випадку спільного набору сортувальників користувачі, які використовують Rollup (ті, хто спільно використовує набір сортувальників), мають усе нижчі витрати на придбання, оскільки зі збільшенням кількості постачальників (Rollup) їх, швидше за все, приверне набір . Це означає, що в більшості випадків агрегатор (або мультиагрегатор) має можливий взаємовигідний ефект, оскільки цінність агрегатора зростає зі збільшенням кількості постачальників (звичайно, за умови, що досвід користувача хороший). Навпаки, в одній послідовній мережі залучення клієнтів обмежується однією мережею та її програмами. Якщо користувачі хочуть використовувати програму Rollup на іншому Rollup, їм доведеться (у межах поточних обмежень) повністю вийти з мережі. Це означає, що прихильність користувачів і цінність не дуже високі, а також це означає, що в будь-який момент, якщо інша екосистема Rollup високо цінується (або має більше стимулів), капітал може бути втрачений.
Резюме атрибутів і компромісів
Атрибути
Спільний набір сортувальників — це зведена мережа, яка об’єднує та сортує транзакції для кількох зведених даних. Ці зведені пакети використовують той самий сортувальник. Таке об’єднання ресурсів означає, що зведені пакети отримають сильнішу економічну безпеку та можливості боротьби з цензурою, що може забезпечити швидкі м’які детерміновані гарантії та умовні крос-зведені транзакції.
Прямо зараз є багато шуму щодо атомарності серед Rollups, які використовують той самий набір сортувальників, здебільшого навколо того, чи є він атомарним за замовчуванням, а це не так. Проте, якщо розглянуті зведені реалізують функції переходу стану (STF) одна одної як залежності між ними, включаючи умовні транзакції, тоді вони справді можуть досягти атомарності між ними - за умови, що їх вирівнювання слотів/блоків (як із спільними наборами сортувальника). У цьому випадку, щоб отримати атомарну сумісність, вам справді потрібно лише запустити легкий клієнт ланцюжка B на ланцюжку A і навпаки (подібно до того, як працює IBC). Для подальшого посилення сумісності заходів безпеки (крім довіри до єдиного повного вузла як легкого вузла), ви можете запровадити ZKP (Proof of State), щоб вирішити «проблему оракула» щодо забезпечення правильності стану. Це дасть змогу чіткіше побачити, чи умовна транзакція чи щось подібне натрапило на канонічний перехресний міст між ними. Докази шахрайства також є можливістю, але, очевидно, залишить період оскарження (це означає, що третя сторона прийде, щоб покрити вартість цього ризику). Крім того, у випадку легких клієнтів (а не повних вузлів) він буде відставати принаймні на один блок через очікування заголовка підпису + вікна захисту від шахрайства (якщо таке є).
Ми вважаємо, що проблему «перехресного мосту», швидше за все, можна вирішити за допомогою легких клієнтів і доказів з нульовим знанням. Проблема з використанням полегшеного клієнта (а не смарт-контракту) у цьому випадку полягає в тому, що хардфорки (оновлення тощо) на стороні вузла Rollup повинні координуватись один з одним, щоб підтримувати роботу свого мосту (подібно до того, як IBC потребує ввімкнення той самий модуль стану ). Якщо ви хочете глибше зануритися в цю конкретну тему (і як її вирішити), ми настійно рекомендуємо переглянути цю презентацію.
Причина, по якій спільні замовники настільки добре масштабуються, полягає в тому, що вони не виконують і не зберігають жодного стану (як це роблять сьогодні централізовані замовники). Те саме стосується самих вузлів зведення (якщо вони не хочуть мати атомарність між собою, наприклад, легкий клієнт/підтвердження стану). Ці вузли виконують лише ті транзакції, які дійсні для їхнього зведення, і будь-які умовні міждоменні транзакції, які є дійсними для них. Якщо вузол зведення має виконувати та зберігати стан для кількох зведень, це перешкоджає масштабованості та знижує децентралізацію (і, отже, опір цензурі). Це також підсилює концепцію поділу виробника на блоки (PBS). Хоча нам ще потрібно повністю розділити будівельників і блок-виробників. У поточному налаштуванні замовники по суті є конструктором і виробником блоків (хоча вони не виконують транзакції). Ідеальним налаштуванням може бути таке, коли замовник існує лише для того, щоб сліпо підписувати блоки з високооптимізованого налаштування конструктора та гарантувати, що блоки реалізовано правильно (одночасно забезпечуючи високий ступінь економічної визначеності та стійкість до цензури щодо цієї сертифікації). Таким чином вони можуть забезпечити високий рівень безпеки та зобов’язань, щоб гарантувати м’яку завершеність для вузлів зведення.
Для перехресних умовних транзакцій вони також існують, щоб допомогти вузлам зведення (виконавцям) надавати корені проміжного стану, забезпечуючи атомарність між зведеннями.
компроміс
Вищезгаданий параметр тайм-ауту має деякі цікаві ефекти на MEV і включення транзакцій, залежно від механізму головної вузли/консенсусу набору замовника. Наприклад, якщо параметр тайм-ауту описується як відносно короткий у нашій ланцюжковій статті для конкретної програми, важливо, щоб виробники блоків децентралізованого набору замовників публікували дані якомога швидше. У такому світі ви можете спостерігати конкуренцію між «валідаторами», які змагаються за те, щоб стати головними вузлами, і роблять ставки на рівні DA за простір блоків, доки це не стане прибутковим.
Як писав Еван у своїй оригінальній публікації про ледачого замовника на форумах Celestia, очікування публікації транзакцій на базовому рівні (у цьому випадку Celestia) перед їх виконанням є дуже неефективним. Оскільки тепер ви обмежені часом блокування базового рівня, який занадто довгий, щоб чекати на досвід користувача. Для кращої взаємодії з користувачем спільний замовник надає зведеним пакетам м’які детерміновані зобов’язання (як описано раніше), які надають користувачам досвід, до якого вони звикли в існуючих централізованих зведених пакетах (зберігаючи при цьому децентралізацію та високу стійкість до цензури). М’які зобов’язання – це, по суті, лише зобов’язання щодо остаточного порядку транзакцій, але підкріплені серйозними економічними гарантіями та швидким завершенням після випуску. Це також покривається доказами шахрайства (як зазначено у вступі). Фактична жорстка остаточність досягається після публікації всіх даних транзакцій на базовому рівні (це означає, що L1 фактично досягає швидшої остаточності). Це залежить від того, використовує Rollup докази шахрайства чи докази нульового знання для перевірки доказів суверенітету, що відбувається на Rollup. Причина бажання цього розділення полягає в тому, щоб усунути величезне вузьке місце переходів станів від сортувальника. Натомість вузли зведення мають справу лише з дійсними для них вузлами (це означає, що ми повинні додати умовні транзакції, підтвердження стану або легку перевірку вузла для належної сумісності). Жорсткий детермінізм усе ще залежить від базового рівня (але це може досягати 15 секунд на Celestia, а також є детермінованим у Tendermint), що дає нам відносно швидкі гарантії жорсткого детермінізму на Rollup.
Використовуйте докази з нульовим знанням у мережі, щоб оптимізувати перевірку, розмір транзакції (наприклад, публікувати лише відмінності в стані, але це додає вищий рівень довіри, доки не буде опубліковано ZKP). Як згадувалося раніше, ці підтвердження стану можна використовувати, щоб дозволити підключеним ланцюжкам/зведеним системам мати легшу та швидшу взаємодію (не чекаючи вікон викликів).
Недоліком цих умовних транзакцій є те, що вони, ймовірно, будуть дорожчими, вимагаючи вищих витрат на перевірку та видачу (наприклад, вартість перевірки заголовка блоку Tendermint, яка субсидується в ланцюжку Cosmos), і додадуть деяку затримку системі ( але все одно швидше, ніж ізольовані зведення набагато швидше). Атомарність, досягнута вертикально спільною інтеграцією, може компенсувати ці проблеми.
Під час початкової фази нового зведення використання спільного набору сортувальників має великий сенс, і переваги, які ви отримуєте як постачальник, швидше за все, переважать деякі компроміси, які ви можете «змушені» піти на рівні рову. Однак для вже зрілого Роллапа, де багато транзакцій і економічної діяльності, мабуть, немає сенсу відмовлятися від частини рову.
Це викликає питання, чи потрібен нам подібний економічний/транзакційний (на зведення) зважений перерозподіл вилученого MEV, щоб змусити вже зрілі зведені приєднатися до спільного набору – чи навіть утримати надзвичайно зрілі зведені від створення власної мережі. Все це досить теоретично, але це, безперечно, цікавий процес мислення щодо того, як MEV у спільних вертикальних світах будуть представлені між багатьма зведеними пакетами з різними рівнями активності. Наприклад, якщо унікальний зведений пакет, який створює цінність, ділиться частиною цих прибутків з іншими (ймовірно, не приносячи великої «вартості») через набір секвенсорів, тоді у них повинні бути додаткові причини переходити до власної окремої системи. У Sreeram від EigenLayr є також деякі думки щодо цього, які ми також рекомендуємо прочитати.
Це стає дедалі важливішим, якщо врахувати, що розробка нових ланцюгів потребує значних технічних витрат для шукачів, тому стандартизація та надання певного суверенітету над «своїми» MEV може бути хорошим місцем для початку. На практиці в MEV домінуючий інтерфейс (або програмне забезпечення) може перемогти, але насправді монетизувати це програмне забезпечення за допомогою критичних частин інфраструктури дуже складно (що призводить до централізації). На ринковому рівні те, що надає спільний замовник, — це в основному загальний фонд для кількох постачальників із централізованим аукціоном, що може призвести до здоровішої конкуренції.
Проблема полягає в тому, що якщо два зведених пакети використовують сортувальники в спільному наборі, тоді можна вибрати зведений пакет із «менш економічною» цінністю (A), щоб запропонувати зведений пакет із високою сумою MEV + комісії зі зведеного пакету (B). . З точки зору Rollup B, вони фактично втрачають певну цінність, яку за ізольованого підходу вони залишили б собі.
Розгляд компромісів взаємодії
Ще одна примітка про компроміси, пов’язані з сумісністю, і інший спосіб вирішення деяких проблем:
Метою спільної мережі замовників є надання канонічної гарантії для кількох ланцюжків, що, очевидно, є великою перевагою в цьому випадку. Це можна поєднати з механізмом, який гарантує ефективні переходи між зведеними пакетами. Це може бути підхід на основі комітету (наприклад, PoS), надійні докази (оптимістичний підхід) або наш кращий підхід – ZKP, підтверджений підписами комітету. Оскільки спільні сортувальники є «лінивими», вони створюють лише суперблоки для сортування транзакцій кількох зведених пакетів, а виконання конкретної транзакції залишається за певним зведеним пакетом. Докази стану (наприклад, Лагранжа, Аксіоми чи Геродота тощо) є всіма можливими рішеннями для потенційного отримання доказів остаточності через суверенні зведення. Ви навіть можете додати докази економічно гарантованої остаточності через такі речі, як пули ставок, EigenLayr тощо. Основна ідея полягає в тому, що загальний сортувальник забезпечує економічну гарантію впорядкування, а докази дійсності, створені в результаті цього сортування, є детермінованими. Основна ідея полягає в тому, що Rollups можуть виконувати транзакції синхронно один з одним. Наприклад, мережа з двох вузлів зведення може умовно знати, що обидві історії зведення дійсні через ZKP і доступні дані (дані, опубліковані на ефективному рівні DA). Публікуючи єдиний префікс блоку зведення з обох мереж A і B, вузол зведення може встановлювати два зведення одночасно. Одне, що слід зазначити, це те, що умовні транзакції перехресного зведення споживають ресурси з двох окремих систем через спільне виконання, тому атомарні (або синхронні) транзакції перехресного зведення, ймовірно, будуть дорожчими, ніж внутрішні транзакції з одним зведенням.
Succinct також охопив крос-ланцюгові «атомарні» транзакції між зведеними пакетами зі спільними замовниками (і спільними засобами перевірки шахрайства) в екосистемі гіперланцюга Optimism, які можна переглянути тут. Крім того, як каже Бо Ду з Polymer: «Міжланцюгові атомарні транзакції схожі на отримання блокувань між шардами бази даних під час запису».
Майбутнє вертикальної інтеграції
Можливу внутрішню роботу ланцюгів SUAVE вже детально досліджували Джон Шарбоно та інші, тому ми не будемо вдаватися в подробиці. Якщо ви хочете отримати більш детальний опис, ви можете переглянути його статтю. Тим не менш, ми вважаємо, що вертикальна інтеграція заслуговує окремого вступу, щоб підкреслити, наскільки ми можемо бути модульними (і чому), а також представити деякі проблеми та проблеми, пов’язані з вертикальною інтеграцією.
Хоча поточна спільна схема замовників Astria, Espresso та Radius дуже модульна, замовники все ще діють як будівельники та виробники блоків (хоча у випадку Astria вони не виконують транзакції). Astria також активно вбудовувала PBS у свою архітектуру з самого початку.
Якщо PBS не вбудовано в протокол, існує кілька способів реалізації PBS (хоча і з різним ступенем децентралізації). Такі продукти, як SUAVE, використовують офлайн-моделі, такі як MEV-Boost, або впроваджують модулі побудови, такі як модулі Cosmos SDK, створені Mekatek і Skip.
Варто зазначити, що жоден із цих методів не є взаємовиключним. У вас є можливість використовувати кілька різних методів і дозволити кожному висловити свої переваги. Таким чином, ви можете мати виконавців, які змагаються за заміщення цих вакансій. Додавання додаткових параметрів завжди добре (і це відповідає нашій вірі в модульність). Тим не менш, різні реалізації матимуть різні компроміси. Наприклад, у такому випадку, як SUAVE, ви можете додати захист конфіденційності за допомогою технології SGX або Crypto, а також додати до правди економічну безпеку Crypto, замість того, щоб покладатися на повністю надійного централізованого розробника PBS. (Дякую Джону Шарбоно за його відгук тут).
Вертикальна інтеграція в ланцюг розробників забезпечує справедливість без використання ярликів, додавання затримок і зниження продуктивності. Таким чином, ланцюжок конструкторів потребує високої оптимізації та може потребувати дорогого та потужного апаратного забезпечення (що призводить до централізації). Це означає, що для перевірки кінцевого користувача нам, ймовірно, знадобляться якісь легкі вузли (хоча їм доведеться довіряти повним вузлам) або використовувати підтвердження типу стану, щоб переконатися, що ланцюжок і користувачі мають доказ того, що налаштування ставок заповнені, а блоки правильні Construct.
Такий ланцюжок може бути дуже важким для стану (ми хочемо уникнути цього), хоча ці транзакції з важким станом будуть мати пріоритет за допомогою смарт-контрактів. У випадку пріоритетної ставки вона або заповнюється, або не заповнюється (протягом короткого періоду часу), оскільки ставки зазвичай дійсні лише протягом короткого періоду часу, залежно від уподобань. Це означає, що ми зможемо реалізувати дуже ефективне (і раннє) закінчення стану для ставок, що дозволить нам обрізати дані та підтримувати ланцюжок «чистим». Ця дата закінчення терміну дії має бути достатньо довгою, щоб ставки могли бути заповнені першими, але якщо її занадто знизити, досягти форвардних ф’ючерсів на блок-пространство буде практично неможливо. Нам не потрібно оновлювати та отримувати прострочені контракти про ставки, оскільки вони не повинні існувати вічно (на відміну від додатків) – це можна зробити, надавши підтвердження стану/сховища, коли ставки заповнені, або за допомогою рішень для зберігання DAS (наприклад, запропонованих рішення Joachim Neu), щоб зробити його більш «безпечним» і надійним.
Як згадувалося раніше, необхідність перевірки «автентичності» SUAVE може бути обмежена «jusha» (просунутими користувачами) платформи, оскільки більшість користувачів і клієнтів SUAVE можуть отримати від неї значні економічні вигоди. Це може змусити нас дозволити людям запускати повні вузли, лише якщо вони хочуть перевірити, хоча це виключає переважну більшість людей (можна сказати, що їм не потрібно перевіряти). Це (на нашу думку) протилежність Crypto, де ми б віддавали перевагу реалізації «ненадійної» перевірки SUAVE через перевірку стану або легкі клієнтські реалізації.
Причина, по якій це потрібно, полягає в тому, що ви хочете переконатися, що ваш пріоритет ставки було заповнено правильно та що блок було заповнено правильною інформацією під час оплати (щоб уникнути повторного набору та інших помилок). По суті, це проблема оракула - насправді її можна вирішити за допомогою підтвердження стану (як у випадку з усіма SUAVE). Однак ці докази стану викликають іншу проблему під час перетину ланцюжків, як передавати цю інформацію між ланцюгами таким чином, щоб вона не була підроблена або прихована? Це може вимагати проходження сильної економічної остаточності (наприклад, запропонованої Lagrangian), і в цьому випадку ви можете використовувати валідатори EigenLayr, щоб підтвердити остаточність і автентичність ланцюжка, і мати дуже сильні економічні обмеження. Тоді це породжує іншу проблему (наприклад, у контракті про торгах передбачено, що «машина оракула» — у даному випадку особа, яка здійснює повторну заставу — визначила закладений токен і забезпечила економічне зобов’язання — але як ми досягнемо консенсусу між Зовнішніми, які скорочують це? Хоча ви можете написати критерії скорочення, це не є консенсусом, що означає, що соціальне скорочення використовуватиметься за допомогою смарт-контрактів (що майже ніколи не буває «чесним» і може спричинити проблеми). Зараз це стосується EigenLayr. Одна з найбільших проблем із форфейтингом .
Отже, що це нас залишає? Можливо, до тих пір, поки ми не отримаємо «недовірливе» розбивання за межі консенсусу, таким ланцюгам, як SUAVE, можуть знадобитися власні алгоритми консенсусу та криптоекономічна безпека, щоб підтвердити переваги ставок і побудувати надійність блоків. Однак це означає додавання більшої кількості векторів криптоекономічної атаки, особливо якщо Rollup цінність його будівельних блоків набагато вища, ніж його власна криптоекономічна безпека.
Крім того, у ланцюгах типу SUAVE та міждомених MEV ще є багато можливостей для розробки. Ось деякі можливі напрямки досліджень:
Щодо виразу переваги, щоб взаємодіяти зі смарт-контрактом у EVM, необхідно надіслати виклик контракту (повідомлення) певній функції за адресою розгорнутого коду, що містить інструкцію виконання. Хоча користувачі надають вхідні дані, вони можуть не контролювати вихідні дані через можливу постійність.
Навпаки, системи проектування вираження переваг (такі як SUAVE та Anoma) вимагають від користувачів лише підписати переваги заставою, яка виплачується розробникам і виробникам блоків, якщо вподобання шукача виконуються. Для складної комбінаторної логіки, такої як послідовності транзакцій для шукачів і конструкторів MEV, може знадобитися реалізація різних мов і віртуальних машин. Це новий дизайнерський простір, який останнім часом привернув багато уваги, особливо архітектура Anoma. Крім того, ми настійно рекомендуємо цю коротку статтю.