EIP-2537 — это предустановленная инструкция EVM, которая была определена для добавления в последнем обновлении Pectra Ethereum. Эта инструкция добавляет в EVM различные вычислительные функции по кривой BLS12-381, такие как вычисления пар на области кривой.
EIP-2537 был предложен в 2020 году и был подтвержден для включения в обновление Ethereum только в 2025 году. В этой статье будет рассмотрена история управления EIP-2537 и исследовано, почему это предложение было принято только спустя 5 лет.
Фон предложения
В январе 2017 года Виталик Бутерин впервые представил алгоритм пар и кривую alt_bn128 в статье. Затем Виталик и Кристиан Рейтвиснер предложили EIP-196 и EIP-197, предлагая добавить поддержку вычислений с кривой alt_bn128 в EVM.
В октябре 2017 года обновление «Византия» официально ввело кривую alt_bn128, что позволило выполнять вычисления пар по кривым в EVM, и проверка доказательств ZK-Snarks может быть выполнена внутри EVM.
Однако, с развитием криптографии, в ноябре 2017 года команда разработчиков zcash предложила кривую BLS12-381. По сравнению с alt_bn128, BLS12-381 обладает более высокой безопасностью и лучшей производительностью. Многие блокчейн-протоколы позже стали использовать кривую BLS12-381, отказавшись от alt_bn128.
В мае 2018 года Джастин Дрейк опубликовал статью, в которой указал, что будущие обновления PoS и шардирования Ethereum могут использовать алгоритм BLS-множественной подписи на основе кривой BLS12-381. Это решение устраняет проблему ограниченного числа валидаторов в ранних схемах PoS. Фактически, поздние обновления ETH2 действительно использовали кривую BLS12-381.
С развитием ETH2 растет призыв к внедрению BLS12-381 в слой выполнения ETH. В феврале 2020 года исследователи предложили EIP-2537 и надеются, что это предложение будет протестировано вместе с тестовой сетью ETH2. Автор EIP-2537 Алекс Стокс призвал включить это предложение в хардфорк Berlin.
Стоит отметить, что автор EIP-2537 также является соучредителем компании Matter Labs, разработчика ZKSync.
Повороты в обновлении Берлина
Перед тем как представить дальнейшие успехи, нам необходимо сначала понять EIP-1962. Это первое предложение Matter Labs, выдвинутое в апреле 2019 года, касающееся предварительной компиляции пар по эллиптическим кривым, поддерживающее три типа кривых: BLS12, BN и MNT4/6.
EIP-1962 планирует однократное добавление 10 предварительно скомпилированных инструкций для обработки различных кривых. Однако это предложение вызвало много вопросов со стороны разработчиков, которые считают его слишком сложным для реализации. Кроме того, из-за высокой универсальности, вызов для инженеров смарт-контрактов также очень неудобен. Тем не менее, как сторона, предложившая это, Matter Labs уже завершила разработку алгоритма эллиптической кривой и предоставила несколько языков для справочных реализаций.
Чтобы решить проблему EIP-1962, Matter Labs в феврале 2020 года предложила несколько EIP для разделения EIP-1962. Эти EIP частично унаследовали интерфейс EIP-1962:
EIP-2537 предоставляет поддержку BLS12-381
EIP-2539 предоставляет поддержку BLS12-377
PR#2541 предоставляет поддержку кривой BLS12-377(Zexe ), но данное предложение в конечном итоге не получило номер EIP.
Наиболее важным является EIP-2537, поскольку уровень консенсуса также использует кривую BLS12-381. Основные цели EIP-1962 и EIP-2537 заключаются в реализации проверки BLS-подписей уровня консенсуса в основной сети. В то время ETH2 разрабатывал контракт на депозит уровня консенсуса. В первоначальном дизайне, поскольку уровень исполнения не включает алгоритм проверки BLS, депозитный контракт не будет проверять подписи, конкретная BLS-подпись будет проверена уровнем консенсуса после депозита пользователя; если она окажется некорректной, депозит будет отменен, и ETH, внесенный пользователем, может быть потерян.
В этом контексте основные разработчики стремятся ввести предкомпилированный BLS12-381 для реализации проверки подписей в контракте на депозит, чтобы избежать возможных потерь средств пользователей. Это также была причина, по которой в то время большое количество разработчиков обратило внимание на EIP-1962 и EIP-2537.
Когда EIP-2537 только был предложен, Виталик указал на ряд проблем, связанных с предложением. Эти сомнения в основном касались содержания документа EIP, после чего авторы EIP ответили на них и обсудили их.
82-е собрание основных разработчиков Ethereum, состоявшееся 6 марта 2020 года, обсудило EIP-2537. Виталик считает, что этот EIP очень эффективен для рекурсивных SNARK-доказательств и в долгосрочной перспективе не окажет негативного влияния на Ethereum. Собрание подтвердило приоритет EIP-2537, все клиенты согласились реализовать этот EIP как можно скорее и планируют завершить всю разработку до обновления Berlin.
Затем EIP-2537 стал задачей с высокой приоритетностью. На 83-й встрече основных разработчиков 20 марта его вновь обсудили как предложение первоочередного значения. На встрече подтвердили, что EIP-2537 заменяет EIP-1962 как основное предложение BLS и включается в предварительный список обновления Berlin.
84-е заседание в апреле официально включило EIP-2537 в обновление жесткой вилки Berlin и определило временные рамки для реализации в апреле и тестирования в мае-июне. Важно отметить, что EIP-2537 был включён в список вопросов высшего приоритета на данном обсуждении.
После этого EIP-2537 вошел в стадию активной разработки и тестирования, и на почти каждом из ближайших 20 встреч основных разработчиков проходило обсуждение, связанное с ним.
На 85-й встрече разработчики обсудили проблему ABI-кодирования EIP-2537. Поскольку Matter Labs ранее в основном завершила реализацию версии на Rust, клиент Besu заявил, что он в основном реализовал функциональность EIP-2537, но со стороны Geth заявили, что в настоящее время никто не занимается соответствующей работой.
На 86-й встрече различные узлы снова синхронизировали прогресс EIP-2537, Geth сообщил о завершении части работы, но еще предстоит выполнить много задач.
На 87-й встрече основной темой обсуждения были проблемы реализации EIP-2537. Разработчики Geth отметили, что существует PR на 16000 строк, реализующий EIP-2537, но нельзя с уверенностью сказать, безопасно ли и эффективно ли этот PR реализует EIP-2537, можно лишь оценить состояние кода с помощью самых простых тестов на нечеткость.
Разработчик Geth заявил: "По моему ощущению, Geth не сможет подготовить операции с кривой BLS до запуска основной сети в июле."
Хадсон Джеймсон предложил найти криптографического инженера для помощи в PR-обзоре Geth и рекомендовал использовать тестовую сеть для проверки безопасности реализации EIP-2537. Поскольку команда разработчиков ETH2 также реализует проверку BLS-подписей, они могут участвовать в тестировании.
Важно отметить, что реализация PR EIP-2537 в Geth для обеспечения высокой эффективности использует большое количество ассемблерного кода, который очень трудно читать и понимать. Алекс Власов предложил убрать сложные ассемблерные оптимизации из PR, чтобы снизить сложность ревью.
Одной из основных целей EIP-2537 является помощь в контракте депозитов ETH2, однако на этой встрече разработчики контракта депозитов заявили, что контракт, не использующий EIP-2537, уже прошел аудит, и некоторые разработчики считают, что лучше не выпускать новую версию контракта с использованием EIP-2537.
В конце концов, на встрече было решено увеличить тестовую сеть YOLO, специально предназначенную для тестирования EIP-2537. На самом деле, из этой встречи видно, что с завершением депозитного контракта важность EIP-2537 значительно снизилась, в то время как разработчики Geth считают, что этот EIP, скорее всего, не сможет быть реализован до обновления Berlin. Похоже, что EIP-2537 не будет принят в обновлении Berlin.
На 88-м заседании разработчики Geth обнаружили, что реализация PR для EIP-2537 имеет ряд проблем и заявили, что необходимо провести дальнейшее тестирование и исправление. В это время в системе Geth существует две реализации EIP-2537: одна содержит оптимизацию на ассемблере, другая полностью написана на языке Go. Один из разработчиков предложил напрямую использовать версию на языке Go, чтобы снизить сложность ревью кода.
На 89-й встрече возникла более серьезная проблема: на тестовой сети YOLO появились некоторые аномалии, разработчики подозревают, что это связано с BLS-подписями, однако разработчики EIP-2537 опровергли это. Хорошая новость заключается в том, что контракт на депозит, основанный на EIP-2537, в основном завершен и ожидает аудита.
90-е заседание установило последний срок для запуска обновления Berlin в июле. На заседании также обсуждалась проблема разнообразия клиентов, в основном касающаяся доминирования Geth, некоторые разработчики предложили заморозить текущее внедрение EIP, чтобы снизить затраты на разработку других клиентов. На 91-м заседании один из разработчиков предложил использовать модульный подход для снижения затрат на разработку и увеличения разнообразия клиентов.
92-е заседание все еще подтверждает EIP-2537 как необходимый EIP для обновления Berlin.
На 96-й конференции, поскольку Celo одновременно включил EIP-2537 и EIP-2539 в свой сетевой хардфорк, Matter Labs希望将EIP-2539也放到YOLO v2测试并进入Berlin升级。但Geth разработчики выступили против, считая, что текущий EIP-2537 все еще не был полностью протестирован в Geth. В конечном итоге конференция решила не добавлять EIP-2696 в обновление Berlin, оставив это для обсуждения в будущем.
На 99-й конференции было решено вывести EIP-2537 из тестовой сети YOLO v3 и обновления Berlin. Главная причина заключается в том, что EIP-2537 потребовал слишком много времени от основных разработчиков, что затруднило разработку других EIP для обновления Berlin. Второстепенной причиной является то, что Фонд Эфириума предложил EVM384 в качестве замены для EIP-2537, предоставляя более универсальное решение для вычислений по эллиптическим кривым. Однако основные разработчики выразили обеспокоенность по поводу вопросов безопасности.
Это ранняя история EIP-2537. Мы видим, что EIP-2537 изначально был одним из самых важных EIP в обновлении Berlin, но был отменен из-за проблем с реализацией. В апреле 2021 года Ethereum завершил обновление Berlin, основные EIP, такие как EIP-2565, на самом деле не были сложными в реализации, и обновление выглядело несколько скромно, так как самый сложный и центральный EIP-2537 был исключен.
Последующее развитие
Как известно, каждое обновление Ethereum включает одно основное предложение. Обновление Лондона после Берлина ввело самое важное предложение по комиссиям в истории Ethereum - EIP-1559. Для прежнего основного предложения EIP-2537 последующие обновления вряд ли смогут его включить.
Лондонское обновление после Берлина, разработчики рассматривают возможность добавления EIP-2537 в issues#369. На 109-й встрече основных разработчиков синхронизировали состояние разработки EIP-2537, и из-за использования других библиотек возникли обсуждения по поводу использования газа. Один из разработчиков предложил заменить EIP-2537 на EVM384. Однако на 111-й встрече в апреле 2021 года EIP-2537 был исключён из обновления Лондон из-за сложности. Основная причина заключается в том, что стандарт EIP-2537 изменил зависимые библиотеки, что может привести к изменению цен на газ, и различным клиентам потребуется много времени для повторной оценки потребления газа.
В июне 2021 года, issues#343 официально предложил включить EIP-2537 в обновление Shanghai. Однако после обновления London, The Merge занял много времени разработчиков, разработчикам уровня исполнения пришлось написать огромное количество кода для реализации PoS-обновления. В сентябре 2022 года, после завершения The Merge, разработчики уровня исполнения получили возможность продолжить обсуждение целей обновления Shanghai.
Ноябрь 2022 года, на 150-м заседании основных разработчиков кратко обсуждалось, следует ли включать EIP-2537 в Shanghai, но разработчики пришли к выводу, что это следует отложить, так как основной целью Shanghai является поддержка вывода PoS. В итоге EIP-2537 не был включен в обновление Shanghai, сосредоточенное на выводе.
К сожалению, обновление Cancun до сих пор не обсуждало EIP-2537, так как основное внимание Cancun сосредоточено на поддержке EIP-4844, чтобы обеспечить Blob для второго уровня Ethereum, позволяя второму уровню использовать Ethereum в качестве слоя доступности данных.
Только на 181-й встрече основных разработчиков в феврале 2024 года разработчики обсудили включение EIP-2537 в обновление Pectra. На тот момент разработчики считали, что реализация EIP-2537 больше не является проблемой, и только некоторые вопросы, касающиеся ценообразования на газ, нужно было решить.
На 202-й встрече, состоявшейся 19 декабря 2024 года, разработчики Nethermind окончательно определили модель ценообразования для EIP-2537. Стоит отметить, что Matter Labs, первоначальный инициатор EIP-2537, на данном этапе фактически вышел из обсуждения. На 203-й встрече в январе 2025 года обсуждалось изменение цен на BLS предкомпиляцию, разработчик Geth Джаред Уазингер предложил увеличить стоимость газа на 20%, что было поддержано командой Besu в ходе бенчмаркинга.
Резюме
EIP-2537 прошел долгий и извилистый путь от предложения до окончательного принятия:
Февраль 2020 года: разделен из EIP-1962, официально предложен EIP-2537
Апрель-октябрь 2020 года: множество обсуждений по вопросам реализации, в конце концов, из-за невозможности реализации был оставлен апгрейд Berlin
Март-апрель 2021 года: обсуждение проблемы затрат на газ, из-за сложности было решено отказаться от обновления London.
Ноябрь 2022 года: обсуждение вопроса о включении обновления Shanghai, безрезультатно
Февраль 2024 года: считается, что реализация больше не является проблемой, все еще существуют некоторые проблемы с затратами на газ, которые могут быть включены в обновление Pectra
Декабрь 2024 - Январь 2025: обсуждение конкретной модели расчета затрат, официальное решение вопросов с газовыми расходами
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
6
Репост
Поделиться
комментарий
0/400
StableGenius
· 08-03 06:12
эмпирически говоря, им понадобилось 5 лет, чтобы сделать то, что должно было быть сделано за 6 месяцев. классический театр управления эфира
Посмотреть ОригиналОтветить0
RugResistant
· 08-01 07:29
анализировал eip. потенциальные проблемы в реализации bls требуют более глубокого аудита, если честно
Посмотреть ОригиналОтветить0
NFTDreamer
· 08-01 07:29
Вот это да, Виталик Бутерин давно хотел так сделать.
Посмотреть ОригиналОтветить0
TokenSleuth
· 08-01 07:29
О, мне придется ждать пять лет... Хватит мучений.
Посмотреть ОригиналОтветить0
0xSunnyDay
· 08-01 07:14
5 лет ждать eip слишком трудно
Посмотреть ОригиналОтветить0
LiquidityHunter
· 08-01 07:11
Эх, я уже устал ждать из-за медленных действий Ethereum.
EIP-2537: Важное обновление Ethereum, которое прошло 5 лет от спора до принятия
EIP-2537: Долгий путь от споров к принятию
EIP-2537 — это предустановленная инструкция EVM, которая была определена для добавления в последнем обновлении Pectra Ethereum. Эта инструкция добавляет в EVM различные вычислительные функции по кривой BLS12-381, такие как вычисления пар на области кривой.
EIP-2537 был предложен в 2020 году и был подтвержден для включения в обновление Ethereum только в 2025 году. В этой статье будет рассмотрена история управления EIP-2537 и исследовано, почему это предложение было принято только спустя 5 лет.
Фон предложения
В январе 2017 года Виталик Бутерин впервые представил алгоритм пар и кривую alt_bn128 в статье. Затем Виталик и Кристиан Рейтвиснер предложили EIP-196 и EIP-197, предлагая добавить поддержку вычислений с кривой alt_bn128 в EVM.
В октябре 2017 года обновление «Византия» официально ввело кривую alt_bn128, что позволило выполнять вычисления пар по кривым в EVM, и проверка доказательств ZK-Snarks может быть выполнена внутри EVM.
Однако, с развитием криптографии, в ноябре 2017 года команда разработчиков zcash предложила кривую BLS12-381. По сравнению с alt_bn128, BLS12-381 обладает более высокой безопасностью и лучшей производительностью. Многие блокчейн-протоколы позже стали использовать кривую BLS12-381, отказавшись от alt_bn128.
В мае 2018 года Джастин Дрейк опубликовал статью, в которой указал, что будущие обновления PoS и шардирования Ethereum могут использовать алгоритм BLS-множественной подписи на основе кривой BLS12-381. Это решение устраняет проблему ограниченного числа валидаторов в ранних схемах PoS. Фактически, поздние обновления ETH2 действительно использовали кривую BLS12-381.
С развитием ETH2 растет призыв к внедрению BLS12-381 в слой выполнения ETH. В феврале 2020 года исследователи предложили EIP-2537 и надеются, что это предложение будет протестировано вместе с тестовой сетью ETH2. Автор EIP-2537 Алекс Стокс призвал включить это предложение в хардфорк Berlin.
Стоит отметить, что автор EIP-2537 также является соучредителем компании Matter Labs, разработчика ZKSync.
Повороты в обновлении Берлина
Перед тем как представить дальнейшие успехи, нам необходимо сначала понять EIP-1962. Это первое предложение Matter Labs, выдвинутое в апреле 2019 года, касающееся предварительной компиляции пар по эллиптическим кривым, поддерживающее три типа кривых: BLS12, BN и MNT4/6.
EIP-1962 планирует однократное добавление 10 предварительно скомпилированных инструкций для обработки различных кривых. Однако это предложение вызвало много вопросов со стороны разработчиков, которые считают его слишком сложным для реализации. Кроме того, из-за высокой универсальности, вызов для инженеров смарт-контрактов также очень неудобен. Тем не менее, как сторона, предложившая это, Matter Labs уже завершила разработку алгоритма эллиптической кривой и предоставила несколько языков для справочных реализаций.
Чтобы решить проблему EIP-1962, Matter Labs в феврале 2020 года предложила несколько EIP для разделения EIP-1962. Эти EIP частично унаследовали интерфейс EIP-1962:
Наиболее важным является EIP-2537, поскольку уровень консенсуса также использует кривую BLS12-381. Основные цели EIP-1962 и EIP-2537 заключаются в реализации проверки BLS-подписей уровня консенсуса в основной сети. В то время ETH2 разрабатывал контракт на депозит уровня консенсуса. В первоначальном дизайне, поскольку уровень исполнения не включает алгоритм проверки BLS, депозитный контракт не будет проверять подписи, конкретная BLS-подпись будет проверена уровнем консенсуса после депозита пользователя; если она окажется некорректной, депозит будет отменен, и ETH, внесенный пользователем, может быть потерян.
В этом контексте основные разработчики стремятся ввести предкомпилированный BLS12-381 для реализации проверки подписей в контракте на депозит, чтобы избежать возможных потерь средств пользователей. Это также была причина, по которой в то время большое количество разработчиков обратило внимание на EIP-1962 и EIP-2537.
Когда EIP-2537 только был предложен, Виталик указал на ряд проблем, связанных с предложением. Эти сомнения в основном касались содержания документа EIP, после чего авторы EIP ответили на них и обсудили их.
82-е собрание основных разработчиков Ethereum, состоявшееся 6 марта 2020 года, обсудило EIP-2537. Виталик считает, что этот EIP очень эффективен для рекурсивных SNARK-доказательств и в долгосрочной перспективе не окажет негативного влияния на Ethereum. Собрание подтвердило приоритет EIP-2537, все клиенты согласились реализовать этот EIP как можно скорее и планируют завершить всю разработку до обновления Berlin.
Затем EIP-2537 стал задачей с высокой приоритетностью. На 83-й встрече основных разработчиков 20 марта его вновь обсудили как предложение первоочередного значения. На встрече подтвердили, что EIP-2537 заменяет EIP-1962 как основное предложение BLS и включается в предварительный список обновления Berlin.
84-е заседание в апреле официально включило EIP-2537 в обновление жесткой вилки Berlin и определило временные рамки для реализации в апреле и тестирования в мае-июне. Важно отметить, что EIP-2537 был включён в список вопросов высшего приоритета на данном обсуждении.
После этого EIP-2537 вошел в стадию активной разработки и тестирования, и на почти каждом из ближайших 20 встреч основных разработчиков проходило обсуждение, связанное с ним.
На 85-й встрече разработчики обсудили проблему ABI-кодирования EIP-2537. Поскольку Matter Labs ранее в основном завершила реализацию версии на Rust, клиент Besu заявил, что он в основном реализовал функциональность EIP-2537, но со стороны Geth заявили, что в настоящее время никто не занимается соответствующей работой.
На 86-й встрече различные узлы снова синхронизировали прогресс EIP-2537, Geth сообщил о завершении части работы, но еще предстоит выполнить много задач.
На 87-й встрече основной темой обсуждения были проблемы реализации EIP-2537. Разработчики Geth отметили, что существует PR на 16000 строк, реализующий EIP-2537, но нельзя с уверенностью сказать, безопасно ли и эффективно ли этот PR реализует EIP-2537, можно лишь оценить состояние кода с помощью самых простых тестов на нечеткость.
Разработчик Geth заявил: "По моему ощущению, Geth не сможет подготовить операции с кривой BLS до запуска основной сети в июле."
Хадсон Джеймсон предложил найти криптографического инженера для помощи в PR-обзоре Geth и рекомендовал использовать тестовую сеть для проверки безопасности реализации EIP-2537. Поскольку команда разработчиков ETH2 также реализует проверку BLS-подписей, они могут участвовать в тестировании.
Важно отметить, что реализация PR EIP-2537 в Geth для обеспечения высокой эффективности использует большое количество ассемблерного кода, который очень трудно читать и понимать. Алекс Власов предложил убрать сложные ассемблерные оптимизации из PR, чтобы снизить сложность ревью.
Одной из основных целей EIP-2537 является помощь в контракте депозитов ETH2, однако на этой встрече разработчики контракта депозитов заявили, что контракт, не использующий EIP-2537, уже прошел аудит, и некоторые разработчики считают, что лучше не выпускать новую версию контракта с использованием EIP-2537.
В конце концов, на встрече было решено увеличить тестовую сеть YOLO, специально предназначенную для тестирования EIP-2537. На самом деле, из этой встречи видно, что с завершением депозитного контракта важность EIP-2537 значительно снизилась, в то время как разработчики Geth считают, что этот EIP, скорее всего, не сможет быть реализован до обновления Berlin. Похоже, что EIP-2537 не будет принят в обновлении Berlin.
На 88-м заседании разработчики Geth обнаружили, что реализация PR для EIP-2537 имеет ряд проблем и заявили, что необходимо провести дальнейшее тестирование и исправление. В это время в системе Geth существует две реализации EIP-2537: одна содержит оптимизацию на ассемблере, другая полностью написана на языке Go. Один из разработчиков предложил напрямую использовать версию на языке Go, чтобы снизить сложность ревью кода.
На 89-й встрече возникла более серьезная проблема: на тестовой сети YOLO появились некоторые аномалии, разработчики подозревают, что это связано с BLS-подписями, однако разработчики EIP-2537 опровергли это. Хорошая новость заключается в том, что контракт на депозит, основанный на EIP-2537, в основном завершен и ожидает аудита.
90-е заседание установило последний срок для запуска обновления Berlin в июле. На заседании также обсуждалась проблема разнообразия клиентов, в основном касающаяся доминирования Geth, некоторые разработчики предложили заморозить текущее внедрение EIP, чтобы снизить затраты на разработку других клиентов. На 91-м заседании один из разработчиков предложил использовать модульный подход для снижения затрат на разработку и увеличения разнообразия клиентов.
92-е заседание все еще подтверждает EIP-2537 как необходимый EIP для обновления Berlin.
На 96-й конференции, поскольку Celo одновременно включил EIP-2537 и EIP-2539 в свой сетевой хардфорк, Matter Labs希望将EIP-2539也放到YOLO v2测试并进入Berlin升级。但Geth разработчики выступили против, считая, что текущий EIP-2537 все еще не был полностью протестирован в Geth. В конечном итоге конференция решила не добавлять EIP-2696 в обновление Berlin, оставив это для обсуждения в будущем.
На 99-й конференции было решено вывести EIP-2537 из тестовой сети YOLO v3 и обновления Berlin. Главная причина заключается в том, что EIP-2537 потребовал слишком много времени от основных разработчиков, что затруднило разработку других EIP для обновления Berlin. Второстепенной причиной является то, что Фонд Эфириума предложил EVM384 в качестве замены для EIP-2537, предоставляя более универсальное решение для вычислений по эллиптическим кривым. Однако основные разработчики выразили обеспокоенность по поводу вопросов безопасности.
Это ранняя история EIP-2537. Мы видим, что EIP-2537 изначально был одним из самых важных EIP в обновлении Berlin, но был отменен из-за проблем с реализацией. В апреле 2021 года Ethereum завершил обновление Berlin, основные EIP, такие как EIP-2565, на самом деле не были сложными в реализации, и обновление выглядело несколько скромно, так как самый сложный и центральный EIP-2537 был исключен.
Последующее развитие
Как известно, каждое обновление Ethereum включает одно основное предложение. Обновление Лондона после Берлина ввело самое важное предложение по комиссиям в истории Ethereum - EIP-1559. Для прежнего основного предложения EIP-2537 последующие обновления вряд ли смогут его включить.
Лондонское обновление после Берлина, разработчики рассматривают возможность добавления EIP-2537 в issues#369. На 109-й встрече основных разработчиков синхронизировали состояние разработки EIP-2537, и из-за использования других библиотек возникли обсуждения по поводу использования газа. Один из разработчиков предложил заменить EIP-2537 на EVM384. Однако на 111-й встрече в апреле 2021 года EIP-2537 был исключён из обновления Лондон из-за сложности. Основная причина заключается в том, что стандарт EIP-2537 изменил зависимые библиотеки, что может привести к изменению цен на газ, и различным клиентам потребуется много времени для повторной оценки потребления газа.
В июне 2021 года, issues#343 официально предложил включить EIP-2537 в обновление Shanghai. Однако после обновления London, The Merge занял много времени разработчиков, разработчикам уровня исполнения пришлось написать огромное количество кода для реализации PoS-обновления. В сентябре 2022 года, после завершения The Merge, разработчики уровня исполнения получили возможность продолжить обсуждение целей обновления Shanghai.
Ноябрь 2022 года, на 150-м заседании основных разработчиков кратко обсуждалось, следует ли включать EIP-2537 в Shanghai, но разработчики пришли к выводу, что это следует отложить, так как основной целью Shanghai является поддержка вывода PoS. В итоге EIP-2537 не был включен в обновление Shanghai, сосредоточенное на выводе.
К сожалению, обновление Cancun до сих пор не обсуждало EIP-2537, так как основное внимание Cancun сосредоточено на поддержке EIP-4844, чтобы обеспечить Blob для второго уровня Ethereum, позволяя второму уровню использовать Ethereum в качестве слоя доступности данных.
Только на 181-й встрече основных разработчиков в феврале 2024 года разработчики обсудили включение EIP-2537 в обновление Pectra. На тот момент разработчики считали, что реализация EIP-2537 больше не является проблемой, и только некоторые вопросы, касающиеся ценообразования на газ, нужно было решить.
На 202-й встрече, состоявшейся 19 декабря 2024 года, разработчики Nethermind окончательно определили модель ценообразования для EIP-2537. Стоит отметить, что Matter Labs, первоначальный инициатор EIP-2537, на данном этапе фактически вышел из обсуждения. На 203-й встрече в январе 2025 года обсуждалось изменение цен на BLS предкомпиляцию, разработчик Geth Джаред Уазингер предложил увеличить стоимость газа на 20%, что было поддержано командой Besu в ходе бенчмаркинга.
Резюме
EIP-2537 прошел долгий и извилистый путь от предложения до окончательного принятия: