В связи с введением EIP-7732, предложения о разделении роли инициатора и разработчика, валидаторы Ethereumвозьмут на себя новые роли.
Это предложение коренным образом меняет подход к проверке блоков Ethereum , разделяя проверку выполнения и проверку консенсуса как логически, так и во временном отношении.
Валидаторы подвергаются модернизации
Теперь у валидаторов появились новые обязанности, включая возможность стать разработчиками и обязанность предоставлять подтверждения своевременности доставки полезной нагрузки.
EIP решает ряд ключевых проблем в существующей системе. Большинство инициаторов блоков маяков передают создание полезной нагрузки для выполнения сторонней организации, известной как разработчик.

Они запрашивают корень хеш-дерева (HTR) обещанной полезной нагрузки для выполнения и отправляют SignedBlindedBeaconBlock доверенной стороне. Затем эта сторона заменяет HTR полной полезной нагрузкой для выполнения от разработчика перед отправкой широковещательного сообщения.
EIP гарантирует справедливый обмен между инициатором предложения блока маяка и строителем. Он обеспечивает, чтобы честный инициатор предложения блока маяка получал оплату от строящегося, а полезная нагрузка честного строящегося становится каноническим началом цепочки.
В настоящее время у валидаторов есть короткий промежуток времени для выполнения переходов между состояниями консенсуса и исполнения, проверки доступности больших двоичных объектов и оценки нового главы блокчейна.

Данный EIP меняет ситуацию, разделяя выполнение и проверку консенсуса, что позволяет валидаторам сосредоточиться на переходе между состояниями консенсуса перед подтверждением.
Проверка выполнения и доступности данных откладывается, что позволяет валидаторам выполнить эти задачи в оставшееся время.
Обоснование проекта EIP-7732
Удаление полной информации о выполнении из блока консенсуса позволяет ускорить распространение по сети. Это снижает вероятность реорганизации при включении транзакций с большими двоичными объектами из-за увеличения времени, необходимого для проверки доступности данных.
Валидаторы больше не пропускают аттестации, что усиливает свойства выбора форка, когда конструкторы создают недопустимые полезные нагрузки. EIP также устраняет необходимость в доверенном промежуточном ПО для делегирования построения блоков.
EIP не требует изменений на уровне выполнения. Однако уровень консенсуса претерпевает ряд модификаций, подробно описанных в репозитории consensus-specs на GitHub.

В их число входят изменения в Beacon Chain, выборе форка, протоколах P2P, руководствах для валидаторов, а также введение нового руководства для сборщиков.
Изменения в цепочке маяков касаются констант, предустановок и различных классов контейнеров для обработки новых аттестаций полезной нагрузки и подписанных заголовков полезной нагрузки при выполнении.
Контейнер BeaconState модифицируется для tracпоследнего хеша блока, последнего слота с полезной нагрузкой для выполнения и последнего корневого элемента вывода средств.

Теперь BeaconBlockBody включает подписанный заголовок полезной нагрузки выполнения и список подтверждений полезной нагрузки. ExecutionPayloadHeader упрощен для tracминимальной информации, необходимой для выполнения обязательств по полезной нагрузке со стороны разработчика.
Изменения в логике перехода состояний включают новые функции для обработки подтверждений полезной нагрузки, заголовков полезной нагрузки выполнения и запросов на вывод средств.
Изменения в выборе механизма форка включают новые константы и классы контейнеров для обработки дочерних узлов, последних сообщений и изменений хранилища. Введены новые обработчики для сообщений подтверждения полезной нагрузки и подписанных конвертов полезной нагрузки выполнения.
Репортаж Джая Хамида

