Аналіз переваг та недоліків багатократних конкурентних пропозицій (MCP)

Автор: Maven11; Переклад: Золотий фінансів xiaozou

Multiple Concurrent Proposer (MCP) — це механізми, які дозволяють декільком ініціаторам бути активними одночасно (не плутати з Multi Context Protocol або Secure Multi-Party Computation MPC, але між ними є деяка схожість), і це інноваційне рішення проблеми цензури. У цій статті ми розглянемо, чому наявність декількох, а не одного ініціатора, відповідального за пропозиції блоків, є ключовим елементом у вдосконаленні дизайну механізмів блокчейну, включаючи те, як він працює та що означає впровадження.

Хоча основна концепція MCP відносно проста для розуміння, наразі майже немає реального впровадження цього механізму в блокчейні. Проте, в певному сенсі, модель роботи біткойн-майнінгових пулів має певну схожість з багатопотоковими пропозиціями – будь-хто, хто працює з повним вузлом біткойна, може дозволити, щоб транзакції були упаковані в блокчейн.

! xoZWXtWoJyweT8MeGgBugxwm51IfcxfkToqRw1dr.png

З іншого боку, механізм багатопаралельних будівельників Solana має деякі спільні риси з впровадженням повного MCP, принаймні відображаючи ідею участі кількох різних учасників у побудові блоків (але не в пропозиції блоків). На Ethereum близько 95% блоків будуються через MEV-Boost. Незважаючи на те, що існує кілька активних конструкторів одночасно, на аукціоні може бути лише один переможець, тому перевага, якої Solana досягає завдяки кільком одночасним конструкторам, тут не витримує. Фактично, в даний час не існує ланцюжка, який дозволяє кільком ініціаторам пропонувати блоки в будь-який час.

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

! UgLFVd0gPFQlFly7IsDhalymLrME44Xqp1yaA0W7.png

Ці групи пропонентів, ймовірно, будуть організовані у вигляді підкомітетів (подібно до існуючого механізму Ethereum), оскільки залучати всіх валідаторів не є реалістичним. Це також означає, що потрібно забезпечити, щоб окремі підкомітети не були монополізовані якимось пулом стейкінгу, інакше це може призвести до проблем з цензурою та змовами. Крім того, слід зазначити, що так звані домашні стейкери зазвичай мають обмежені технічні можливості — MCP значно збільшить складність системи.

Ось основні переваги MCP, які варто прийняти:

Причини підтримки множинних конкурентних пропозицій:

--Посилена стійкість до цензури (особливо важливо в умовах поточних обмежень)

--Розширення на базовому рівні протоколу, а не покладаючись на зовнішні рішення

--Дисперсія MEV (більше не визначається єдиним пропонувальником або будівельником при упаковці транзакцій)

Проблеми, які безпосередньо виникають при впровадженні MCP:

--Посилення конкуренції за порядок угод (упаковка та порядок) (можливо, призведе до появи явища PGA?)

--Імітаційні виклики, спричинені недійсними транзакціями

--Підвищення апаратних вимог

--Проблеми з доступністю даних для недійсних транзакцій

--необхідно впровадити інструменти остаточності

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

1、Переваги MCP

(1) Підвищення стійкості до цензури

Більшість сучасних блокчейнів використовують механізм детермінованої остаточності, і їх процес консенсусу покладається на одного лідера для визначення вмісту блоку (з невеликими відмінностями). Після того, як блок транслюється, більшість валідаторів досягають консенсусу та включають його в канонічний ланцюжок. Ethereum прискорює виробництво блоків за допомогою механізму підкомітету (але для досягнення консенсусу повному набору валідаторів потрібно більше часу). У структурі MCP кілька ініціаторів створюють свій власний блок і в кінцевому підсумку об'єднуються, що означає, що запис блоку переходить від одного принципала (пропонент/будівельник/репітер, ці ролі в ідеалі повинні бути відкинуті MCP) до багатоканальної моделі. Це значно ускладнює перегляд. Коли є кілька корпусів упаковки, опір цензурі системи значно посилиться.

В основі нинішнього вузького місця (зауважте, що такі команди, як Flashbots, покращують статус-кво) лежить те, що один розробник отримує права на створення блоків від одного ініціатора через аукціон, а (довірений) ретранслятор як аукціоніст ще більше посилює централізацію. Хоча основний протокол Ethereum децентралізований, існуючий процес транзакцій у ланцюжку – ні. Solana також зіткнулася з централізацією реле/будівельників Jito і намагається вирішити її за допомогою рішення для повторного стейкінгу (перший реальний стейкінг "AVS"!). ）。 Користувачі Bitcoin можуть вирішити проблему автономно (з меншими витратами), запустивши повну ноду, але це відбувається за рахунок остаточності – Bitcoin використовує імовірнісну завершеність і не має «інструментів остаточності», необхідних для впровадження MCP, який покладається на правило найдовшого ланцюга.

(2) Розширення на рівні базового протоколу

Часто багато розробок передається на аутсорсинг стороннім командам, щоб виправити недоліки дизайну L1 (не обмежуючись Ethereum) і вирішити проблеми основного протоколу. Впровадження MCP означає безпосередню роботу з проблемами, які в іншому випадку були б вирішені/викликані офчейн-рішеннями. Це збільшує вимоги до апаратного забезпечення (одночасно підвищуючи стійкість до цензури), що може бути вигідним компромісом залежно від потреби в децентралізації користувачами протоколу. Зокрема, Solana, ймовірно, використовуватиме цей підхід для вирішення проблеми централізації Jito. Крім того, оскільки зусилля з побудови блоків розподіляються між кількома сторонами, загальний попит на пропускну здатність мережі в кінцевому підсумку зросте.

(3) Дисперсія MEV

Найбільш унікальний ефект MCP полягає в тому, що він змінює оригінальну модель "MEV-лотереї", дозволяючи ділитися MEV певного блоку між кількома активними ініціаторами (а не монополізуватися одним ініціатором або розробником). Валідатори (переважно корпоративні структури) віддають перевагу стабільному потоку доходів, і цей механізм також ефективний для запобігання односторонньому використанню MEV (статус-кво) через перебудову транзакцій. Ця особливість має синергетичний ефект з метою стійкості до цензури.

Примітка: Якщо ви колись читали наші минулі статті, ви, можливо, знайомі з терміном теорія CAP: це три основні характеристики, які повинні бути виконані для нормальної роботи розподілених систем.

**C：**означає узгодженість (consistency), тобто досвід користувача повинен залишатися єдиним для всіх користувачів, і кожного разу, коли вони використовують систему, вони повинні відчувати, що взаємодіють з єдиною базою даних.

**A：**представляє доступність (availability), тобто те, що ми зазвичай називаємо активністю (liveness), вказує на те, що всі повідомлення мають бути оброблені вузлами системи і відображені в наступних блоках/запитах, всі команди повинні бути виконані.

P: розшифровується як толерантність до розділів, що означає, що система повинна зберігати стабільність і доступність, навіть коли вона зазнає атаки або мережа вузлів розділена.

MCP є одним з найкращих способів реалізації ключових елементів теореми CAP (особливо стосовно стійкості до цензури) — ці елементи часто просто зводять до проблем теорії ігор. Пам'ятайте: довіряйте самій угоді, а не теорії ігор.

Однак переваги неодмінно супроводжуються витратами, принцип роботи теореми CAP показує: великі досягнення завжди супроводжуються відповідними недоліками — майже неможливо повністю врахувати всі характеристики. Тому давайте розглянемо можливі проблеми, які можуть виникнути при впровадженні MCP.

2、Проблеми, які потрібно вирішити MCP

Основна проблема полягає в тому, що MCP певною мірою може викликати стадію подвійної конкуренції в межах блоку. По-перше, це комісія за упаковку транзакцій, по-друге, плата за сортування. Обробка плати за сортування є особливо складною, оскільки на першій стадії місцеві виробники мають лише локальний вигляд блоку, а не глобальний. Це означає, що точно обчислити оптимальну ставку для конкретної позиції в блоці є важким завданням.

! ch8ILlNsaae7gXUMsXRIibmRDzmECCY1A73W5FDF.png

Це не тільки ускладнює операції, але, що більш важливо, (в умовах аукціонної механіки) це призведе до повернення до епохи пріоритетних аукціонів Gas (PGA). Хоча забезпечується більша стійкість до цензури, в основному це відроджує проблеми, які намагався вирішити MEV-Boost — медіана високих комісій за Gas у конкурентних блоках, ексклюзивне ціноутворення на стадії упаковки та інші явища.

Окрім проблем із сортуванням, включаючи локальні та глобальні подання, існують й інші проблеми, пов'язані з транзакціями. Це стосується саме проблеми, викликаної невірними транзакціями під час поширення локально-глобального представлення блоку. Враховуючи, що неможливо передбачити вплив змін стану на транзакції інших ініціаторів на початку фази (до того, як субблоки будуть об'єднані в блоки, створені спільно декількома ініціаторами пропозиції), можуть бути випадки, коли ініціатори передають один одному невірні транзакції (проблема загострюється, якщо ці транзакції завантажуються в ланцюжок як контент доступності даних). Також може бути виявлено, що валідатор у поточному наборі MCP порушить ліміт параметрів (наприклад, порушить максимальне значення газу). Хоча це можна вирішити, запровадивши арбітр (або вбудоване правило протоколу), яке може фільтрувати транзакції за низькими цінами з тією ж зміною стану за комісією після розкриття доступності даних, це повертає нас до вирішеної дилеми PGA. Однак відсутність використання таких механізмів, як аукціони, щоб надати пошукачам/будівельникам контроль над розташуванням блоків, призведе до потоку спам-транзакцій і погіршення затримки азартних ігор – все це підірве можливість преконфісів. Ethereum (після оновлення Pectra) і Solana мають додаткові міркування: пропозиція Ethereum 7702 робить транзакції недійсними через недійсність, а Solana не має транзакції nonce (обліковий запис nonce все ще існує). Це значно ускладнює оцінку дійсності транзакції – по суті, імітація всіх комбінацій для визначення правильного порядку, що може створити величезне навантаження на пропускну здатність мережі. Solana може бути простіше впоратися з її високим апаратним бар'єром для входу, але Ethereum, безсумнівно, потребуватиме оновлення апаратного забезпечення. Однак потенційне рішення Ethereum полягає в тому, що клієнт виконання (а не розробник + ретранслятор) фактично розраховує порядок під час фази злиття підблоків, що підтверджує необхідність оновлення апаратного забезпечення.

! x7UlHJpjjdPKvjjZ3KnsdNRxm1Y0Ci2Zg34ezx9w.png

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

Як згадувалося раніше, реалізація MCP, швидше за все, вимагатиме інструментів остаточності для вирішення проблем синхронізації - саме це мається на увазі в розділі моделювання перед консенсусом упорядкування вище. Це також піднімає проблему затягування гри в час пропозиції блоків (явище, яке було помічено на аукціонах MEV-Boost), з ефектом, що ініціатори можуть дивитися на інші блоки, перш ніж створювати свої власні, і таким чином навмисно надсилати транзакції, які роблять недійсними чужі транзакції (особливо вигідно для пошукачів). Якщо правила антитайм-гри будуть занадто суворими, це призведе до ліквідації гірших валідаторів (мається на увазі більше відсутніх блоків).

Можливі рішення гри на час можуть бути запозичені з удосконалень таких ланцюгів, як Monad, в яких використовується механізм асинхронного виконання (відкладеного виконання). Наприклад, можна встановити правило: повний ефект від набору транзакцій всіх активних ініціаторів за один проміжок часу повинен чекати, поки всі набори не будуть побудовані. Це значно обмежує пропускну здатність, оскільки існує висока ймовірність того, що кілька ініціаторів міститимуть одну й ту саму транзакцію. Затримка виконання також означає, що навіть якщо транзакція «включена» в підблок, вона може не потрапити до фінального блоку злиття, що призведе до транзакції «включено, але відкочено» (повторюючи проблему подвійного включення, згадану на початку). Зауважте, що для виконання таких операцій можуть знадобитися специфічні інструменти доопрацювання (включаючи виконання, поширення та доопрацювання блоків).

! Idvyka85De1Y0RFlDGYtAavBV04lPdP3OkgpJ9zA.png

Хоча ми головним чином зосереджені на Ethereum, варто зазначити, що Solana активно просуває MCP. З приходом Макса Резника до Anza та публічною підтримкою реалізації від Анатолія, ця тенденція стає дедалі більш очевидною. У нещодавній статті Анатолія згадуються такі ключові питання:

--Що робити, якщо блоки з різних валідаторів приходять у різний час (це також може бути битва зі часом)

--Як об'єднати угоди (як вже обговорювалося раніше)

--Як розподілити обсяг блоків (максимальний ліміт Gas) між валідаторами для максимізації пропускної здатності

--Проблема витрачання ресурсів (однакові транзакції включаються в кілька підблоків, ця проблема також була згадана раніше)

Багато проблем, пов'язаних із впровадженням MCP на Solana, зазвичай відгукуються на питання, з якими стикається Ethereum. Проте Solana більше зосереджена на пропускній здатності та оптимізації продуктивності, що означає, що управління ресурсами блоків та об'єднання блоків стають ще більш важливими під час забезпечення стабільності консенсусу.

Інший ключовий момент, згаданий на початку статті: MCP не тільки може зміцнити протокол, а й використовуватися для розширення протоколу. Він навіть може включати спеціалізовану серіалізацію додатків (ASS) на рівень протоколу за допомогою механізму сортування. У майбутньому може виникнути така ситуація: пропонувальник більше не є XYZ-транзакції, а самим додатком, яке буде пропонувати, відповідно до своїх потреб, сортувати набір транзакцій (саме в цьому напрямку працює проект Delta) — або навпаки, додаток надає пропонувальнику правила сортування транзакцій. Варто зазначити, що також досліджується варіант перенесення податку MEV на сторону додатка (ініціатора транзакції) у поєднанні з MCP (оскільки контроль над пакуванням більше не здійснюється єдиним пропонувальником, реалізація буде простішою).

У нещодавній публікації Макс і Анатолій стверджували, що MCP може досягти вужчого спреду бід-аск, застосовуючи виділену серіалізацію (децентралізована концепція NASDAQ). У нинішніх умовах, як говорилося раніше, блоки може пропонувати тільки один лідер. Це означає, що при коливаннях ціни сторона котирування в книзі ордерів буде намагатися розвернути певні котирування. Згідно з моделлю єдиного ініціатора Solana, це можна зробити лише через аукціони Jito через монополію ініціатора на владу. В ідеалі, як показує Hyperliquid, запити на зворотні платежі повинні бути пріоритетними, щоб дозволити маркет-мейкерам підтримувати більш вузькі спреди. Тому є надія, що це буде досягнуто через АСС як додаток - у них монополія на аукціонну владу за моделлю єдиного лідера, і цю монополію можна ліквідувати шляхом прийняття ГДК. Однак це рішення ASS, швидше за все, буде обмежене сценаріями ізоляції держави. Суть пропозиції полягає в тому, щоб дозволити розробникам додатків визначати пріоритетні дії (наприклад, скасування замовлень) для конкретних облікових записів і віддавати перевагу транзакціям з найвищим пріоритетом (не обов'язково транзакціям з найвищим рівнем чайових, але життєвою силою ліквідності) для конкретних облікових записів. Основна ідея полягає в тому, щоб встановити поріг комісії для регулярних угод, дозволяючи при цьому певним пріоритетним угодам подолати ліміт.

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

! iYPNZnNzqp5tf0XoZCz0g88JRxA3c57RpBWm2aOw.png

Вказаний механізм тісно співпрацює з механізмом поширення блоків Solana, Turbine. Лідери (MCP) використовують фрагменти даних (shreds), які надсилаються до проміжних вузлів у деревоподібній структурі Turbine — ці проміжні вузли повинні містити фрагменти від усіх лідерів. Проміжні вузли надсилають підтвердження фрагментів одному єдиному лідеру консенсусу, який повинен зібрати достатню кількість фрагментів повідомлень, щоб провести трансляцію та досягти консенсусу.

З виходом Alpenglow, враховуючи скасування однорівневої архітектури релейних вузлів та механізму голосування на ланцюгу (тепер повністю на ланцюзі), конкретна реалізація може зазнати змін. Ці зміни можуть знизити витрати на експлуатацію валідаторів, що в свою чергу збільшить їхню кількість і залучить учасників з меншою технічною спроможністю. Це, безумовно, корисно для децентралізації, але може вплинути на продуктивність ланцюга. Варто обговорити, як вони впораються з проблемою збоїв валідаторів після впровадження MCP у Solana.

**3、**Інші практики MCP в екосистемах

Екосистема Cosmos також просуває впровадження MCP, відома організація Informal Systems щойно випустила специфікацію з кількома пропозиціями в рамках моделі BFT консенсусу. Вони використовують безпечний протокол широкомасштабної трансляції, вимагаючи, щоб кожен субблок валідатора отримав підтвердження від інших валідаторів через механізм голосування. Модуль побудови блоків Tendermint/CometBFT потім досягає консенсусу щодо цих наборів субблоків, що означає, що конкретний валідатор генерує велику кількість субблоків.

Sei активно розробляє MCP (намагаючись стати першим реалізованим проектом) через проект Sei Giga, частина дизайнерського натхнення якого походить з статті Autobahn (рекомендується до прочитання). Основна ідея полягає в розділенні доступності даних і сортування, прискорюючи доступність даних через кілька паралельних каналів, а потім сортування до глобального ланцюга. Це трохи відрізняється від концепції MCP в Ethereum — валідатори не синхронізують створення блоків у фіксовані проміжки часу, а постійно виробляють блоки, які потім об'єднуються у глобальний вигляд.

Патрік О'Грейді з Commonware також досліджує відповідні рішення.

Нарешті, проект Delta спроектував основний рівень, який має функцію антикорупційної дошки оголошень, при цьому кожен додаток працює зі своїм власним конкурентним сортувальником, а згенеровані блоки врешті-решт підсумовуються до глобального рівня стану.