Автор: Тиа, Techub News
Процесс решения проблемы MEV фактически заключается в переформулировании правил распределения блочного пространства. Я считаю, что все уже знакомы с MEV, но если вы хотите знать, о чем говорят некоторые предложения по управлению Ethereum MEV, вам все равно придется дополнить некоторую справочную информацию. Поэтому в этой статье мы разобрались с рядом вопросов об управлении. MEV с тех пор, как Ethereum перешел на PoS, такие как PBS, ePBS и PEPC, я надеюсь предоставить вам некоторую справочную информацию.
PBS (разделение разработчиков предложений)
До слияния Ethereum для решения проблемы MEV использовалось MEV-Geth, разработанное Flashbots. MEV-Geth — это модифицированный клиент Go-Ethereum. Основная идея состоит в том, чтобы позволить майнерам сосредоточиться на своей работе — добыче полезных ископаемых, а не участвовать в соревнованиях MEV, тем самым избегая потенциальных проблем реструктуризации, которые могут возникнуть. Механизм MEV-Geth очень прост. Это рыночно-ориентированное решение, то есть, когда майнеры упаковывают блоки, они могут выбирать в зависимости от размера прибыли от пакета, представленного искателем. Благодаря этому изобретательному рыночному механизму все стороны могут получить выгоды, одновременно создавая определенные ограничения. Хотя поисковику необходимо делиться частью прибыли с майнерами, взамен он получает более надежную гарантию от кражи майнерами. Когда поисковик, основной источник прибыли, окажется в ловушке, майнеры также начнут пассивно использовать MEV-Geth и будут дополнительно ограничены механизмом MEV-Geth. MEV-Geth будет поддерживать белый список майнеров, и только майнеры из белого списка могут получить пакет искателя. Налагая ограничения на репутацию майнеров и удаляя майнеров, которые крадут результаты поисковика, из белого списка, можно предотвратить кражу майнерами прибыли MEV поисковика.
Однако после слияния, поскольку метод генерации блока изменился на случайный выбор предлагающего из числа валидаторов для предложения блока, метод ограничения репутации больше не позволяет предотвратить перехват MEV предлагающим.
Возможное решение — сделать содержимое блока невидимым для валидаторов. Дальнейшим усовершенствованием в этом направлении является PBS (Proposer Builder Seperatioin, Proposer Builder Seperatioin). PBS далее разбивает обязанности проверяющего лица на строительство блоков и предложения блоков, а также передает застройщику комплексные права на строительство, которые могут включать конкуренцию за интересы. Таким образом, работа заявителя становится очень простой, и остается только предлагать блоки. на основе размера прибыли блока, представленного застройщиком.
Изначально Ethereum хотел встроить PBS в протокол во время слияния, но из-за потенциальной сложности этот процесс был отложен, что дало MEV-Boost возможность вмешаться в PBS. В настоящее время PBS реализуется через MEV-Boost, разработанный Flashbots. Помимо строителя и предлагающего, есть еще очень важная роль – ретранслятор. Разработчик отправляет блоки не напрямую предлагающему, а через ретранслятор третьей роли.
![](https://img.cointime.com/builder/bEwnKiDxITm8Qu70097hUroqgy67Ne1UFszXNIfv.png)
Потому что есть и другие проблемы, которые необходимо решить, например, как гарантировать, что разработчик заплатит предлагающему и раскроет содержание блока предлагающему в конце, чтобы избежать наказания предлагающего за отправку пустого блока; например, как гарантировать, что территория, представленная блоками-застройщиками, обязательно будет включена в цепочку маяков и т. д. Данные вопросы защиты прав и интересов застройщиков и заявителей реализуются в основном через ретрансляцию.
Строитель отправит блоки на ретранслятор, а затем ретранслятор отсортирует блоки в соответствии с прибылью, которую можно получить от каждого блока, а затем отправит заголовок блока с наибольшей прибылью предлагающему, чтобы гарантировать, что предлагающий не видимый для содержимого блока. После того, как предлагающий фиксирует предложение блока (подписывает заголовок блока), ретранслятор раскрывает предлагающему полный блок. Плата, выплачиваемая застройщиком предлагающему, также требует помощи реле для обеспечения завершения. Транзакция, выплаченная предлагающему, включается в отправленный блок, но, поскольку предлагающий не может видеть содержимое блока, ее все равно необходимо заранее подтвердить ретранслятором.
![](https://img.cointime.com/builder/gtDUBbbseeqbrZkp0L0Cpsyr812Qi2laV4BNvEWE.png)
В протоколе и протоколе выхода
Чтобы участвовать в рынке, созданном MEV-Boost, валидаторам необходимо запустить стороннюю программу MEV-Boost, не относящуюся к Ethereum, одновременно запуская клиент консенсуса Ethereum и клиент исполнения. В этом заключается магия работающего в настоящее время PBS, который позволяет третьим сторонам за пределами протокола участвовать в разработке правил формирования консенсуса в Ethereum. С точки зрения владения это невероятно.
Это также заставило задуматься о «достоверности» механизма протокола, о том, как доверие укрепляется и как оно подрывается другими механизмами. MEV-Boost — хороший пример, поскольку могут возникнуть ситуации, когда внешние протоколы вносят изменения в существующие механизмы. Когда сам протокол начинает отставать, такие изменения могут начать прорастать извне. Возникновение внешних механизмов должно отвечать текущему рыночному спросу, но является ли внешний механизм надежным и тщательно ли он предназначен для предотвращения появления потенциала. проблемы, и даже внешние механизмы, которые могут подорвать соглашение, пока неизвестны.
Централизованное реле
Наиболее критикуемым аспектом MEV-Boost является централизованный рынок реле. Но эта установка создает проблемы с доверием. Строители должны быть уверены, что реле не украдет их MEV. Предлагающие также должны быть уверены в том, что заголовки блоков, которые они получают и подписывают от ретранслятора, действительны. Однако, несмотря на их жизненно важную роль, для реле не существует финансового стимула, а их эксплуатация требует значительных затрат. В прошлом году сеть Ethereum поддерживали 11 ретрансляторов , но сегодня только 9 ретрансляторов по-прежнему предоставляют услуги.
Стоит отметить, что реле не требуют доступа, такие как Eden, только ретранслируют свои собственные строители . Существуют также ретрансляторы, такие как bloXroute, которые утверждают, что отфильтровывают транзакции, связанные с фронтальными и сэндвич-атаками. В некоторой степени реле также имеет определенные права по установлению правил.
![](https://img.cointime.com/builder/QxnGAp9lYiUbUaPT62TKLwmWtMaTWO8YBd3VivvC.png)
![](https://img.cointime.com/builder/tFI6htMW9XaDwwaUZofMky95XCTe1h9Ert7M8Hp3.png)
Данные поступают из рейтинговой сети.
Более того, с точки зрения живости, из-за существования ретранслятора между строителем и предлагающим нет подтверждения на атомарном уровне. Если предлагающий подписывает обязательство по заголовку блока, а сборщик также предоставляет полезный контент, но не может отправить контент вовремя из-за ошибок ретрансляции (злонамеренных или незлонамеренных), как строитель, так и предлагающий понесут убытки. .
ePBS: инкапсуляция PBS в Ethereum
Будь то решение проблемы централизации ретрансляции или перемещение частей за пределы протокола в протокол, инкапсуляция PBS в ePBS Ethereum, похоже, стала необходимостью. В настоящее время ePBS больше не является обсуждаемым предложением, и редактор EIP Ethereum присвоил ему номер — EIP-7732 .
ePBS предоставляет не требующую доверия инфраструктуру для предлагающих и строителей, позволяющую передавать на аутсорсинг права на строительство блоков. Роль строителя, которая изначально была вне протокола, была включена в протокол, то есть еще одна роль строителя разделена между валидаторами. Строителю как валидатору также необходимо выполнить залог в Ethereum. Поскольку обязанности первоначального инициатора уровня консенсуса были разделены, завершение ePBS требует внесения изменений в уровень консенсуса. Среди них строитель отвечает за создание полезной нагрузки выполнения (окончательного списка транзакций, которые должны быть выполнены в блоке). Ответственность предлагающего заключается в предложении блоков маяков. Конкретный процесс заключается в следующем:
- Узнав, что он выбран в качестве Предлагающего, составьте и транслируйте Список включений (IL, то есть транзакции, которые необходимо включить в слот).
- Разработчики отправляют хэш блока, содержащий полезные данные выполнения и обязательство «SignedExecutionPayloadHeader», которое готово заплатить предлагающему (полезные данные выполнения должны соответствовать IL).
- Предлагающий выбирает один из «SignedExecutionPayloadHeader», отправленных разработчиками, чтобы включить его (обычно тот, у которого самая высокая цена, уплаченная предлагающему). И транслируйте предложенный блок маяка «SignedBeaconBlock».
- Свидетели выполняют свидетельские обязанности
- Агрегаторы отправляют агрегаты аттестации, в то же время сборщик передает полезную нагрузку выполнения;
- PTC (Комитет по своевременности полезной нагрузки, в каждом слоте в качестве членов PTC будут выбраны 512 валидаторов) проверяет, вовремя ли билдер раскрывает полезную нагрузку выполнения и транслирует результат
ePBS также прошел через множество обсуждений с момента его предложения до окончательного получения номера EIP. Первоначально PBS был предложен Виталиком 21 июня , а 4 месяца спустя двухслотовое решение было улучшено. Еще через 3 месяца была запущена однослотовая PBS . И только 23 июля идея PTC была официально предложена. .
PEPC (Обязательства предлагающего, предусмотренные протоколом)
Конечно, есть и те, кто не согласен с ePBS и надеется использовать вместо него другие решения. PEPC такой. ePBS встраивает в протокол определенное правило, но здесь, в PEPC, предлагающий продает права на создание программируемых блоков.
PEPC был предложен Барнабе в октябре 2022 года. Барнабе считает, что если механизм PBS должен быть реализован в протоколе, ему следует рассмотреть возможность реализации общего механизма доверенной передачи сигналов, а не реализации конкретного механизма доверенных сигналов (например, если меня попросят построить блок). верните вам xx ETH).
Как и в случае с названием PEPC (Обязательства предлагающего, обеспечиваемые протоколом), некоторые механизмы обеспечения прав и интересов строителей и предлагающих реализуются посредством обязательств, представленных предлагающим в рамках протокола. Эти обязательства могут быть проверены в цепочке, в основном путем. коды операций «BEACONROOT» для достижения. Это более общий механизм. Обязательство может передать на аутсорсинг все права на строительство блоков или только часть блоков. То есть предлагающий продает права на создание программируемых блоков.
краткое содержание
Выше приведено краткое введение в PBS, ePBS и PEPC. С точки зрения разработки протокола необходимо не только разработать рыночный механизм перераспределения MEV, но также подумать о том, как сделать валидаторов более децентрализованными и как улучшить устойчивость к цензуре. Более того, при разработке протокола существует множество компромиссов. Возьмем, к примеру, ePBS, получившую номер EIP. Хотя конструкция ePBS решает проблему централизованной ретрансляции, действительно ли ее ключевая роль в качестве стороннего ретранслятора вне соглашения имеет только отрицательные последствия? С точки зрения механизма оплаты застройщика использование ретрансляции лучше, чем механизм ePBS, поскольку ePBS является механизмом предоплаты. Если строитель упаковывает блок со сверхвысокой прибылью, он не сможет предоставить предлагающему большие суммы. предоплаченный механизм возврата.
Все комментарии