Игра между соглашением Ethereum и MEV началась с дня, когда Ethereum перешел с PoW на PoS...

Написал: Tia, Techub News

Процесс решения проблемы MEV фактически заключается в пересмотре правил распределения Блок-пространства. MEV, вероятно, уже не так незнаком, но если вы хотите узнать, о чем именно говорят предложения по управлению MEV в сети Ethereum, вам возможно понадобится дополнительная информация о контексте, поэтому в этой статье представлен обзор ряда предложений по управлению MEV после перехода Ethereum к PoS, таких как PBS, ePBS, PEPC, с надеждой предоставить вам некоторую контекстную информацию.

PBS(Proposer Builder Seperatioin)

До слияния ETH, решение MEV осуществлялось через использование MEV-Geth, разработанного Flashbots - модифицированного клиента go-ethereum. Его основная идея заключается в том, чтобы Майнеры сосредоточились на своей основной работе - майнинге, а не участвовали в борьбе за MEV, чтобы избежать возможных проблем с потенциальной реконструкцией. Механизм MEV-Geth очень прост: это рыночное решение, при котором Майнеры могут выбирать пакеты при формировании блока в зависимости от прибыли, полученной от поисковика. Через этот изощренный рыночный механизм стороны получают выгоду, одновременно создавая определенные ограничения. Хотя поисковику приходится отдавать часть прибыли Майнеру, он получает гарантию безопасности от кражи Майнером. Когда основной источник прибыли - поисковик - становится закрытым, Майнеры также вынуждены использовать MEV-Geth и подчиняться его механизму. MEV-Geth поддерживает Разрешенный список Майнеров, и только Майнеры, находящиеся в этом списке, могут получать пакеты от поисковика. Путем ограничения репутации Майнеров, исключая из Разрешенного списка тех, кто крадет результаты поисковика, можно предотвратить грабеж MEV-прибыли поисковика Майнерами.

Однако после слияния, так как способ создания Блоков изменяется на выбор proposer из валидаторы случайным образом, невозможно использовать метод ограничения доверия для предотвращения захвата MEV proposer.

Возможным решением является сделать содержимое блока невидимым для валидаторов. Вдоль этой линии дальнейшее улучшение - это PBS (Proposer Builder Separation, разделение предложителя и строителя). PBS разделяет обязанности предложителя валидаторов на строительство блока и предложение блока, передавая сложное право на строительство, которое может участвовать в конфликте интересов, строителю. Таким образом, работа предложителя становится очень простой, ему нужно только выбирать предложение блока в соответствии с прибылью, представленной строителем.

Изначально Ethereum планировал внедрить PBS в протокол при merge, но из-за потенциальной сложности этот процесс был отложен, что дало возможность MEV-Boost войти в PBS. В настоящее время PBS реализуется через MEV-Boost, разработанный Flashbots. Кроме builder и proposer, есть еще одна важная роль - relay. Builder не отправляет блок напрямую proposer, а через третью роль - relay.

Есть и другие вопросы, которые необходимо решить, например, как гарантировать, что застройщик заплатит автору предложения и что содержание блока будет раскрыто автору предложения в конце, чтобы автор предложения не был наказан за отправку пустого блока; Например, как сделать так, чтобы блоки, представленные строителем, были включены в цепочку маяков. Эти вопросы защиты прав и интересов строителей и заказчиков в основном реализуются через эстафеты.

builder отправит Блок relay, затем relay отсортирует Блоки в соответствии с прибылью, которую может получить каждый Блок, и затем отправит proposer заголовок Блока с наибольшей прибылью, чтобы гарантировать, что proposer не видит содержимое Блока. Только после того, как proposer даст обещание о предложении Блока (подписав заголовок Блока), relay раскроет полный Блок proposer. Чтобы обеспечить оплату, которую builder выплачивает proposer, также необходимо вмешательство relay. Транзакция, выплаченная proposer, включается в представленный Блок, но так как proposer не может видеть содержимое Блока, relay все равно должен предварительно подтвердить.

В протоколе и вне протокола

Чтобы участвовать в рынке, построенном на MEV-Boost, валидаторы должны запускать клиенты Ethereum и выполнение клиентов одновременно со сторонней программой MEV-Boost, не относящейся к Ethereum. Вот где проявляется волшебство PBS, которое позволяет сторонним участникам принимать участие в проектировании правил, сформированных в рамках протокола Ethereum. С точки зрения собственности, это непостижимо.

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

Централизованный реле

Наиболее критикованной особенностью MEV-Boost является централизованный рынок реле. Однако такая настройка вносит проблему доверия. Строители должны доверять, что реле не похитит их MEV. Заявитель также должен доверять, что полученные ими от реле и подписанные заголовки блока являются действительными. Тем не менее, несмотря на свою важную роль, реле не имеет никаких экономических стимулов, и его работа требует значительных затрат. В прошлом году 11 реле поддерживали сеть Ethereum, однако сейчас только 9 из них остаются в работе.

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

Данные от Rated Network

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

ePBS: упаковка PBS в Ethereum

Будь то для решения проблем децентрализации ретрансляции или для перемещения части Протокола внутрь Протокола, упаковка PBS в ePBS ETH блокчейна, кажется, становится обязательной. В настоящее время ePBS больше не является предметом обсуждения, и ему уже назначен номер в редакции EIP ETH - EIP-7732.

ePBS предоставляет инфраструктуру без доверия для proposer и builder, чтобы они могли выполнить аутсорсинг построения Блок. Роль builder, которая изначально была вне Протокола, теперь включена в Протокол, то есть валидаторы разделяют роль builder, а builder валидаторов также должен застейкать в ETH. Поскольку обязанности proposer в слое Соглашения были разделены, для завершения ePBS необходимо внести изменения в слой Соглашения. В частности, builder ответственен за создание нагрузки ution (окончательный список транзакций, которые будут выполнены в этом Блоке), а обязанности proposer заключаются в предложении маяка Блока. Конкретный процесс следующий:

1. После того как было решено, что вы станете Предложителем, необходимо создать и передать список включаемых транзакций (IL), то есть тех транзакций, которые обязательно должны быть включены в этот слот.
2. builder отправляют proposer содержащий хешБлока и обещание оплатить proposer за выполнение payload “SignedutionPayloadHeader” (payload должен удовлетворять IL)
3. заявитель выбирает один из ‘SignedutionPayloadHeader’, полученных от ‘builders’, и включает его (обычно выбирается тот, который предлагает наивысшую цену заявителю). Затем транслируется предложение о блоке-маяке ‘SignedBeaconBlock’.
4. Свидетель выполняет свои обязанности по свидетельству
5. агрегаторы представляют агрегаты утверждений; в то же время строитель широковещает ution payload
6. Комитет по своевременности передачи нагрузки (Payload Timeliness Committee, в каждом слоте выбирается 512 валидаторов в качестве членов PTC) проверяет, быстро ли билдер раскрывает платежную нагрузку и транслирует результаты.

ePBS в процессе получения номера EIP от начала до конца также прошёл несколько обсуждений. Изначально PBS была предложена Виталиком в июне 21 года, через 4 месяца была усовершенствована схема Two-slot, ещё через 3 месяца была представлена Single-slot PBS, и только в июле 23 года была официально предложена идея PTC.

PEPC (Протокол-обязательные обязательства предложителей)

Конечно, есть и те, кто не согласен с ePBS и хочет заменить его другими вариантами. Вот где появляется PEPC. Если ePBS встраивает определенное правило в Протокол, то здесь proposer продает право на построение Программируемость Блоков.

PEPC был предложен barnabe в октябре 2022 года. barnabe считает, что если нужно внедрить механизм PBS в Протокол, то следует рассмотреть создание универсального механизма для достоверной передачи сигналов, а не механизма для конкретного достоверного сигнала (например, если попросить меня построить Блок, я верну тебе xx ETH).

Как и в случае с PEPC (Protocol-Enforced Proposer Commitments), некоторые механизмы, обеспечивающие интересы builder и proposer, осуществляются через представление proposer внутри Протокола, которое называется commitment. Эти commitments могут быть проверены в блокчейне и реализуются основным кодом операции «BEACONROOT». Это более общий механизм, в котором commitment может представлять собой полное аутсорсинг конструирования Блоков или только части Блоков, то есть proposer продает программную возможность конструирования Блоков.

Заключение

Выше приведено краткое описание PBS, ePBS и PEPC. С точки зрения проектирования протокола, необходимо не только разработать механизм рынка для перераспределения MEV, но и обеспечить большую децентрализацию валидаторов и повысить устойчивость к цензуре. Кроме того, в проектировании протокола существует много компромиссов. Например, рассмотрим ePBS с уже полученным номером EIP. Хотя дизайн ePBS решает проблему централизованного ретранслятора, действительно ли только негативное влияние у этой критической роли стороннего ретранслятора вне протокола? С точки зрения механизма оплаты builder, использование ретранслятора на самом деле предпочтительнее, поскольку ePBS является предоплатной системой. Если builder упаковывает блок с очень высокой прибылью, то в предоплатной системе невозможно предложить высокую отдачу proposer.