В феврале разработчик Prysm Potuz выразил мнение, что у Ethereum есть проблемы с доверием к основной сети, и выступил за отсрочку форка Electra до 2025 года с использованием мероприятия Interop для улучшения дизайна ePBS. Однако сообщество Ethereum имеет разные точки зрения на ePBS, и некоторые разработчики и исследователи опасаются возможных рисков. Мнения о ePBS разнятся, и сегодня мы узнаем, что это такое, и в чем разница между ePBS и PBS.
Ранее мы упомянули, что механизм PBS предназначен для обеспечения безопасности обязательств Proposer и безопасности интерпретации Builder, поэтому эта ответственность возлагается на доверенные Реле. Реле отвечает за хранение содержимого Блока, гарантируя, что Proposer получит содержимое Блока, но не сможет легко украсть содержимое Блока Builder. Однако, если Реле действует злонамеренно, тогда Proposer и Builder понесут ущерб, и им придется обратиться к другим Реле и надеяться, что они не являются злонамеренными. Здесь возникает проблема, мы должны найти доверенную третью сторону, чтобы передать ей доверие. Поскольку PBS - это решение, выходящее за рамки Протокола. PBS зависит от согласия и добровольного соблюдения сообщества, требуется дополнительная координация и доверие.
В PBS должна быть роль посредника в качестве третьей стороны, занимающейся решением проблем:
Внедренное разделение предлагающего и строителя (ePBS), внедренное разделение предлагающего и строителя (ePBS) - это еще один вариант, вытекающий из PBS. ePBS - это предложение, напрямую включающее PBS в уровень соглашения ETH坊, поэтому оно также называется In-Protocol PBS. Его появление было обусловлено потребностью в решении потенциальных сбоев в Реле и устранении одиночных сбоев в системе. Как новый механизм согласования, далее мы подробно рассмотрим ePBS, с целью ясного объяснения его основных принципов, преимуществ и различий с традиционным разделением предлагающего и строителя (PBS).
ePBS, то есть встроенный механизм разделения предложителя и строителя в блокчейн-протоколе. Вместо того чтобы полагаться на доверенную роль релея, как в протоколе Ethereum, если хотя бы одна из сторон - Предложитель или Строитель - совершает злоупотребление, наказание (разрезание) может быть наложено самим протоколом Ethereum, а не обязательно полагаться на доверие к какой-либо роли. Это также является основным отличием всего протокола от ранее упомянутого нами протокола PBS.
Конечно, разделение ролей в применении ePBS все еще основано на оригинальной основе PBS, путем повышения способности отдельной сущности к контролю над содержимым блока для увеличения уровня сопротивления цензуре и децентрализации сети блокчейна.
Из названия можно сделать вывод, что в ePBS Enshrined можно сделать вывод, что в связи с встроенной работой Protokol будут прямо наказываться злостные действия, и доверительный центр также тихо меняется в этой настройке.
В PBS необходимо участие третьих сторон (валидатора, ретранслятора и т.д.), чтобы идентифицировать и наказывать злоумышленников. В ePBS же злоумышленники могут быть идентифицированы и обработаны непосредственно самим Протоколом благодаря его конструкции.
PBS в определенной степени зависит от внешнего управления или третьих лиц, что приводит к проблемам централизации доверия. В отличие от этого, ePBS, внедряя правила в Протокол, уменьшает потребность в доверии к внешним третьим лицам, повышая уровень Децентрализация системы.
*Сравнение традиционной PBS и ePBS
В Ethereum POS цепи время слота разделено на интервалы по 12 секунд. В каждом слоте случайным образом выбирается валидатор, чтобы предложить Блок. В то же время назначается комитет для проверки действительности Блока. Если в заданном слоте не было предложено Блока, то через 4 секунды ответственные за подтверждение валидаторы будут проверять предыдущий Блок.
source: ethresearch, один слот ePBS будет обрабатываться CL (уровень согласования) и EL (уровень исполнения). Информация об Блоке будет транслироваться на уровне согласования, после чего Блок будет отправлен на уровень исполнения для проверки.
Комитет по своевременности полезной нагрузки (PTC), «Комитет по своевременности полезной нагрузки». Основная задача - обеспечить своевременное и точное добавление содержимого транзакций в новый Блок. Этот комитет состоит из валидаторы (в качестве части комитета, взятой в долг у комитета сигнальной цепи 521 человек), их работа заключается в проверке, завершил ли Builder заполнение транзакций Блока к концу каждого цикла создания Блока, и что эти транзакции правильно выполнены в соответствии с правилами.
Просто говоря, PTC похож на команду надзора, контролирующую, своевременно ли сдают свою работу Builder, включают ли они правильные транзакции в Блок. Если Builder хорошо справляется, своевременно представляет требуемый Блок, PTC подтвердит это голосованием. Таким образом, сеть сможет определить, какие Блоки являются полными и действительными, а какие могут иметь проблемы или быть неполными.
Путем механизма голосования PTC влияет на состояние блока, является ли он “полным блоком” или “пустым блоком”. Если PTC подтверждает своевременность и правильность нагрузки, блок может быть признан “полным блоком”; если нет нагрузки или задержки в представлении нагрузки, блок может быть помечен как “пустой блок”. Затем, на основе результатов голосования PTC, сеть непосредственно награждает или наказывает Предложителя и Строителя, чтобы стимулировать своевременное и точное построение блока.
Реализация ePBS с сопротивлением цензуре, совмещенная с дизайном списка включений
Несмотря на то, что основой дизайна ePBS является концепция безопасности Builder, он предоставляет Builder полный контроль над транзакциями Блок. Таким образом, использование списка включений будет очень идеальной формой комбинации, способной обеспечить антицензурное и Децентрализация.
Ранее в наших статьях уже упоминался CL, в общих чертах рассмотрим процесс (детали можно найти по ссылке: undefined). ** Предоставьте этот список Builder’у, приоритетным должно быть включение в него этих сделок. Он должен охватывать все текущие активные сделки, независимо от того, находятся ли эти сделки в пуле сделок. Пока Блок еще имеет свободное место, сделки из списка должны быть включены в Блок Builder’а. Если Блок полон, Builder должен четко обозначить это и подтвердить, что они заметили этот список.
Когда Builder пытается проверить некоторые транзакции, непрерывно заполняющиеся блоки из-за внедрения EIP-1559 приводят к быстрому увеличению base fee. Если в это время Builder продолжает проверять, добавляя фальшивые транзакции в блок, растущие издержки сделают эту практику нерентабельной и непрактичной.
ePBS встроен в Протокол, который разделяет роли предложителя и строителя. Через PTC в качестве подмножества комитета по подтверждению, ответственного за голосование за достоверность и своевременность ution Payload, выпущенного Builder. Его основное преимущество заключается в том, что он преобразует традиционную роль доверенного третьего лица в роль, выполняемую самим Протоколом Ethereum для надзора и наказания, тем самым уменьшая потребность в доверии к одному субъекту. Это не только повышает устойчивость к цензуре, но и, через механизмы, такие как Inclusion List, усиливает защиту сделок, делая стоимость цензуры сделок высокой и неосуществимой.
Кроме того, ePBS просто предоставляет опцию разделения Протокол уровня Блок Proposer и Builder, а не обязательную, их основное различие заключается в механизме оплаты и модели доверия. При рассмотрении вопроса доверия к Протоколу стоимость заключается в необходимости заранее обязаться к оплате. В отличие от ePBS, MEV-Boost может определять сумму, которую необходимо заплатить Beacon Proposer, исходя из полученного дохода, реализованного в ution Payload собственной сортировкой, что обеспечивает больше прибыли и пространства. Может быть, однажды механизм ePBS будет реализован без необходимости предварительного обязательства оплаты, и это приносит немного фантазии и ожидания!