EIP-2537: Довгий шлях від суперечок до прийняття

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.

Офіційне впровадження оновлення "Візантія" у жовтні 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 hard fork та визначила графік реалізації в квітні, а тестування в травні-червні. Варто зазначити, що 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-кривими до запуску основної мережі в липні."

Хадсон Джеймсон запропонував знайти криптографічного інженера для Geth для допомоги в рецензуванні PR та запропонував використовувати тестову мережу для перевірки безпеки реалізації EIP-2537. Оскільки команда розробників ETH2 також реалізує верифікацію BLS підписів, вони можуть взяти участь у тестуванні.

Потрібно додати, що реалізація EIP-2537 Geth у PR для забезпечення ефективності широко використовує асемблерний код, цей фрагмент коду дуже важко читати та розуміти. Алекс Власов запропонував прибрати складну асемблерну оптимізацію з 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. Другорядним фактором є те, що Фонд Ethereum запропонував EVM384 як альтернативу EIP-2537, пропонуючи більш універсальне рішення для обчислення еліптичних кривих. Але основні розробники висловили стурбованість щодо питань безпеки.

Це рання історія EIP-2537. Ми можемо бачити, що EIP-2537 спочатку був одним із найважливіших EIP у оновленні Berlin, але через проблеми з реалізацією зрештою був скасований. У квітні 2021 року Ethereum завершив оновлення Berlin, основні EIP, такі як EIP-2565, насправді не є складними для реалізації, оновлення виглядає дещо бідним, це якраз через те, що найскладніший основний EIP-2537 був виключений.

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

Відомо, що кожне оновлення Ethereum супроводжується основною пропозицією. Оновлення London, яке відбулося після Berlin, впровадило найважливішу пропозицію щодо комісій у історії Ethereum EIP-1559. Щодо колишньої основної пропозиції EIP-2537, подальші оновлення навряд чи зможуть включити її.

Під час оновлення Лондона після Берліна, розробники на issues#369 розглядають можливість додати EIP-2537. На 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 як шар доступності даних.

До 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 року: обговорення проблеми витрат на газ, через складність відмовилися від оновлення Лондон.
• Листопад 2022 року: обговорення питання про включення оновлення Shanghai, безрезультатно
• Лютий 2024 року: вважається, що реалізація більше не є проблемою, однак залишаються певні проблеми з витратами на газ, які можуть бути включені в оновлення Pectra.
• Грудень 2024 - Січень 2025: обговорення конкретної моделі розрахунку витрат, офіційне вирішення витрат на газ