EIP-2537 є останньою EVM попередньою інструкцією, яка була визначена для додавання в оновленні Pectra. Ця інструкція додає до EVM різні обчислювальні функції BLS12-381, такі як обчислення пар на області кривої.
EIP-2573 був вперше запропонований у 2020 році, і тільки у 2025 році був підтверджений для включення в оновлення Ethereum. У цій статті основна увага приділяється історії управління EIP-2537, досліджуючи, чому цей проєкт був включений в оновлення лише через 5 років.
Тло пропозиції
У січні 2017 року Віталік Бутерін вперше представив алгоритм парування та криву alt_bn128 на конференції Exploring Elliptic Curve Pairings. Після цього, у лютому 2017 року, Віталік Бутерін та Крістіан Рейтвіснер запропонували пропозиції EIP-196 та EIP-197, які містять пропозицію про додавання підтримки обчислень з кривою alt_bn128 до EVM.
У жовтні 2017 року під час оновлення Byzantium офіційно була впроваджена крива alt_bn128. Простими словами, alt_bn128 вперше реалізувала обчислення парування в полях кривих всередині EVM, що дозволило верифікацію доказів ZK-Snarks виконувати всередині EVM.
Але з розвитком криптографії, у листопаді 2017 року, команда розробників zcash вперше представила криву BLS12-381 у статті BLS12-381: New zk-SNARK Elliptic Curve Construction. Порівняно з alt_bn128, BLS12-381 має вищий рівень безпеки та кращу продуктивність. Значна кількість блокчейн-протоколів після цього використала криву BLS12-381, відмовившись від кривої alt_bn128.
У травні 2018 року Джастін Дрейк опублікував статтю "Pragmatic signature aggregation with BLS" на ethresear, в якій вказав, що в майбутніх оновленнях PoS та шардінгу Ethereum можна використовувати алгоритм BLS мультипідпису на основі кривої BLS12-381. На той час дослідники Ethereum сподівалися вирішити проблему рівня консенсусу за допомогою EIP-1011, але рішення EIP-1011 могло вмістити максимум 900 валідаторів, тому для кожного валідатора було встановлено величезний обсяг стейкінгу в 1500 ETH. З появою схеми BLS мультипідпису EIP-1011 вийшло з історичної сцени. Як виявилося, пізніші оновлення ETH2 також в кінцевому підсумку використовували криву BLS12-381.
У зв'язку з розробкою ETH2, що використовується BLS12-381, почали закликати до включення в шар виконання ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537 і сподіваються, що ця пропозиція буде прийнята для тестування в тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс у статті "Що ETH2 потрібно від ETH1 протягом наступних шести місяців" закликав включити EIP-2537 у жорстке розгалуження Berlin.
Цікаво, що автор EIP-2537 також є співзасновником компанії Matter Labs, яка найбільш відома своїм продуктом ZKSync
Берлін нестабільність
Перед тим, як перейти до подальшого матеріалу, нам потрібно спочатку представити EIP-1962. EIP-1962 — це перша пропозиція про попереднє складання пар на полях еліптичних кривих, яку Matter Labs представила у квітні 2019 року. Ця пропозиція підтримує три криві, а саме:
BLS12
У порівн.
MNT4/6 (Ate парування)
Цей EIP готує одноразове додавання 10 попередньо скомпільованих інструкцій для обробки різних кривих. Однак після появи цієї пропозиції чимало розробників поставили під сумнів, що пропозиція є занадто складною, щоб розробникам було легко реалізувати її. Одночасно, через високу узагальненість EIP1962, виклики є досить клопіткими для інженерів смарт-контрактів. Звичайно, як автор EIP-1962, Matter Labs фактично вже завершила розробку алгоритму еліптичних кривих і надала референсні реалізації на Rust / Go / C++.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонували кілька EIP, які розділяють EIP-1962, ці EIP частково успадковують інтерфейс EIP-1962. Ці EIP включають:
EIP-2537 надає підтримку BLS12-381
EIP-2539 надає підтримку BLS12-377
PR#2541 надає підтримку кривої BLS12-377 (Zexe curve), але зверніть увагу, що ця пропозиція в підсумку не отримала номер EIP і не може бути знайдена на офіційному веб-сайті документації EIP.
Найважливішим з цих EIP є EIP-2537, оскільки на рівні консенсусу також використовується крива BLS12-381. Основною метою EIP-1962 та EIP-2537 є реалізація перевірки підписів BLS на рівні консенсусу в основній мережі. У той час ETH2 розробляла дизайн депозитного контракту для рівня консенсусу. Коли депозитний контракт був спочатку розроблений, оскільки рівень виконання не містить алгоритму перевірки BLS, депозитний контракт не перевірятиме підпис, конкретний підпис BLS буде перевірено на рівні консенсусу після того, як користувач внесе депозит, якщо він виявиться неправильним (для нових валідаторів), депозит не відбудеться, і внесені користувачем ETH будуть втрачені.
У цьому контексті основні розробники прагнуть впровадити BLS12-381 передкомпіляцію для реалізації перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів, які вносять ETH2. Це також була причина, чому тоді багато розробників звертали увагу на EIP-1962 та EIP-2537.
Коли EIP-2537 тільки-но було запропоновано, Віталік відразу виявив ряд проблем, пов'язаних з EIP:
Ці сумніви були зосереджені лише на змісті документації EIP, після чого автори EIP відповіли на них і обговорили. Потім, 6 березня 2020 року, на зустрічі Ethereum Core Devs Meeting #82 обговорили EIP-2537. На цій зустрічі Віталік вважав, що EIP-2537 та інші EIP дуже ефективні для рекурсивних SNARK-доказів і в довгостроковій перспективі не завдадуть шкоди Ethereum. Крім того, на зустрічі було підтверджено пріоритет EIP-2537, всі клієнти погодилися якомога швидше реалізувати EIP-2537 і запланували завершити всю розробку до оновлення Berlin.
Потім EIP-2537 став завданням з високим пріоритетом. 20 березня 2020 року, на зустрічі Ethereum Core Devs Meeting #83, EIP-2537 знову був першим обговорюваним пропозицією. Ця зустріч підтвердила, що EIP-2537 замінює EIP-1962 як основну BLS пропозицію і стає попереднім списком EIP для оновлення Berlin (, тобто Eligibility for Inclusion (EFI)).
На засіданні Ethereum Core Devs Meeting #84 у квітні 2020 року, на зустрічі офіційно було включено EIP-2537 до оновлення Berlin Hard Fork, а також визначено графік реалізації оновлення Berlin на квітень та тестування в травні - червні. Варто зазначити, що під час цього обговорення EIP-2537 було віднесено до найбільш пріоритетних питань.
Потім EIP-2537 перейшов до великої кількості етапів розробки та тестування, і в наступних майже 20 зустрічах основних розробників на кожному з них обговорювалося питання EIP-2537. Далі ми можемо подивитися, які питання щодо EIP-2537 обговорювалися на кожній зустрічі.
На зустрічі розробників ядра Ethereum #85, Дanno та Axic обговорили питання кодування ABI для EIP-2537. Після цього основні розробники синхронізували поточний стан реалізації, при цьому, оскільки автор пропозиції EIP-2537 Matter Labs вже в основному завершив реалізацію версії на Rust, клієнт Besu оголосив, що функціональність EIP-2537 в основному реалізована, але з боку Geth повідомили, що наразі ніхто не працює над реалізацією EIP-2537.
На зустрічі Ethereum Core Devs Meeting #86 різні реалізації вузлів Ethereum знову синхронізували стан реалізації EIP-2537, де Geth повідомив, що частина роботи виконана, але ще залишилося багато роботи.
На зустрічі розробників Ethereum Core Devs Meeting #87 основною темою обговорення було питання реалізації EIP-2537. Розробники Geth зазначили, що наразі існує PR на 16000 рядків, що реалізує EIP-2537, але розробники Geth не можуть бути впевнені, чи є PR безпечним та ефективно реалізує EIP-2537, тому розробники могли лише використовувати найпростіший і грубий метод – нечітке тестування, щоб оцінити стан коду.
Розробник Geth сказав: "Отже, моя інтуїтивна реакція полягає в тому, що немає жодних шансів, що Geth буде готовий з операціями BLS кривих до запуску основної мережі в липні.", тобто Geth, швидше за все, не зможе завершити відповідну розробку EIP-2537 до запланованого часу в Берліні.
Хадсон Джеймсон запропонував знайти криптографічних інженерів для допомоги в рецензуванні PR для Geth, а також запропонував використовувати тестову мережу для перевірки безпеки реалізації EIP-2537. Оскільки на той момент команда розробників ETH2 також реалізовувала перевірку підписів BLS, команда ETH2 може взяти участь у тестуванні.
Тут ми повинні додати деякі фонова інформація, що реалізація PR EIP-2537 Geth використовує велику кількість асемблерного коду для забезпечення ефективності, і ця частина асемблерного коду дуже важка для читання та розуміння. Тому Алекс Власов запропонував прибрати складну оптимізацію асемблера всередині PR, щоб зменшити складність перевірки.
У попередньому тексті ми вже згадували, що однією з ключових цілей EIP-2537 є сприяння контракту депозиту ETH2, але на цій зустрічі розробники контракту депозиту заявили, що контракт депозиту, який не використовує EIP-2537, вже пройшов аудит, тому деякі розробники висловили пропозицію, що краще не запускати контракт депозиту, який використовує EIP-2537.
Врешті-решт, на засіданні було вирішено додати тестову мережу YOLO, основою якої є тестування EIP-2537. Насправді, на цьому засіданні ми можемо побачити, що важливість EIP-2537 значно знизилася з завершенням депозитного контракту, в той час як розробники Geth вже вважають, що цей EIP, швидше за все, не буде реалізований до оновлення Berlin. Схоже, що EIP-2537 не буде прийнятий в оновлення Berlin.
На зустрічі розробників Ethereum Core Devs Meeting #88 розробники Geth виявили низку проблем у реалізації PR EIP-2537, розробники зазначили, що потрібно подальше тестування та виправлення. На той момент у системі Geth існували дві реалізації EIP-2537, одна з яких містила оптимізацію асемблера, а інша була повністю написана мовою go, один з розробників запропонував безпосередньо використовувати версію, написану мовою go, щоб знизити складність перевірки коду.
На зустрічі розробників Ethereum Core Devs Meeting #89 виникла ще серйозніша проблема: тест YOLO виявив деякі несправності, розробники підозрюють, що це пов'язано з підписами BLS, але розробники EIP2537 спростували це, стверджуючи, що проблеми з тестовою мережею не викликані підписами BLS. Хороша новина для EIP-2537 полягає в тому, що контракт на депозит, заснований на EIP-2537, практично завершено, і він чекає на аудит контракту.
На зустрічі Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 один з розробників запропонував використати модульне рішення для зниження витрат на розробку з метою збільшення різноманітності клієнтів. Якщо читачі зацікавлені в різноманітності клієнтів Ethereum, вони можуть ознайомитися з записами цих двох зустрічей.
На засіданні розробників Ethereum Core #92 EIP 2537 все ще підтверджується як необхідний для оновлення Berlin.
На зустрічі розробників Ethereum Core Devs Meeting #96, на базі Celo вже були одночасно включені EIP-2537 та EIP-2539 до оновлення мережі з хардфорком, тому Matter Labs сподівається, що EIP-2539, який був запропонований одночасно з EIP-2537, також буде протестований на тестовій мережі YOLO v2 та увійде до оновлення Berlin. Однак розробники Geth виступили проти, вважаючи, що поточний EIP-2537 все ще не пройшов повного тестування в Geth. Врешті-решт, на нараді було вирішено не додавати 2696 до оновлення Berlin, залишивши це на майбутнє обговорення.
#99内 Ethereum Core Devs Meeting було прийнято рішення перенести EIP-2537 з тестової мережі YOLO v3 і оновлення Berlin, основна причина полягала в тому, що EIP-2537 витрачав занадто багато часу для основних розробників і перешкоджав розробці інших EIP в рамках оновлення Berlin. Другорядним фактором є те, що Ethereum Foundation запропонував EVM384 як заміну EIP-2537, який забезпечує більш загальне рішення для обчислення еліптичних кривих. Однак основні розробники висловили занепокоєння щодо безпеки під час обговорень на конференції.
Вищезазначене є ранньою історією EIP-2537. Ми можемо побачити, що EIP-2537 на початку був одним з найважливіших EIP у оновленні Berlin, але через проблеми з реалізацією в кінцевому підсумку був скасований. Нарешті, у квітні 2021 року Ethereum завершив оновлення Berlin, в якому основні EIP, такі як EIP-2565, насправді не були складними для реалізації. Здається, що оновлення Berlin виглядає дещо бідним, оскільки найскладніший і найважливіший EIP-2537 був виключений з оновлення Berlin.
подальший розвиток
Як всім відомо, кожне оновлення Ethereum має основну пропозицію, наприклад, оновлення London, яке відбулося після оновлення Berlin, впровадило найважливішу пропозицію щодо комісій за всю історію Ethereum EIP-1559. Що стосується EIP-2537, яка колись була основною пропозицією, наступні оновлення з трудом можуть включити цю пропозицію.
Під час оновлення London після Berlin, розробники в issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109 синхронізували поточний стан розробки EIP-2537. У цей час, через використання інших бібліотек для реалізації EIP-2537, виникла дискусія щодо використання газу для EIP-2537. Одночасно деякі розробники запропонували замінити EIP-2537 на EVM384. Однак на зустрічі Ethereum Core Devs Meeting #111 у квітні 2021 року EIP-2537 був виключений з оновлення London через складність. Основна складність полягає в тому, що стандартна реалізація EIP-2537 змінила залежні бібліотеки, що може призвести до змін у ціноутворенні газу, і різним реалізаціям клієнтів потрібно буде витратити значний час на повторну оцінку споживання газу.
У червні 2021 року в issues#343 офіційно було запропоновано включити EIP-2537 до оновлення Shanghai. Однак слід зазначити, що після оновлення London фактично оновлення Pairs, або, як його ще називають, The Merge, зайняло багато часу розробників, і розробникам виконавчого рівня потрібно було написати велику кількість коду для реалізації PoS-оновлення. У вересні 2022 року оновлення Pairs було завершено, і розробники виконавчого рівня нарешті отримали можливість продовжити обговорення деяких цілей оновлення Shanghai.
У листопаді 2022 року на зустрічі розробників Ethereum Core Devs Meeting #150 коротко обговорювалося питання включення EIP-2537 до оновлення Shanghai, але розробники вирішили відкласти EIP-2537, оскільки основним завданням оновлення Shanghai є підтримка виведення PoS. Врешті-решт, EIP-2537 не був включений до внутрішнього оновлення Shanghai, яке має на меті реалізацію функції виведення.
Ще гірше, що під час оновлення Cancun не було обговорено EIP-2537, оскільки основою оновлення Cancun є підтримка EIP-4844 виконавчими вузлами. EIP-4844 забезпечує Blob для другого рівня Ethereum, щоб полегшити використання Ethereum як шару доступності даних для другого рівня.
Нарешті, на зустрічі Ethereum Core Devs Meeting #181 у лютому 2024 року, розробники обговорили включення EIP-2537 у оновлення Pectra, і на цей момент розробники вважали, що реалізація EIP-2537 більше не є проблемою, лише деякі питання залишалися в аспекті ціноутворення газу.
На зустрічі розробників ядерної команди Ethereum 19 грудня 2024 року #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203 розробники обговорили, зокрема, перепризначення BLS попередньо скомпільованого коду. Розробник Geth Джаред Васінгер запропонував підвищити вартість газу на 20%, і це було підтримано командою Besu в тестуванні.
підсумок
| Дата | Подія |
| --- | --- |
| Лютий 2020 року | Офіційно запропоновано EIP-1962 та розділено EIP-2537 |
| Квітень 2020 - Жовтень 2020 | На декількох зустрічах розробників обговорювались проблеми реалізації EIP-2537, і врешті-решт його було відкинуто через неможливість реалізації в оновленні Berlin |
| березень 2021 - квітень 2021 | Обговорення проблеми вартості газу EIP-2537 на конференції розробників, врешті-решт відмовлено через складність у результаті оновлення London |
| Листопад 2022 року | Обговорення на конференції розробників щодо включення оновлення Shanghai, безрезультатно |
| Лютий 2024 року | Розробники вважають, що EIP-2537 не має жодних проблем з реалізацією, однак існують деякі проблеми з витратами на газ, і вважають, що його можна включити в оновлення Pectra |
| Грудень 2024 - Січень 2025 | Обговорення конкретних моделей розрахунку витрат на конференції розробників, офіційне вирішення проблеми витрат EIP-2537 |
Отже, чи буде EIP включено в оновлення Ethereum, "звичайно, це залежить від власних зусиль, але також потрібно враховувати історичний процес". Кожне оновлення Ethereum має свою власну тему, як EIP-2537 колись став найважливішим EIP для оновлення Berlin, але через його складність та важкість реалізації був відхилений. Наступний етап Ethereum перейшов до історичного процесу PoS, де складні EIP, що стосуються чистого виконавчого шару, не отримали уваги, а велика кількість EIP, пов'язаних з PoS, була визнана основними цілями оновлення, що призвело до того, що EIP-2537 не приймався протягом тривалого часу.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Ethereum управлінський огляд: EIP-2537 попередня компіляція
Автор: shew
Огляд
EIP-2537 є останньою EVM попередньою інструкцією, яка була визначена для додавання в оновленні Pectra. Ця інструкція додає до EVM різні обчислювальні функції BLS12-381, такі як обчислення пар на області кривої.
EIP-2573 був вперше запропонований у 2020 році, і тільки у 2025 році був підтверджений для включення в оновлення Ethereum. У цій статті основна увага приділяється історії управління EIP-2537, досліджуючи, чому цей проєкт був включений в оновлення лише через 5 років.
Тло пропозиції
У січні 2017 року Віталік Бутерін вперше представив алгоритм парування та криву
alt_bn128на конференції Exploring Elliptic Curve Pairings. Після цього, у лютому 2017 року, Віталік Бутерін та Крістіан Рейтвіснер запропонували пропозиції EIP-196 та EIP-197, які містять пропозицію про додавання підтримки обчислень з кривоюalt_bn128до EVM.У жовтні 2017 року під час оновлення Byzantium офіційно була впроваджена крива
alt_bn128. Простими словами,alt_bn128вперше реалізувала обчислення парування в полях кривих всередині EVM, що дозволило верифікацію доказів ZK-Snarks виконувати всередині EVM.Але з розвитком криптографії, у листопаді 2017 року, команда розробників zcash вперше представила криву
BLS12-381у статті BLS12-381: New zk-SNARK Elliptic Curve Construction. Порівняно зalt_bn128,BLS12-381має вищий рівень безпеки та кращу продуктивність. Значна кількість блокчейн-протоколів після цього використала кривуBLS12-381, відмовившись від кривоїalt_bn128.У травні 2018 року Джастін Дрейк опублікував статтю "Pragmatic signature aggregation with BLS" на ethresear, в якій вказав, що в майбутніх оновленнях PoS та шардінгу Ethereum можна використовувати алгоритм BLS мультипідпису на основі кривої
BLS12-381. На той час дослідники Ethereum сподівалися вирішити проблему рівня консенсусу за допомогою EIP-1011, але рішення EIP-1011 могло вмістити максимум 900 валідаторів, тому для кожного валідатора було встановлено величезний обсяг стейкінгу в 1500 ETH. З появою схеми BLS мультипідпису EIP-1011 вийшло з історичної сцени. Як виявилося, пізніші оновлення ETH2 також в кінцевому підсумку використовували кривуBLS12-381.У зв'язку з розробкою ETH2, що використовується
BLS12-381, почали закликати до включення в шар виконання ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537 і сподіваються, що ця пропозиція буде прийнята для тестування в тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс у статті "Що ETH2 потрібно від ETH1 протягом наступних шести місяців" закликав включити EIP-2537 у жорстке розгалуження Berlin.Цікаво, що автор EIP-2537 також є співзасновником компанії Matter Labs, яка найбільш відома своїм продуктом ZKSync
Берлін нестабільність
Перед тим, як перейти до подальшого матеріалу, нам потрібно спочатку представити EIP-1962. EIP-1962 — це перша пропозиція про попереднє складання пар на полях еліптичних кривих, яку Matter Labs представила у квітні 2019 року. Ця пропозиція підтримує три криві, а саме:
Цей EIP готує одноразове додавання 10 попередньо скомпільованих інструкцій для обробки різних кривих. Однак після появи цієї пропозиції чимало розробників поставили під сумнів, що пропозиція є занадто складною, щоб розробникам було легко реалізувати її. Одночасно, через високу узагальненість EIP1962, виклики є досить клопіткими для інженерів смарт-контрактів. Звичайно, як автор EIP-1962, Matter Labs фактично вже завершила розробку алгоритму еліптичних кривих і надала референсні реалізації на Rust / Go / C++.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонували кілька EIP, які розділяють EIP-1962, ці EIP частково успадковують інтерфейс EIP-1962. Ці EIP включають:
Найважливішим з цих EIP є EIP-2537, оскільки на рівні консенсусу також використовується крива BLS12-381. Основною метою EIP-1962 та EIP-2537 є реалізація перевірки підписів BLS на рівні консенсусу в основній мережі. У той час ETH2 розробляла дизайн депозитного контракту для рівня консенсусу. Коли депозитний контракт був спочатку розроблений, оскільки рівень виконання не містить алгоритму перевірки BLS, депозитний контракт не перевірятиме підпис, конкретний підпис BLS буде перевірено на рівні консенсусу після того, як користувач внесе депозит, якщо він виявиться неправильним (для нових валідаторів), депозит не відбудеться, і внесені користувачем ETH будуть втрачені.
У цьому контексті основні розробники прагнуть впровадити BLS12-381 передкомпіляцію для реалізації перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів, які вносять ETH2. Це також була причина, чому тоді багато розробників звертали увагу на EIP-1962 та EIP-2537.
Коли EIP-2537 тільки-но було запропоновано, Віталік відразу виявив ряд проблем, пов'язаних з EIP:
Ці сумніви були зосереджені лише на змісті документації EIP, після чого автори EIP відповіли на них і обговорили. Потім, 6 березня 2020 року, на зустрічі Ethereum Core Devs Meeting #82 обговорили EIP-2537. На цій зустрічі Віталік вважав, що EIP-2537 та інші EIP дуже ефективні для рекурсивних SNARK-доказів і в довгостроковій перспективі не завдадуть шкоди Ethereum. Крім того, на зустрічі було підтверджено пріоритет EIP-2537, всі клієнти погодилися якомога швидше реалізувати EIP-2537 і запланували завершити всю розробку до оновлення Berlin.
Потім EIP-2537 став завданням з високим пріоритетом. 20 березня 2020 року, на зустрічі Ethereum Core Devs Meeting #83, EIP-2537 знову був першим обговорюваним пропозицією. Ця зустріч підтвердила, що EIP-2537 замінює EIP-1962 як основну BLS пропозицію і стає попереднім списком EIP для оновлення Berlin (, тобто Eligibility for Inclusion (EFI)).
На засіданні Ethereum Core Devs Meeting #84 у квітні 2020 року, на зустрічі офіційно було включено EIP-2537 до оновлення Berlin Hard Fork, а також визначено графік реалізації оновлення Berlin на квітень та тестування в травні - червні. Варто зазначити, що під час цього обговорення EIP-2537 було віднесено до найбільш пріоритетних питань.
Потім EIP-2537 перейшов до великої кількості етапів розробки та тестування, і в наступних майже 20 зустрічах основних розробників на кожному з них обговорювалося питання EIP-2537. Далі ми можемо подивитися, які питання щодо EIP-2537 обговорювалися на кожній зустрічі.
На зустрічі розробників ядра Ethereum #85, Дanno та Axic обговорили питання кодування ABI для EIP-2537. Після цього основні розробники синхронізували поточний стан реалізації, при цьому, оскільки автор пропозиції EIP-2537 Matter Labs вже в основному завершив реалізацію версії на Rust, клієнт Besu оголосив, що функціональність EIP-2537 в основному реалізована, але з боку Geth повідомили, що наразі ніхто не працює над реалізацією EIP-2537.
На зустрічі Ethereum Core Devs Meeting #86 різні реалізації вузлів Ethereum знову синхронізували стан реалізації EIP-2537, де Geth повідомив, що частина роботи виконана, але ще залишилося багато роботи.
На зустрічі розробників Ethereum Core Devs Meeting #87 основною темою обговорення було питання реалізації EIP-2537. Розробники Geth зазначили, що наразі існує PR на 16000 рядків, що реалізує EIP-2537, але розробники Geth не можуть бути впевнені, чи є PR безпечним та ефективно реалізує EIP-2537, тому розробники могли лише використовувати найпростіший і грубий метод – нечітке тестування, щоб оцінити стан коду.
Розробник Geth сказав: "Отже, моя інтуїтивна реакція полягає в тому, що немає жодних шансів, що Geth буде готовий з операціями BLS кривих до запуску основної мережі в липні.", тобто Geth, швидше за все, не зможе завершити відповідну розробку EIP-2537 до запланованого часу в Берліні.
Хадсон Джеймсон запропонував знайти криптографічних інженерів для допомоги в рецензуванні PR для Geth, а також запропонував використовувати тестову мережу для перевірки безпеки реалізації EIP-2537. Оскільки на той момент команда розробників ETH2 також реалізовувала перевірку підписів BLS, команда ETH2 може взяти участь у тестуванні.
Тут ми повинні додати деякі фонова інформація, що реалізація PR EIP-2537 Geth використовує велику кількість асемблерного коду для забезпечення ефективності, і ця частина асемблерного коду дуже важка для читання та розуміння. Тому Алекс Власов запропонував прибрати складну оптимізацію асемблера всередині PR, щоб зменшити складність перевірки.
У попередньому тексті ми вже згадували, що однією з ключових цілей EIP-2537 є сприяння контракту депозиту ETH2, але на цій зустрічі розробники контракту депозиту заявили, що контракт депозиту, який не використовує EIP-2537, вже пройшов аудит, тому деякі розробники висловили пропозицію, що краще не запускати контракт депозиту, який використовує EIP-2537.
Врешті-решт, на засіданні було вирішено додати тестову мережу YOLO, основою якої є тестування EIP-2537. Насправді, на цьому засіданні ми можемо побачити, що важливість EIP-2537 значно знизилася з завершенням депозитного контракту, в той час як розробники Geth вже вважають, що цей EIP, швидше за все, не буде реалізований до оновлення Berlin. Схоже, що EIP-2537 не буде прийнятий в оновлення Berlin.
На зустрічі розробників Ethereum Core Devs Meeting #88 розробники Geth виявили низку проблем у реалізації PR EIP-2537, розробники зазначили, що потрібно подальше тестування та виправлення. На той момент у системі Geth існували дві реалізації EIP-2537, одна з яких містила оптимізацію асемблера, а інша була повністю написана мовою go, один з розробників запропонував безпосередньо використовувати версію, написану мовою go, щоб знизити складність перевірки коду.
На зустрічі розробників Ethereum Core Devs Meeting #89 виникла ще серйозніша проблема: тест YOLO виявив деякі несправності, розробники підозрюють, що це пов'язано з підписами BLS, але розробники EIP2537 спростували це, стверджуючи, що проблеми з тестовою мережею не викликані підписами BLS. Хороша новина для EIP-2537 полягає в тому, що контракт на депозит, заснований на EIP-2537, практично завершено, і він чекає на аудит контракту.
На зустрічі Ethereum Core Devs Meeting #90内，这次会议锁定了 7 月份上线 Berlin 升级的 DDL。当然，这次会议另一个有趣的论点是客户端多样性问题，在此次会议中，开发者主要讨论了 Geth 占据主导地位的情况，并且有开发者提议冻结当前 EIP 实现来降低其他客户端的开发成本。更加有趣的是，在 #91 один з розробників запропонував використати модульне рішення для зниження витрат на розробку з метою збільшення різноманітності клієнтів. Якщо читачі зацікавлені в різноманітності клієнтів Ethereum, вони можуть ознайомитися з записами цих двох зустрічей.
На засіданні розробників Ethereum Core #92 EIP 2537 все ще підтверджується як необхідний для оновлення Berlin.
На зустрічі розробників Ethereum Core Devs Meeting #96, на базі Celo вже були одночасно включені EIP-2537 та EIP-2539 до оновлення мережі з хардфорком, тому Matter Labs сподівається, що EIP-2539, який був запропонований одночасно з EIP-2537, також буде протестований на тестовій мережі YOLO v2 та увійде до оновлення Berlin. Однак розробники Geth виступили проти, вважаючи, що поточний EIP-2537 все ще не пройшов повного тестування в Geth. Врешті-решт, на нараді було вирішено не додавати 2696 до оновлення Berlin, залишивши це на майбутнє обговорення.
#99内 Ethereum Core Devs Meeting було прийнято рішення перенести EIP-2537 з тестової мережі YOLO v3 і оновлення Berlin, основна причина полягала в тому, що EIP-2537 витрачав занадто багато часу для основних розробників і перешкоджав розробці інших EIP в рамках оновлення Berlin. Другорядним фактором є те, що Ethereum Foundation запропонував EVM384 як заміну EIP-2537, який забезпечує більш загальне рішення для обчислення еліптичних кривих. Однак основні розробники висловили занепокоєння щодо безпеки під час обговорень на конференції.
Вищезазначене є ранньою історією EIP-2537. Ми можемо побачити, що EIP-2537 на початку був одним з найважливіших EIP у оновленні Berlin, але через проблеми з реалізацією в кінцевому підсумку був скасований. Нарешті, у квітні 2021 року Ethereum завершив оновлення Berlin, в якому основні EIP, такі як EIP-2565, насправді не були складними для реалізації. Здається, що оновлення Berlin виглядає дещо бідним, оскільки найскладніший і найважливіший EIP-2537 був виключений з оновлення Berlin.
подальший розвиток
Як всім відомо, кожне оновлення Ethereum має основну пропозицію, наприклад, оновлення London, яке відбулося після оновлення Berlin, впровадило найважливішу пропозицію щодо комісій за всю історію Ethereum EIP-1559. Що стосується EIP-2537, яка колись була основною пропозицією, наступні оновлення з трудом можуть включити цю пропозицію.
Під час оновлення London після Berlin, розробники в issues#369曾考虑在 London 升级中增加 EIP-2537。在Ethereum Core Devs Meeting #109 синхронізували поточний стан розробки EIP-2537. У цей час, через використання інших бібліотек для реалізації EIP-2537, виникла дискусія щодо використання газу для EIP-2537. Одночасно деякі розробники запропонували замінити EIP-2537 на EVM384. Однак на зустрічі Ethereum Core Devs Meeting #111 у квітні 2021 року EIP-2537 був виключений з оновлення London через складність. Основна складність полягає в тому, що стандартна реалізація EIP-2537 змінила залежні бібліотеки, що може призвести до змін у ціноутворенні газу, і різним реалізаціям клієнтів потрібно буде витратити значний час на повторну оцінку споживання газу.
У червні 2021 року в issues#343 офіційно було запропоновано включити EIP-2537 до оновлення Shanghai. Однак слід зазначити, що після оновлення London фактично оновлення Pairs, або, як його ще називають, The Merge, зайняло багато часу розробників, і розробникам виконавчого рівня потрібно було написати велику кількість коду для реалізації PoS-оновлення. У вересні 2022 року оновлення Pairs було завершено, і розробники виконавчого рівня нарешті отримали можливість продовжити обговорення деяких цілей оновлення Shanghai.
У листопаді 2022 року на зустрічі розробників Ethereum Core Devs Meeting #150 коротко обговорювалося питання включення EIP-2537 до оновлення Shanghai, але розробники вирішили відкласти EIP-2537, оскільки основним завданням оновлення Shanghai є підтримка виведення PoS. Врешті-решт, EIP-2537 не був включений до внутрішнього оновлення Shanghai, яке має на меті реалізацію функції виведення.
Ще гірше, що під час оновлення Cancun не було обговорено EIP-2537, оскільки основою оновлення Cancun є підтримка EIP-4844 виконавчими вузлами. EIP-4844 забезпечує Blob для другого рівня Ethereum, щоб полегшити використання Ethereum як шару доступності даних для другого рівня.
Нарешті, на зустрічі Ethereum Core Devs Meeting #181 у лютому 2024 року, розробники обговорили включення EIP-2537 у оновлення Pectra, і на цей момент розробники вважали, що реалізація EIP-2537 більше не є проблемою, лише деякі питання залишалися в аспекті ціноутворення газу.
На зустрічі розробників ядерної команди Ethereum 19 грудня 2024 року #202内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的Ethereum Core Devs Meeting #203 розробники обговорили, зокрема, перепризначення BLS попередньо скомпільованого коду. Розробник Geth Джаред Васінгер запропонував підвищити вартість газу на 20%, і це було підтримано командою Besu в тестуванні.
підсумок
| Дата | Подія | | --- | --- | | Лютий 2020 року | Офіційно запропоновано EIP-1962 та розділено EIP-2537 | | Квітень 2020 - Жовтень 2020 | На декількох зустрічах розробників обговорювались проблеми реалізації EIP-2537, і врешті-решт його було відкинуто через неможливість реалізації в оновленні Berlin | | березень 2021 - квітень 2021 | Обговорення проблеми вартості газу EIP-2537 на конференції розробників, врешті-решт відмовлено через складність у результаті оновлення London | | Листопад 2022 року | Обговорення на конференції розробників щодо включення оновлення Shanghai, безрезультатно | | Лютий 2024 року | Розробники вважають, що EIP-2537 не має жодних проблем з реалізацією, однак існують деякі проблеми з витратами на газ, і вважають, що його можна включити в оновлення Pectra | | Грудень 2024 - Січень 2025 | Обговорення конкретних моделей розрахунку витрат на конференції розробників, офіційне вирішення проблеми витрат EIP-2537 |
Отже, чи буде EIP включено в оновлення Ethereum, "звичайно, це залежить від власних зусиль, але також потрібно враховувати історичний процес". Кожне оновлення Ethereum має свою власну тему, як EIP-2537 колись став найважливішим EIP для оновлення Berlin, але через його складність та важкість реалізації був відхилений. Наступний етап Ethereum перейшов до історичного процесу PoS, де складні EIP, що стосуються чистого виконавчого шару, не отримали уваги, а велика кількість EIP, пов'язаних з PoS, була визнана основними цілями оновлення, що призвело до того, що EIP-2537 не приймався протягом тривалого часу.