EIP-2537: Довгий шлях від 2020 до 2025 року

EIP-2537 є EVM-упередженою командою, яка була визначена для додавання у найновішому оновленні Pectra Ethereum. Ця команда додає до EVM різноманітні обчислювальні функції для кривої BLS12-381, такі як обчислення пар на полях кривої.

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 року Джастін Дрейк опублікував статтю, в якій зазначив, що майбутні оновлення PoS та шардінг Ethereum можуть використовувати алгоритм 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 Віталік відразу вказав на низку проблем, які в основному зосереджені на змісті документа. Автор потім дав відповідь і провів обговорення.

Конференція основних розробників 82, що відбулася 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 також може взяти участь у тестуванні.

Слід зазначити, що реалізація EIP-2537 Geth в PR для забезпечення ефективності активно використовує асемблерний код, що ускладнює читання та розуміння. Алекс Власов запропонував прибрати складну оптимізацію асемблера, щоб знизити складність перевірки.

Хоча однією з основних цілей 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 для оновлення Берліна.

На засіданні 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-2537])https://img-cdn.gateio.im/webp-social/moments-3198079b11f21298df05682606409838.webp(

Подальший розвиток

Як відомо, кожне оновлення Ethereum має основну пропозицію, таку як EIP-1559, введену після Берліна в Лондоні. Для EIP-2537, яка колись була основною пропозицією, наступні оновлення важко буде включити.

Під час оновлення London розробники розглядали можливість додавання EIP-2537. На засіданні 109 було синхронізовано його стан розробки, оскільки використання нової бібліотеки викликало обговорення газу. Хтось запропонував замінити на EVM384. Але на засіданні 111 через складність його було виключено з оновлення London, головним чином через зміни в ціноутворенні газу, що викликані заміною бібліотеки, які потребують повторної оцінки.

У червні 2021 року офіційно було запропоновано включити EIP-2537 до оновлення Shanghai. Але після London The Merge зайняв багато часу у розробників. Лише у вересні 2022 року, після завершення The Merge, розробники виконавчого рівня отримали можливість продовжити обговорення цілей Shanghai.

У листопаді 2022 року на нараді було коротко обговорено можливість включення Шанхаю, але розробники вважали, що це слід відкласти. Основна мета Шанхаю полягає в підтримці виведення PoS. Врешті-решт, EIP-2537 не було включено до оновлення Шанхаю, яке було зосереджене на виведенні.

Гірше того, що оновлення Cancun ніколи не обговорювало EIP-2537, оскільки його основою є підтримка EIP-4844, яка забезпечує доступність даних Blob для другого рівня.

Нарешті, на засіданні 181 у лютому 2024 року обговорювалися оновлення Pectra з впровадженням EIP-2537, розробники вважають, що реалізація вже не є проблемою, існує лише проблема ціноутворення газу.

19 грудня 2024 року на конференції 202 розробники Nethermind остаточно затвердили модель ціноутворення EIP-2537. Первісний пропонент Matter Labs на той час майже вийшов з обговорення. На конференції 203 у січні 2025 року обговорювалося перепризначення цін, розробники Geth запропонували підвищити витрати на газ на 20%, отримавши підтримку команди Besu.

![Спостереження за управлінням Ethereum: Процес передзбирального EIP-2537])https://img-cdn.gateio.im/webp-social/moments-75338d7a495f20ef25a70cca21a48381.webp(

Підсумок

EIP-2537 пройшов довгий шлях у 5 років від моменту його запропонування до прийняття. Він був основою оновлення Berlin, але був залишений через труднощі в реалізації. Потім Ethereum увійшов в історичний процес PoS, де складні чисто виконавчі EIP не отримували уваги, а безліч EIP, пов'язаних з PoS, стали основними цілями, що призвело до того, що EIP-2537 довгий час не приймали. Лише в 2025 році, з вирішенням основних технічних проблем, EIP-2537 нарешті має перспективи реалізації в оновленні Pectra.

Цей процес показує, що чи буде EIP включено в оновлення Ethereum, залежить не лише від його власної технічної цінності, але й потрібно враховувати весь етап розвитку та пріоритети Ethereum. Кожне оновлення має свою тему, і лише ті EIP, які відповідають поточним потребам та є технічно зрілими, можуть бути в кінцевому підсумку прийняті.

![Нагляд за управлінням Ethereum: процес попередньої компіляції EIP-2537])https://img-cdn.gateio.im/webp-social/moments-55d3bb1142078f459d3a41ead42cd599.webp(