Предлагается добавить новый объект к blobSchedule на уровне исполнения:
"prague": {
"target": 6,
"max": 9,
"baseFeeUpdateFraction": 5007716
}
Очевидно, что это дублирующие настройки целевого и максимального количества блобов в блоке, которые мы уже рассмотрели в рамках EIP-7691: Blob throughput increase и которые устанавливались на уровне консенсуса.
▫️Что такое blobSchedule?
Это структура данных, которая отвечает за процесс обработки блобов. Она определяет, как и когда блобы могут быть включены в блоки, обеспечивая контроль над их количеством и параметрами.
Настройки будут добавлены к genesis chain config и будут определены в config.go (это в geth, в других клиентах может быть по-другому).
▫️Параметр baseFeeUpdateFraction
Мы еще не разбирали параметр baseFeeUpdateFraction, думаю, пришло время. Этот параметр отвечает за механизм обновления базовой комиссии (blob base fee). 🤔
У базовой комиссии есть своя формула расчета, которая использует baseFeeUpdateFraction как коэффициент, определяющий, насколько быстро меняется blob base fee в зависимости от загрузки сети.
⬆️ Чем больше baseFeeUpdateFraction, тем меньше изменение blobBaseFee.
⬇️ Чем меньше baseFeeUpdateFraction, тем более чувствительно меняется blobBaseFee.
И здесь прошу обратить внимание, что в этом предложение baseFeeUpdateFraction повышается с 3338477 до 5007716. Это означает, что комиссия будет изменятся плавнее.
▫️Нюансик
Зачем значения, которые являются константами, объявлять в конфиге генезис блока, если они меняются только во время форков? Может проще захардкодить?
Такое объявление упрощает процесс тестирования и моделирования в тестовых сетях, позволяя легко изменять значения и смотреть на результат.
Мне очень не нравится такой подход, налицо дублирование кода в изолированных слоях консенсуса и исполнения. Это требует дополнительных затрат на развитие и поддержку кода. Почему бы не подумать над тем, чтобы сделать, как завещал дядюшка Боб? Сделать общую кодовую база для переиспользования на уровнях консенсуса и выполнения. Может мне кто-то объяснить в чем трудность?
▫️Вывод
Как говорят во многих статьях, описывающих этот стандарт: «Ничего интересного, поменяют параметры блобов и все».
Но разработчики Ethereum, думаю, с этим не согласятся. Протокол достиг того уровня, когда даже самые маленькие изменения будут иметь свою долю влияния на работу протокола, стейкеров и валидаторов.
Предложение нацелено в фиксации параметров, регулирующих количество блобов в блоке, на уровне исполнения.
▫️Продолжение нюансика
Неожиданно мне пришла в голову мысль: «Когда сложность Ethereum в него выстрелит?». Ведь чем дальше, тем больше код обрастает кучей условий под разные форки. Посмотрите на этот код:
if isForkTimestampIncompatible(c.CancunTime, newcfg.CancunTime, headTimestamp) {
return newTimestampCompatError("Cancun fork timestamp", c.CancunTime, newcfg.CancunTime)
}
if isForkTimestampIncompatible(c.PragueTime, newcfg.PragueTime, headTimestamp) {
return newTimestampCompatError("Prague fork timestamp", c.PragueTime, newcfg.PragueTime)
}
Сколько еще нужно форков и предложений, чтобы даже самый опытный разработчик клиента заблудился в коде и оставил уязвимость? Меня пугает такое развитие кодовой базы, хотя с другой стороны, я прекрасно понимаю, почему так получается: совместимость, безопасность, добавим сюда нюансы раскатывания по сети и т.д. и т.п.
▫️Заключение
Мы рассмотрели последнее предложение для Pectra. Не смотря на то, что по-большому счету предложения направлены на работу с техническим долгом, я все равно ожидаю форк с нетерпением, как новый этап в развитии Ethereum.
Мой фаворит в этом списке — это EIP-7702: Set EOA account code for one transaction, я довольно намучился с абстракцией аккаунта. А какое предложение смотрит на тебя?🍺
#в_гостях_у_Pectra #павел_найданов