Анализ преимуществ и недостатков многократных предложений (MCP)

Автор: Maven11; Перевод: Золотая экономика xiaozou

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

Хотя основная концепция MCP относительно проста для понимания, в настоящее время практически нет блокчейнов, которые фактически используют этот механизм. Тем не менее, в определенной степени модель работы биткойн-майнинг-пулов имеет сходство с множественными параллельными предложениями — любой, кто запускает полный узел биткойна, может сделать так, чтобы транзакция была упакована в блок.

! xoZWXtWoJyweT8MeGgBugxwm51IfcxfkToqRw1dr.png

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

Понять MCP наиболее наглядно можно, разобрав его на два уровня: несколько предложителей одновременно предоставляют блоки, а также окончательное объединение этих субблоков.

! UgLFVd0gPFQlFly7IsDhalymLrME44Xqp1yaA0W7.png

Эти группы предлагающих, скорее всего, будут подсоветами (подобно существующим механизмам Ethereum), поскольку нецелесообразно привлекать всех валидаторов. Это также означает, что важно следить за тем, чтобы отдельные подкомитеты не были монополизированы стейкинг-пулом, в противном случае могут возникнуть проблемы с цензурой и сговором. Кроме того, важно отметить, что легендарные хоумстейкеры часто имеют ограниченные технические возможности – МКП значительно увеличит сложность системы.

Вот основные преимущества MCP, которые стоит принять во внимание:

Причины поддержки множества параллельных предложителей:

--Увеличение устойчивости к цензуре (особенно важно в текущих условиях узкого места)

--Расширение на уровне базового протокола, а не зависимость от внешних решений

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

Проблемы, которые будут напрямую раскрыты внедрением MCP:

--Усиление конкуренции за сортировку сделок (упаковка и порядок) (может привести к возникновению явления PGA?)

--Моделируемые вызовы, возникающие из недействительных сделок

--Повышение требований к оборудованию

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

--необходимо ввести инструменты окончательности

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

1. Преимущества MCP

(1) Увеличение устойчивости к цензуре

Большинство современных блокчейнов используют детерминированный механизм окончательности, и их процесс консенсуса опирается на одного лидера для определения содержимого блока (с небольшими отличиями). После трансляции блока большинство валидаторов достигают консенсуса и встраивают его в каноническую цепочку. Ethereum ускоряет производство блоков с помощью механизма подкомитета (но для достижения консенсуса всем набором валидаторов требуется больше времени). В рамках MCP несколько инициаторов создают каждый свой собственный блок и в конечном итоге объединяются, что означает, что запись блока переходит от одного участника (предлагающий/создающий/повторяющий, эти роли в идеале должны быть отброшены MCP) к многоканальной модели. Это значительно усложняет его проверку. При наличии нескольких корпусов упаковки устойчивость системы к цензуре будет значительно повышена.

В основе текущего узкого места (обратите внимание, что такие команды, как Flashbots, улучшают статус-кво) лежит то, что один строитель получает права на строительство блоков от одного предлагающего через аукцион, а (доверенный) ретранслятор в качестве аукциониста еще больше усугубляет централизацию. В то время как основной протокол Ethereum децентрализован, существующий процесс транзакций в цепочке — нет. Solana также сталкивается с проблемой централизации ретрансляторов/строителей Jito и пытается решить эту проблему с помощью решения для повторного стейкинга (первого рестейкинга с реальной доходностью «AVS»!). ）。 Пользователи Биткойна могут решить проблему автономно (с меньшими затратами), запустив полный узел, но это происходит за счет окончательности — Биткойн использует вероятностную финальность и не имеет «инструментов финальности», необходимых для реализации MCP, которая опирается на правило самой длинной цепочки.

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

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

(3) Распределенный MEV

Наиболее уникальным эффектом MCP является то, что он изменяет исходную модель «лотереи MEV», позволяя делить MEV определенного блока между несколькими активными предлагающими (а не монополизированными одним предлагающим или строителем). Валидаторы (в основном юридические лица) предпочитают стабильный поток доходов, и этот механизм также эффективен для предотвращения односторонней эксплуатации MEV (статус-кво) путем переорганизации транзакций. Эта функция имеет синергетический эффект с целью, устойчивой к цензуре.

Примечание: если вы когда-либо читали наши предыдущие статьи, вы можете быть знакомы с термином теорема CAP: это три основные характеристики, которые должны быть соблюдены для нормальной работы распределенной системы.

C： представляет собой согласованность (consistency), что означает, что пользовательский опыт должен оставаться единым для всех пользователей, и каждый раз, когда вы используете систему, вы должны чувствовать, что взаимодействуете с единой базой данных.

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

**P：**представляет собой отказоустойчивость разделов (partition tolerance, или устойчивость к цензуре), что означает, что система должна сохранять согласованность и доступность даже в условиях атак или разделения сети узлов.

MCP является одним из лучших способов реализации ключевых элементов теоремы CAP (особенно устойчивости к цензуре) — эти элементы обычно просто сводятся к проблемам теории игр. Помните: доверяйте самому протоколу, а не теории игр.

Тем не менее, преимущества неизбежно сопровождаются затратами. Законы работы теоремы CAP показывают, что великие достижения всегда сопровождаются соответствующими недостатками — практически невозможно полностью учесть все характеристики. Поэтому давайте рассмотрим возможные проблемы, которые могут возникнуть при реализации MCP.

2. Проблемы, которые необходимо решить для MCP

Основная проблема заключается в том, что MCP в определенной степени вызывает фазу двойного конкурирования внутри блока. Сначала это сборы за упаковку транзакций, затем сборы за сортировку. Обработка сборов за сортировку особенно сложна, поскольку на первом этапе местные производители имеют только локальное представление о блоке, а не глобальное. Это означает, что точно рассчитать оптимальную ставку для конкретного местоположения в блоке — это сложная задача.

! ch8ILlNsaae7gXUMsXRIibmRDzmECCY1A73W5FDF.png

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

Помимо проблем сортировки, в том числе локальных и глобальных, существуют и другие проблемы, связанные с транзакциями. Речь идет конкретно о проблеме, вызванной недействительными транзакциями во время распространения локально-глобального представления блока. Учитывая, что невозможно предсказать влияние изменения состояния на транзакции другого предлагающего в начале фазы (до того, как подблоки будут объединены в совместно построенные блоки нескольких предлагающих), возможны случаи, когда предлагающие передают друг другу недействительные транзакции (проблема усугубляется, если эти транзакции загружаются в цепочку в виде содержимого доступности данных). Также возможно, что валидатор в текущем наборе MCP нарушит ограничение параметров (например, нарушит максимальное значение газа). Хотя эту проблему можно решить, введя арбитра (или встроенное правило протокола), который может фильтровать недорогие транзакции с одним и тем же изменением состояния по комиссии после раскрытия доступности данных, это возвращает нас к решенной дилемме PGA. Тем не менее, если вообще не использовать такие механизмы, как аукционы, чтобы дать поисковикам/строителям контроль над расположением блоков, это приведет к потоку спам-транзакций и ухудшению задержки азартных игр — все это подорвет возможность предварительных транзакций. Ethereum (после обновления Pectra) и Solana имеют дополнительные соображения: предложение Ethereum 7702 больше не делает транзакции недействительными из-за одноразовых номеров, а Solana не имеет одноразового номера транзакций (одноразовый номер учетной записи все еще существует). Это значительно усложняет оценку действительности транзакции — по сути, моделирование всех комбинаций для определения правильного порядка, что может создать огромную нагрузку на пропускную способность сети. Solana может быть проще в обращении с ее высоким аппаратным барьером для входа, но Ethereum, несомненно, будет нуждаться в обновлении оборудования. Тем не менее, потенциальное решение Ethereum заключается в том, чтобы исполняющий клиент (а не сборщик + повторитель) фактически рассчитывал порядок во время фазы слияния подблоков, что подтверждает необходимость обновления оборудования.

! x7UlHJpjjdPKvjjZ3KnsdNRxm1Y0Ci2Zg34ezx9w.png

Что касается доступности данных (DA), как уже упоминалось, еще одной важной проблемой является то, что эти недействительные транзакции могут быть раскрыты в блокчейне (фактически становясь бесплатными транзакциями). Это еще больше усугубляет нагрузку на имитационные вычисления, упомянутую на этапе консенсуса — хотя вы можете отфильтровывать недействительные транзакции на этапе объединения. Некоторые существующие реализации FOCIL (адрес отправителя, а не полная транзакция) могут быть повторно использованы (если не полагаться полностью на имитационную проверку, но если вмешательство человека происходит, а не по правилам протокола, это может нарушить имитационный процесс, сделав другие транзакции недействительными).

Как упоминалось ранее, реализация MCP, скорее всего, потребует инструментов окончательности для решения проблем синхронизации - именно это подразумевается в разделе о моделировании предварительного согласованного порядка выше. Это также поднимает проблему задержки игры во времени предложений блоков (явление, которое наблюдалось в аукционах MEV-Boost), в результате чего предлагающие могут посмотреть на другие блоки, прежде чем построить свой собственный, и таким образом намеренно отправлять транзакции, которые аннулируют чужие транзакции (особенно выгодно для тех, кто ищет блоки). Если правила игры против времени будут слишком строгими, это приведет к отсеиванию более слабых валидаторов (то есть большего количества недостающих блоков).

Возможные решения игры на время можно позаимствовать из усовершенствований таких цепочек, как Monad, которые используют механизм асинхронного выполнения (отложенного выполнения). Например, можно задать правило: полный эффект от набора транзакций всех активных предлагающих за один период времени должен подождать, пока не будут построены все наборы. Это существенно ограничивает пропускную способность, так как существует высокая вероятность того, что несколько предлагающих будут содержать одну и ту же транзакцию. Задержка выполнения также означает, что даже если транзакция «включена» в подблок, она может не попасть в окончательный блок слияния, что приведет к транзакции «включено, но откат» (перекликаясь с проблемой двойного включения, упомянутой в начале). Обратите внимание, что для выполнения таких операций могут потребоваться специальные инструменты финальности (включая выполнение, распространение и финализацию блоков).

! Idvyka85De1Y0RFlDGYtAavBV04lPdP3OkgpJ9zA.png

Хотя мы в основном сосредоточены на Ethereum, стоит отметить, что Solana активно продвигает MCP. С приходом Max Resnick в Anza и открытой поддержкой Anatoly реализации, эта тенденция становится все более очевидной. В недавней статье Anatoly упомянул следующие ключевые моменты:

--Что делать, если блоки из разных валидаторов приходят в разное время (это также может быть временная игра)

--Как объединить сделки (об этом уже говорилось выше)

--Как распределить емкость блока (максимальный лимит Gas) между валидаторами для максимизации пропускной способности

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

Многие проблемы, связанные с реализацией MCP на Solana, обычно перекликаются с проблемами, с которыми сталкивается Ethereum. Однако Solana больше сосредоточена на пропускной способности и оптимизации производительности, что означает, что управление ресурсами блоков и объединение блоков становятся более важными при обеспечении устойчивости консенсуса.

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

В недавнем посте Макс и Анатолий утверждали, что MCP может достичь более узких спредов между спросом и предложением, применив специальную сериализацию (децентрализованную концепцию NASDAQ). В текущих условиях, как упоминалось ранее, только один лидер может предлагать блоки. Это означает, что при колебаниях цены котирующая сторона в книге ордеров будет пытаться перевернуть определенные котировки. В соответствии с моделью Solana с одним предлагающим, это может быть сделано только через аукционы Jito из-за монополии предлагающего на власть. В идеале, как показывает Hyperliquid, запросы на возвратные платежи должны быть приоритетными, чтобы маркет-мейкеры могли поддерживать более узкие спреды. Поэтому есть надежда, что это будет достигнуто с помощью ASS в качестве приложения - у них есть монополия на аукционные мощности по модели единого лидера, и эта монополия может быть устранена путем принятия MPC. Однако это решение ASS, скорее всего, будет ограничено сценариями изоляции состояния. Суть предложения заключается в том, чтобы позволить разработчикам приложений определять приоритетные действия (например, отмену заказов) для конкретных учетных записей и отдавать приоритет транзакциям с наивысшим приоритетом (не обязательно транзакциям с самыми высокими чаевыми, но жизненной силе ликвидности) для конкретных учетных записей. Основная идея заключается в том, чтобы установить порог комиссии для обычных сделок, позволяя при этом определенным приоритетным сделкам пробивать лимит.

Обсуждавшиеся ранее проблемы с комиссиями за упаковку и сортировку, похоже, уже имеют решение в Solana. Комиссия за упаковку поступает к валидатору транзакций, тогда как комиссия за сортировку выплачивается протоколу (уничтожается). При объединении нескольких подсетей необходимо просто отсортировать и выполнить объединенный набор транзакций по заранее установленной комиссии за сортировку.

! iYPNZnNzqp5tf0XoZCz0g88JRxA3c57RpBWm2aOw.png

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

С выходом Alpenglow реализация может быть скорректирована с учетом отказа от одноуровневой архитектуры релейных узлов и механизма голосования в цепочке (теперь полностью ончейн). Ожидается, что эти изменения снизят операционные расходы валидаторов, тем самым увеличив количество валидаторов и привлекая менее технически мощных игроков. Хотя это выгодно для децентрализации, это может повлиять на производительность цепочки. Стоит изучить, как они будут реагировать на сбои валидатора после того, как Solana внедрит MCP.

**3、**Практика MCP в других экосистемах

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

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

Патрик О'Грэйди из Commonware также исследует соответствующие решения.

В конце концов, проект Delta разработал основной слой, который сочетает в себе функции антикоррупционного информационного стенда, при этом каждое приложение запускает свой собственный параллельный сортировщик, а сгенерированные блоки в конечном итоге сводятся к глобальному уровню состояния.