EIP-2537 — это EVM-препроцессорная команда, которая была определена для добавления в последнее обновление форка Pectra Ethereum. Эта команда добавляет различные вычислительные функции кривой BLS12-381 в EVM, такие как вычисления пар на поле кривой и другие.
EIP-2537 был впервые предложен в 2020 году и только в 2025 году был подтвержден для включения в обновление Ethereum. В этой статье будет представлен процесс управления EIP-2537 и рассмотрено, почему это предложение было принято только через 5 лет.
Фон предложения
В январе 2017 года Виталик Бутерин впервые представил алгоритм пар и кривую alt_bn128 в одной статье. Затем в феврале Виталик и Кристиан Рейтвайсснер предложили EIP-196 и EIP-197, предлагая добавить поддержку вычислений с кривой alt_bn128 в EVM.
Обновление Byzantium в октябре 2017 года официально включило кривую alt_bn128, что позволило выполнять вычисления пар по кривым в EVM, и стало возможным выполнение проверки доказательств ZK-Snarks внутри EVM.
Но с развитием криптографии в ноябре 2017 года команда zcash представила кривую BLS12-381, которая обладает более высокой безопасностью и лучшей производительностью по сравнению с alt_bn128. Многие блокчейн-протоколы затем начали использовать кривую BLS12-381 вместо alt_bn128.
В мае 2018 года Джастин Дрейк опубликовал статью, в которой указал, что будущие обновления Ethereum PoS и шардирования могут использовать алгоритм BLS-мультиподписей на основе BLS12-381. Это стало основой для последующего обновления ETH2.
С развитием ETH2 растет интерес к внедрению BLS12-381 в исполняющий уровень. В феврале 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-2537 предоставляет поддержку BLS12-381
EIP-2539 предоставляет поддержку BLS12-377
PR#2541 предоставляет поддержку кривой BLS12-377(Zexe ), но не получил номер EIP
Среди них EIP-2537 является наиболее важным, поскольку уровень консенсуса также использует кривую BLS12-381. Основные цели EIP-1962 и EIP-2537 заключаются в реализации проверки BLS-подписей уровня консенсуса в основной сети.
В то время разрабатывался контракт на депозит ETH2. Поскольку уровень исполнения не имел BLS-валидации, в первоначальном дизайне контракт на депозит не проверял подписи, а проверялся слоем консенсуса; если он был неверен, депозит не удавался, что приводило к потерям средств.
Поэтому основные разработчики хотят ввести предварительную компиляцию BLS12-381 для проверки подписей в депозитном контракте, чтобы избежать рисков потери средств. Это также объясняет, почему разработчики в то время обращали внимание на EIP-1962 и EIP-2537.
После предложения EIP-2537 Виталик немедленно указал на ряд проблем, в основном сосредоточенных на содержании документа. Автор затем ответил и обсудил это.
На заседании основных разработчиков 6 марта 2020 года обсуждалась EIP-2537. Виталик считает, что она очень эффективна для рекурсивных SNARK-доказательств и в долгосрочной перспективе не повредит Ethereum. Заседание подтвердило приоритет EIP-2537, все клиенты согласны реализовать ее как можно скорее и завершить разработку до обновления Berlin.
Затем EIP-2537 стал задачей с высоким приоритетом. На встрече 20 марта 83 вновь была приоритетно обсуждена эта инициатива, подтверждена её замена EIP-1962 в качестве основной BLS инициативы и включение в предварительный список обновления Berlin.
В апрельской конференции 84 официально был включен EIP-2537 в хардфорк Berlin, определив сроки реализации в апреле и тестирования в мае-июне. EIP-2537 был заявлен как вопрос высшего приоритета.
После этого EIP-2537 вошел в стадию активной разработки и тестирования, и на почти каждом из ближайших 20 совещаний основных разработчиков обсуждались соответствующие вопросы.
На конференции 85 обсуждалась проблема кодирования ABI. Поскольку Matter Labs практически завершила реализацию на Rust, клиент Besu заявил, что он практически реализовал функциональность EIP-2537, но Geth заявил, что еще не начал работу над реализацией.
Совещание 86 снова синхронизировало состояние всех узлов, Geth сообщил о завершении части работы, но еще много задач остается выполнить.
Ядро содержания встречи 87 заключается в проблеме реализации EIP-2537. Разработчики Geth заявили, что существует PR на 16000 строк для реализации EIP-2537, но нельзя определить, безопасен ли он и эффективен, его можно оценить только с помощью простого тестирования на нечеткость. Geth считает, что с высокой вероятностью не удастся завершить соответствующую разработку до запланированного времени в Берлине.
Хадсон Джеймсон предложил найти криптографического инженера для помощи в PR-обзоре Geth и рекомендовал протестировать реализацию безопасности в тестовой сети. Команда ETH2 также может участвовать в тестировании.
Необходимо дополнить, что реализация PR EIP-2537 в Geth для обеспечения эффективности大量 использует ассемблерный код, что затрудняет чтение и понимание. Алекс Власов предложил убрать сложную ассемблерную оптимизацию, чтобы снизить сложность проверки.
Хотя одной из основных целей EIP-2537 является помощь в контракте депозитов ETH2, разработчики контракта депозитов на данной встрече заявили, что версия, не использующая EIP-2537, уже прошла аудит, и некоторые разработчики предложили не выпускать новую версию с использованием EIP-2537.
В конце концов, на совещании было решено создать специальную тестовую сеть YOLO для тестирования EIP-2537. В этот момент можно было заметить, что с завершением контракта на депозит важность EIP-2537 значительно снизилась, и разработчики Geth считают, что, скорее всего, не смогут реализовать его до обновления Berlin. Похоже, что EIP-2537 не будет включен в Berlin.
На встрече 88 разработчики Geth обнаружили ряд проблем с реализацией PR для EIP-2537, заявив, что необходимо провести дополнительные тесты для исправления. В это время у Geth есть две версии реализации: одна содержит оптимизацию на ассемблере, другая полностью написана на Go. Кто-то предложил использовать версию на Go, чтобы снизить сложность проверки кода.
На конференции 89 возникла более серьезная проблема, в тестовой сети YOLO произошла аномалия, подозревают, что это вызвано подписью BLS, но разработчики EIP-2537 опровергли это. Хорошая новость в том, что депозитный контракт на основе EIP-2537 практически завершен и ожидает аудита.
Совещание 90 установило срок выхода обновления Berlin в июле. На совещании также обсуждалась проблема разнообразия клиентов, некоторые предложили заморозить текущую реализацию EIP, чтобы снизить затраты на разработку других клиентов. На совещании 91 даже предложили использовать модульную схему для увеличения разнообразия клиентов.
Конференция 92 снова подтвердила, что EIP-2537 является необходимым EIP для обновления Berlin.
На заседании 96 обсуждалось, следует ли включать EIP-2539 в тестирование Berlin, так как Celo уже включил EIP-2537 и EIP-2539 в свое обновление сети. Однако разработчики Geth выступили против, считая, что EIP-2537 сам по себе все еще не полностью протестирован. В конечном итоге было решено не добавлять EIP-2696 в Berlin.
Совещание 99 решило исключить EIP-2537 из тестовой сети YOLO v3 и обновления Berlin, основной причиной является то, что он потратил слишком много времени разработчиков, влияя на разработку других EIP. Второстепенным фактором стало предложение фонда Ethereum EVM384 в качестве альтернативы. Однако разработчики выразили обеспокоенность по поводу его безопасности.
Это ранняя история EIP-2537. Он был одним из самых важных EIP обновления Berlin, но в конечном итоге был отменен из-за проблем с реализацией. В апреле 2021 года Ethereum завершил обновление Berlin, и реализация таких основных EIP, как EIP-2565, была относительно простой, что казалось немного тонким, именно потому, что самый сложный EIP-2537 был исключен.
Последующее развитие
Как известно, каждое обновление Ethereum сопровождается основным предложением, таким как EIP-1559, введённый после Berlin в London. Что касается EIP-2537, которое когда-то было основным предложением, в последующих обновлениях будет трудно снова включить его.
Во время обновления London разработчики рассматривали возможность добавления EIP-2537. На встрече 109 была синхронизирована информация о его разработке, поскольку использование новой библиотеки вызвало обсуждение газа. Кто-то предложил заменить его на EVM384. Однако на встрече 111 из-за сложности его исключили из обновления London, в основном из-за изменения ценообразования газа, вызванного заменой библиотеки, что требует повторной оценки.
В июне 2021 года была официально предложена интеграция EIP-2537 в обновление Shanghai. Однако после Лондона The Merge занял много времени у разработчиков. После завершения The Merge в сентябре 2022 года разработчики уровня выполнения только тогда получили возможность продолжить обсуждение целей Shanghai.
В ноябре 2022 года на встрече кратко обсуждалось, следует ли включить Shanghai, но разработчики считали, что это следует отложить. Основная цель Shanghai заключается в поддержке вывода средств PoS. В конечном итоге EIP-2537 не был включен в обновление Shanghai, сосредоточенное на выводе средств.
Более того, обновление Cancun до сих пор не обсуждало EIP-2537, поскольку его основная цель - поддержка EIP-4844, которая обеспечивает доступность данных Blob для второго уровня.
Наконец, на заседании 181 в феврале 2024 года обсуждалось обновление Pectra с включением EIP-2537, разработчики считают, что реализация больше не является проблемой, существует только проблема ценообразования на газ.
На заседании 19 декабря 2024 года разработчики Nethermind окончательно утвердили модель ценообразования EIP-2537. Первоначальный предложитель Matter Labs на тот момент почти вышел из обсуждения. На заседании 203 в январе 2025 года обсуждалось повторное ценообразование, разработчики Geth предложили увеличить стоимость газа на 20%, что получило поддержку от команды Besu.
Резюме
EIP-2537 прошел долгий путь в 5 лет с момента его предложения до принятия. Он был ядром обновления Berlin, но был abandoned из-за сложностей реализации. Затем Ethereum вошел в историю PoS, и сложные чисто исполнительные EIP стали менее важными, в то время как большое количество связанных с PoS EIP стало основной целью, что привело к долгому отсутствию принятия EIP-2537. Только в 2025 году, с решением основных технических проблем, EIP-2537 наконец-то имеет шанс быть реализованным в обновлении Pectra.
Этот процесс показывает, что возможность включения EIP в обновление Ethereum зависит не только от его технической ценности, но и от стадии разработки и приоритетов всего Ethereum. Каждое обновление имеет свою тему, и только те EIP, которые соответствуют текущим потребностям и являются технически зрелыми, могут быть окончательно приняты.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
8
Поделиться
комментарий
0/400
LuckyPig
· 18ч назад
Давай, действуй! 💪 Быстро войти в позицию! 🚗 Садись крепко, скоро На луну 🛫 Садись крепко, скоро На луну 🛫 Садись крепко, скоро На луну 🛫 Садись крепко, скоро На луну 🛫 Садись крепко, скоро На луну 🛫 Садись крепко, скоро На луну 🛫
Посмотреть ОригиналОтветить0
DataBartender
· 18ч назад
Эта волна ждала 5 лет, это слишком сложно.
Посмотреть ОригиналОтветить0
MetaverseHobo
· 18ч назад
5 лет ожидания - это мучение?
Посмотреть ОригиналОтветить0
AirdropHunterXM
· 18ч назад
Тёрли пять лет? Действия Вита слишком медленные, не так ли?
Посмотреть ОригиналОтветить0
defi_detective
· 18ч назад
5 лет это слишком долго, убивает от нетерпения.
Посмотреть ОригиналОтветить0
MevWhisperer
· 18ч назад
Прошло пять лет, прежде чем я прошел, так что хочется разбить компьютер.
Посмотреть ОригиналОтветить0
NoodlesOrTokens
· 18ч назад
5 лет слишком медленно, что Виталик Бутерин тянет?
Посмотреть ОригиналОтветить0
rekt_but_not_broke
· 18ч назад
Прошло всего пять лет! Эта эффективность хуже, чем открытие Ньютоном закона всемирного тяготения.
Долгий путь EIP-2537: от высокоприоритетного Berlin до окончательного принятия обновления Pectra
EIP-2537: Долгий путь с 2020 по 2025 год
EIP-2537 — это EVM-препроцессорная команда, которая была определена для добавления в последнее обновление форка Pectra Ethereum. Эта команда добавляет различные вычислительные функции кривой BLS12-381 в EVM, такие как вычисления пар на поле кривой и другие.
EIP-2537 был впервые предложен в 2020 году и только в 2025 году был подтвержден для включения в обновление Ethereum. В этой статье будет представлен процесс управления EIP-2537 и рассмотрено, почему это предложение было принято только через 5 лет.
Фон предложения
В январе 2017 года Виталик Бутерин впервые представил алгоритм пар и кривую alt_bn128 в одной статье. Затем в феврале Виталик и Кристиан Рейтвайсснер предложили EIP-196 и EIP-197, предлагая добавить поддержку вычислений с кривой alt_bn128 в EVM.
Обновление Byzantium в октябре 2017 года официально включило кривую alt_bn128, что позволило выполнять вычисления пар по кривым в EVM, и стало возможным выполнение проверки доказательств ZK-Snarks внутри EVM.
Но с развитием криптографии в ноябре 2017 года команда zcash представила кривую BLS12-381, которая обладает более высокой безопасностью и лучшей производительностью по сравнению с alt_bn128. Многие блокчейн-протоколы затем начали использовать кривую BLS12-381 вместо alt_bn128.
В мае 2018 года Джастин Дрейк опубликовал статью, в которой указал, что будущие обновления Ethereum PoS и шардирования могут использовать алгоритм BLS-мультиподписей на основе BLS12-381. Это стало основой для последующего обновления ETH2.
С развитием ETH2 растет интерес к внедрению BLS12-381 в исполняющий уровень. В феврале 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-2537 является наиболее важным, поскольку уровень консенсуса также использует кривую BLS12-381. Основные цели EIP-1962 и EIP-2537 заключаются в реализации проверки BLS-подписей уровня консенсуса в основной сети.
В то время разрабатывался контракт на депозит ETH2. Поскольку уровень исполнения не имел BLS-валидации, в первоначальном дизайне контракт на депозит не проверял подписи, а проверялся слоем консенсуса; если он был неверен, депозит не удавался, что приводило к потерям средств.
Поэтому основные разработчики хотят ввести предварительную компиляцию BLS12-381 для проверки подписей в депозитном контракте, чтобы избежать рисков потери средств. Это также объясняет, почему разработчики в то время обращали внимание на EIP-1962 и EIP-2537.
После предложения EIP-2537 Виталик немедленно указал на ряд проблем, в основном сосредоточенных на содержании документа. Автор затем ответил и обсудил это.
На заседании основных разработчиков 6 марта 2020 года обсуждалась EIP-2537. Виталик считает, что она очень эффективна для рекурсивных SNARK-доказательств и в долгосрочной перспективе не повредит Ethereum. Заседание подтвердило приоритет EIP-2537, все клиенты согласны реализовать ее как можно скорее и завершить разработку до обновления Berlin.
Затем EIP-2537 стал задачей с высоким приоритетом. На встрече 20 марта 83 вновь была приоритетно обсуждена эта инициатива, подтверждена её замена EIP-1962 в качестве основной BLS инициативы и включение в предварительный список обновления Berlin.
В апрельской конференции 84 официально был включен EIP-2537 в хардфорк Berlin, определив сроки реализации в апреле и тестирования в мае-июне. EIP-2537 был заявлен как вопрос высшего приоритета.
После этого EIP-2537 вошел в стадию активной разработки и тестирования, и на почти каждом из ближайших 20 совещаний основных разработчиков обсуждались соответствующие вопросы.
На конференции 85 обсуждалась проблема кодирования ABI. Поскольку Matter Labs практически завершила реализацию на Rust, клиент Besu заявил, что он практически реализовал функциональность EIP-2537, но Geth заявил, что еще не начал работу над реализацией.
Совещание 86 снова синхронизировало состояние всех узлов, Geth сообщил о завершении части работы, но еще много задач остается выполнить.
Ядро содержания встречи 87 заключается в проблеме реализации EIP-2537. Разработчики Geth заявили, что существует PR на 16000 строк для реализации EIP-2537, но нельзя определить, безопасен ли он и эффективен, его можно оценить только с помощью простого тестирования на нечеткость. Geth считает, что с высокой вероятностью не удастся завершить соответствующую разработку до запланированного времени в Берлине.
Хадсон Джеймсон предложил найти криптографического инженера для помощи в PR-обзоре Geth и рекомендовал протестировать реализацию безопасности в тестовой сети. Команда ETH2 также может участвовать в тестировании.
Необходимо дополнить, что реализация PR EIP-2537 в Geth для обеспечения эффективности大量 использует ассемблерный код, что затрудняет чтение и понимание. Алекс Власов предложил убрать сложную ассемблерную оптимизацию, чтобы снизить сложность проверки.
Хотя одной из основных целей EIP-2537 является помощь в контракте депозитов ETH2, разработчики контракта депозитов на данной встрече заявили, что версия, не использующая EIP-2537, уже прошла аудит, и некоторые разработчики предложили не выпускать новую версию с использованием EIP-2537.
В конце концов, на совещании было решено создать специальную тестовую сеть YOLO для тестирования EIP-2537. В этот момент можно было заметить, что с завершением контракта на депозит важность EIP-2537 значительно снизилась, и разработчики Geth считают, что, скорее всего, не смогут реализовать его до обновления Berlin. Похоже, что EIP-2537 не будет включен в Berlin.
На встрече 88 разработчики Geth обнаружили ряд проблем с реализацией PR для EIP-2537, заявив, что необходимо провести дополнительные тесты для исправления. В это время у Geth есть две версии реализации: одна содержит оптимизацию на ассемблере, другая полностью написана на Go. Кто-то предложил использовать версию на Go, чтобы снизить сложность проверки кода.
На конференции 89 возникла более серьезная проблема, в тестовой сети YOLO произошла аномалия, подозревают, что это вызвано подписью BLS, но разработчики EIP-2537 опровергли это. Хорошая новость в том, что депозитный контракт на основе EIP-2537 практически завершен и ожидает аудита.
Совещание 90 установило срок выхода обновления Berlin в июле. На совещании также обсуждалась проблема разнообразия клиентов, некоторые предложили заморозить текущую реализацию EIP, чтобы снизить затраты на разработку других клиентов. На совещании 91 даже предложили использовать модульную схему для увеличения разнообразия клиентов.
Конференция 92 снова подтвердила, что EIP-2537 является необходимым EIP для обновления Berlin.
На заседании 96 обсуждалось, следует ли включать EIP-2539 в тестирование Berlin, так как Celo уже включил EIP-2537 и EIP-2539 в свое обновление сети. Однако разработчики Geth выступили против, считая, что EIP-2537 сам по себе все еще не полностью протестирован. В конечном итоге было решено не добавлять EIP-2696 в Berlin.
Совещание 99 решило исключить EIP-2537 из тестовой сети YOLO v3 и обновления Berlin, основной причиной является то, что он потратил слишком много времени разработчиков, влияя на разработку других EIP. Второстепенным фактором стало предложение фонда Ethereum EVM384 в качестве альтернативы. Однако разработчики выразили обеспокоенность по поводу его безопасности.
Это ранняя история EIP-2537. Он был одним из самых важных EIP обновления Berlin, но в конечном итоге был отменен из-за проблем с реализацией. В апреле 2021 года Ethereum завершил обновление Berlin, и реализация таких основных EIP, как EIP-2565, была относительно простой, что казалось немного тонким, именно потому, что самый сложный EIP-2537 был исключен.
Последующее развитие
Как известно, каждое обновление Ethereum сопровождается основным предложением, таким как EIP-1559, введённый после Berlin в London. Что касается EIP-2537, которое когда-то было основным предложением, в последующих обновлениях будет трудно снова включить его.
Во время обновления London разработчики рассматривали возможность добавления EIP-2537. На встрече 109 была синхронизирована информация о его разработке, поскольку использование новой библиотеки вызвало обсуждение газа. Кто-то предложил заменить его на EVM384. Однако на встрече 111 из-за сложности его исключили из обновления London, в основном из-за изменения ценообразования газа, вызванного заменой библиотеки, что требует повторной оценки.
В июне 2021 года была официально предложена интеграция EIP-2537 в обновление Shanghai. Однако после Лондона The Merge занял много времени у разработчиков. После завершения The Merge в сентябре 2022 года разработчики уровня выполнения только тогда получили возможность продолжить обсуждение целей Shanghai.
В ноябре 2022 года на встрече кратко обсуждалось, следует ли включить Shanghai, но разработчики считали, что это следует отложить. Основная цель Shanghai заключается в поддержке вывода средств PoS. В конечном итоге EIP-2537 не был включен в обновление Shanghai, сосредоточенное на выводе средств.
Более того, обновление Cancun до сих пор не обсуждало EIP-2537, поскольку его основная цель - поддержка EIP-4844, которая обеспечивает доступность данных Blob для второго уровня.
Наконец, на заседании 181 в феврале 2024 года обсуждалось обновление Pectra с включением EIP-2537, разработчики считают, что реализация больше не является проблемой, существует только проблема ценообразования на газ.
На заседании 19 декабря 2024 года разработчики Nethermind окончательно утвердили модель ценообразования EIP-2537. Первоначальный предложитель Matter Labs на тот момент почти вышел из обсуждения. На заседании 203 в январе 2025 года обсуждалось повторное ценообразование, разработчики Geth предложили увеличить стоимость газа на 20%, что получило поддержку от команды Besu.
Резюме
EIP-2537 прошел долгий путь в 5 лет с момента его предложения до принятия. Он был ядром обновления Berlin, но был abandoned из-за сложностей реализации. Затем Ethereum вошел в историю PoS, и сложные чисто исполнительные EIP стали менее важными, в то время как большое количество связанных с PoS EIP стало основной целью, что привело к долгому отсутствию принятия EIP-2537. Только в 2025 году, с решением основных технических проблем, EIP-2537 наконец-то имеет шанс быть реализованным в обновлении Pectra.
Этот процесс показывает, что возможность включения EIP в обновление Ethereum зависит не только от его технической ценности, но и от стадии разработки и приоритетов всего Ethereum. Каждое обновление имеет свою тему, и только те EIP, которые соответствуют текущим потребностям и являются технически зрелыми, могут быть окончательно приняты.