Ця стаття в основному розглядає історію управління EIP-2537, досліджуючи, чому цей проект було включено в оновлення лише через 5 років.
Автор: shew
Огляд
EIP-2537 є новою EVM попередньою асемблерною інструкцією, яка була визначена для додавання в останньому оновленні Pectra. Ця інструкція додає до EVM різноманітні обчислювальні функції кривої BLS12-381, такі як обчислення пар на області кривої тощо.
EIP-2573 спочатку був запропонований у 2020 році і не було підтверджено, що він приєднається до оновлення Ethereum до 2025 року. Ця стаття присвячена історії управління 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, який використовується ETH2, починає викликати увагу до виконувального шару ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537 і сподівалися, що ця пропозиція буде протестована на тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс у статті "Що eth2 потрібно від eth1 протягом наступних шести місяців" закликав включити EIP-2537 у жорсткий форк Berlin.
Цікаво, що автор EIP-2537 також є співзасновником Matter Labs, а найвідомішим продуктом Matter Labs є ZKSync.
Берлінська завіса
Перед тим, як перейти до подальшого матеріалу, нам спочатку потрібно представити EIP-1962. EIP-1962 - це перша пропозиція, що стосується попередньої компіляції парування в області еліптичних кривих, яку в квітні 2019 року запропонувала компанія Matter Labs. Ця пропозиція підтримує три криві, а саме:
BLS12
У порівн.
MNT4/6 (Ate pairing)
Цей 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, основні розробники Ethereum обговорили 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 Core Devs Meeting #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 до запланованого часу в Берліні.
Хадсон Джеймсон запропонував знайти криптографічного інженера для Geth, щоб допомогти з перевіркою PR, а також запропонував використовувати тестову мережу для перевірки безпеки реалізації 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 Devs Meeting #92, 2537 все ще підтверджується як EIP, необхідний для оновлення Berlin.
На Ethereum Core Devs Meeting #96 Matter Labs хоче помістити EIP-2539, запропонований одночасно з EIP-2537, в тестову мережу YOLO v2 і увійти в оновлення Berlin, враховуючи, що Celo включила як EIP-2537, так і EIP-2539 в оновлення хардфорка мережі. Однак розробники Geth заперечили, стверджуючи, що поточний EIP-2537 не був повністю протестований у Geth. На останньому засіданні було прийнято рішення не додавати 2696 до модернізації Берліна, залишивши це для майбутнього обговорення.
На зустрічі розробників Ethereum Core Devs Meeting #99 було вирішено вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin, головною причиною цього є те, що EIP-2537 витрачав надто багато часу основних розробників, що призвело до затримки в розробці інших EIP у рамках оновлення Berlin. Вторинним фактором є те, що Фонд Ethereum запропонував EVM384 як альтернативу EIP-2537, EVM 384 пропонує більш універсальне рішення для обчислення еліптичних кривих. Однак основні розробники висловили занепокоєння щодо проблем безпеки під час обговорення на зустрічі.
Це рання історія EIP-2537, який був одним із найважливіших EIP у модернізації Берліна в перші дні, але зрештою був скасований через проблеми з реалізацією. Нарешті, у квітні 2021 року Ethereum завершив оновлення Berlin, і фактичні реалізації, такі як EIP-2565, включені в ядро оновлення, не складні, і здається, що оновлення Berlin трохи тонке, тому що найскладніший EIP-2537 був вигнаний з оновлення Berlin.
!
Подальший розвиток
Як відомо, кожне оновлення Ethereum супроводжується основною пропозицією, наприклад, оновлення London, яке сталося після оновлення Berlin, ввело найважливішу пропозицію щодо комісій за всю історію Ethereum - EIP-1559. Щодо EIP-2537, який колись був основною пропозицією, наступні оновлення мали великі труднощі з включенням цієї пропозиції.
У оновленні Лондона після Берліна розробники в 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 був виключений з оновлення Лондона через складність. Основна складність полягала в тому, що стандартна реалізація 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, яке зосереджене на функції виведення.
Що ще більш трагічно, так це те, що EIP-2537 не обговорювався в оновленні Cancun, тому що суть оновлення Cancun полягає в тому, що вузли виконавчого рівня підтримують EIP-4844. EIP-4844 надає блоби для рівня 2 Ethereum, щоб полегшити Layer 2 використання Ethereum як рівня доступності даних.
Нарешті, на зустрічі Ethereum Core Devs Meeting #181 у лютому 2024 року, розробники обговорили включення EIP-2537 у оновлення Pectra, і на той момент розробники вважали, що реалізація EIP-2537 вже не є проблемою, лише деякі питання стосуються ціноутворення на витрати газу.
На зустрічі розробників Ethereum Core Devs Meeting 19 грудня 2024 року #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, розробники обговорювали, зокрема, перепризначення BLS попередньої компіляції. Розробник Geth Джаред Васінгер запропонував підвищити вартість газу на 20%, і це отримало підтримку команди Besu в рамках бенчмаркінгу.
Підсумок
!
Як видно, чи буде EIP включено в оновлення Ethereum, «звичайно, потрібно покладатися на власні зусилля, але також слід враховувати історичний шлях». Кожне оновлення Ethereum має свою тему, як, наприклад, EIP-2537, яке стало найважливішим EIP оновлення Berlin, але було скасовано через труднощі реалізації та складність. Наступні оновлення Ethereum увійшли в історичний процес PoS, складні EIP виключно для виконання не отримували уваги, тоді як велика кількість EIP, пов'язаних з PoS, вважалася основними цілями оновлення, що призвело до того, що EIP-2537 не приймали протягом тривалого часу.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Спостереження за управлінням Ethereum: процес попередньої компіляції EIP-2537｜Дослідження GCC
Автор: shew
Огляд
EIP-2537 є новою EVM попередньою асемблерною інструкцією, яка була визначена для додавання в останньому оновленні Pectra. Ця інструкція додає до EVM різноманітні обчислювальні функції кривої BLS12-381, такі як обчислення пар на області кривої тощо.
EIP-2573 спочатку був запропонований у 2020 році і не було підтверджено, що він приєднається до оновлення Ethereum до 2025 року. Ця стаття присвячена історії управління 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, який використовується ETH2, починає викликати увагу до виконувального шару ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537 і сподівалися, що ця пропозиція буде протестована на тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс у статті "Що eth2 потрібно від eth1 протягом наступних шести місяців" закликав включити EIP-2537 у жорсткий форк Berlin.
Цікаво, що автор EIP-2537 також є співзасновником Matter Labs, а найвідомішим продуктом Matter Labs є ZKSync.
Берлінська завіса
Перед тим, як перейти до подальшого матеріалу, нам спочатку потрібно представити EIP-1962. EIP-1962 - це перша пропозиція, що стосується попередньої компіляції парування в області еліптичних кривих, яку в квітні 2019 року запропонувала компанія Matter Labs. Ця пропозиція підтримує три криві, а саме:
Цей 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, основні розробники Ethereum обговорили 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 Core Devs Meeting #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 до запланованого часу в Берліні.
Хадсон Джеймсон запропонував знайти криптографічного інженера для Geth, щоб допомогти з перевіркою PR, а також запропонував використовувати тестову мережу для перевірки безпеки реалізації 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 Devs Meeting #92, 2537 все ще підтверджується як EIP, необхідний для оновлення Berlin.
На Ethereum Core Devs Meeting #96 Matter Labs хоче помістити EIP-2539, запропонований одночасно з EIP-2537, в тестову мережу YOLO v2 і увійти в оновлення Berlin, враховуючи, що Celo включила як EIP-2537, так і EIP-2539 в оновлення хардфорка мережі. Однак розробники Geth заперечили, стверджуючи, що поточний EIP-2537 не був повністю протестований у Geth. На останньому засіданні було прийнято рішення не додавати 2696 до модернізації Берліна, залишивши це для майбутнього обговорення.
На зустрічі розробників Ethereum Core Devs Meeting #99 було вирішено вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin, головною причиною цього є те, що EIP-2537 витрачав надто багато часу основних розробників, що призвело до затримки в розробці інших EIP у рамках оновлення Berlin. Вторинним фактором є те, що Фонд Ethereum запропонував EVM384 як альтернативу EIP-2537, EVM 384 пропонує більш універсальне рішення для обчислення еліптичних кривих. Однак основні розробники висловили занепокоєння щодо проблем безпеки під час обговорення на зустрічі.
Це рання історія EIP-2537, який був одним із найважливіших EIP у модернізації Берліна в перші дні, але зрештою був скасований через проблеми з реалізацією. Нарешті, у квітні 2021 року Ethereum завершив оновлення Berlin, і фактичні реалізації, такі як EIP-2565, включені в ядро оновлення, не складні, і здається, що оновлення Berlin трохи тонке, тому що найскладніший EIP-2537 був вигнаний з оновлення Berlin.
!
Подальший розвиток
Як відомо, кожне оновлення Ethereum супроводжується основною пропозицією, наприклад, оновлення London, яке сталося після оновлення Berlin, ввело найважливішу пропозицію щодо комісій за всю історію Ethereum - EIP-1559. Щодо EIP-2537, який колись був основною пропозицією, наступні оновлення мали великі труднощі з включенням цієї пропозиції.
У оновленні Лондона після Берліна розробники в 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 був виключений з оновлення Лондона через складність. Основна складність полягала в тому, що стандартна реалізація 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, яке зосереджене на функції виведення.
Що ще більш трагічно, так це те, що EIP-2537 не обговорювався в оновленні Cancun, тому що суть оновлення Cancun полягає в тому, що вузли виконавчого рівня підтримують EIP-4844. EIP-4844 надає блоби для рівня 2 Ethereum, щоб полегшити Layer 2 використання Ethereum як рівня доступності даних.
Нарешті, на зустрічі Ethereum Core Devs Meeting #181 у лютому 2024 року, розробники обговорили включення EIP-2537 у оновлення Pectra, і на той момент розробники вважали, що реалізація EIP-2537 вже не є проблемою, лише деякі питання стосуються ціноутворення на витрати газу.
На зустрічі розробників Ethereum Core Devs Meeting 19 грудня 2024 року #202 内，Nethermind 开发者最终确定了 EIP-2537 的定价模型。是的，作为 EIP-2537 的最初提案者 Matter Labs 此时已经近乎退出了讨论。在随后的，2025 年 1 月的 Ethereum Core Devs Meeting #203, розробники обговорювали, зокрема, перепризначення BLS попередньої компіляції. Розробник Geth Джаред Васінгер запропонував підвищити вартість газу на 20%, і це отримало підтримку команди Besu в рамках бенчмаркінгу.
Підсумок
!
Як видно, чи буде EIP включено в оновлення Ethereum, «звичайно, потрібно покладатися на власні зусилля, але також слід враховувати історичний шлях». Кожне оновлення Ethereum має свою тему, як, наприклад, EIP-2537, яке стало найважливішим EIP оновлення Berlin, але було скасовано через труднощі реалізації та складність. Наступні оновлення Ethereum увійшли в історичний процес PoS, складні EIP виключно для виконання не отримували уваги, тоді як велика кількість EIP, пов'язаних з PoS, вважалася основними цілями оновлення, що призвело до того, що EIP-2537 не приймали протягом тривалого часу.