EIP-2537 є останньою EVM попередньо скомпільованою інструкцією, яка була визначена для додавання під час недавнього оновлення Pectra. Ця інструкція додає до EVM різні обчислювальні функції кривої BLS12-381, включаючи обчислення пар на області кривої тощо.
EIP-2573 спочатку був представлений у 2020 році, а лише у 2025 році був підтверджений для включення в оновлення Ethereum. У цій статті буде представлено процес управління EIP-2537, а також обговорено, чому знадобилося 5 років, щоб включити цю пропозицію в оновлення.
Фон пропозиції
У січні 2017 року Віталік Бутерин вперше представив алгоритм парування та криву alt_bn128. Пізніше Віталік та Крістіан Рейтвіссер запропонували EIP-196 та EIP-197, щоб додати підтримку обчислень кривої alt_bn128 до EVM. В жовтні 2017 року оновлення Byzantium офіційно включило криву alt_bn128, реалізувавши обчислення парування в полях кривих всередині EVM, що дозволило виконувати перевірку доказів ZK-Snarks безпосередньо в EVM.
У листопаді 2017 року команда zcash запропонувала криву BLS12-381, яка має вищу безпеку та продуктивність у порівнянні з alt_bn128. Багато блокчейн-протоколів згодом прийняли криву BLS12-381, відмовившись від кривої alt_bn128.
У травні 2018 року Джастін Дрейк зазначив, що майбутнє PoS та шардінгового оновлення Ethereum може використовувати алгоритм BLS мультипідпису на основі кривої BLS12-381. Це призвело до того, що попередній план EIP-1011 вийшов з історичної сцени, а пізніше оновлення ETH2 також врешті-решт використало криву BLS12-381.
З розвитком ETH2 зростає голос за впровадження BLS12-381 на виконавчий рівень ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537, сподіваючись протестувати його на тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс закликав включити його до Берлінського хардфорку.
Цікаво, що автор EIP-2537 є також співзасновником Matter Labs, найбільш відомим продуктом якого є ZKSync.
Перед тим, як представити подальший зміст, потрібно спочатку згадати EIP-1962. Це перша пропозиція попередньо скомпільованого парного алгоритму еліптичних кривих, запропонована Matter Labs у квітні 2019 року, яка підтримує три криві: BLS12, BN та MNT4/6. Цей EIP планує одноразово додати 10 попередньо скомпільованих інструкцій для обробки різних кривих. Проте багато розробників ставлять під сумнів, що пропозиція є занадто складною для реалізації, а також незручною для використання інженерами смарт-контрактів. Як сторона пропозиції, Matter Labs завершила розробку алгоритму еліптичних кривих та надала багатомовні посилання на реалізації.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонувала кілька EIP, які розділяють EIP-1962, частково успадковуючи його інтерфейс:
EIP-2537 надає підтримку BLS12-381
EIP-2539 надає підтримку BLS12-377
PR#2541 надає підтримку кривої BLS12-377(Zexe curve), але не отримав номер EIP
Серед них EIP-2537 є найважливішим, оскільки рівень консенсусу також використовує криву BLS12-381. Основною метою EIP-1962 та EIP-2537 є реалізація верифікації підписів BLS на рівні консенсусу в основній мережі. Тоді ETH2 розробляв контракт на депозити, і через відсутність алгоритму верифікації BLS на рівні виконання, у первісному дизайні контракт на депозити не верифікував підпис, а це робив рівень консенсусу; якщо виявлялася помилка, це могло призвести до втрати коштів користувачів.
У цьому контексті основні розробники прагнуть впровадити BLS12-381 попередньо скомпільовану функцію для перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів. Це була причина, чому в той час багато розробників звертали увагу на EIP-1962 та EIP-2537.
Коли EIP-2537 тільки був запропонований, Віталік вказав на низку проблем, які в основному зосереджені на змісті документації EIP. Після цього автор відповів на обговорення. На зустрічі основних розробників 6 березня 2020 року Віталік вважав, що EIP-2537 та інші є дуже ефективними для рекурсивних SNARK-доказів, і в довгостроковій перспективі не зашкодять Ethereum. На зустрічі було підтверджено пріоритет EIP-2537, всі клієнти погодилися якнайшвидше реалізувати його та запланували завершити розробку до оновлення Berlin.
Потім EIP-2537 став завданням високого пріоритету. На засіданні 20 березня було підтверджено, що EIP-2537 замінює EIP-1962 як основну пропозицію BLS та входить до попереднього списку оновлення Berlin. На засіданні в квітні офіційно було включено EIP-2537 до жорсткого форка Berlin, визначивши терміни реалізації на квітень та тестування на травень-червень, і було включено його до списку найвищих пріоритетів.
Далі EIP-2537 переходить до великої стадії розробки та тестування, в подальшому майже на кожній з близько 20 основних зустрічей розробників обговорювались відповідні питання. Основний зміст включає:
Обговорення проблеми кодування ABI
Синхронізація прогресу реалізації клієнтів
Реалізація PR в Geth містить 16000 рядків коду, важко визначити безпеку та ефективність
Розробники повідомили, що Geth важко завершити розробку EIP-2537 до липня
Пропозиція знайти криптографічного інженера для допомоги в перевірці PR, використовуючи тестову мережу для тестування реалізації безпеки
Обговорення питання про видалення складної оптимізації асемблера для зменшення складності перевірки
Розробники контрактів на депозит повідомили, що версія, яка не використовує EIP-2537, вже пройшла аудит, і вони розглядають можливість більше не випускати версію, що використовує EIP-2537.
Вирішено збільшити тестування YOLO тестової мережі спеціально для тестування EIP-2537
Отже, можна зробити висновок, що важливість EIP-2537 значно знизилася після завершення контракту на депозити, і розробники Geth вважають, що реалізувати його до Berlin буде важко. Виглядає так, що EIP-2537 не буде прийнято Berlin.
У подальших засіданнях виникли більше питань:
Geth виявив проблеми з реалізацією PR EIP-2537, необхідні подальші тестування та виправлення
На тестовій мережі YOLO виникли проблеми, підозрюють, що це пов'язано з підписами BLS.
Обговорити питання різноманітності клієнтів, розглянути можливість замороження поточної реалізації EIP для зниження витрат на розробку інших клієнтів.
Matter Labs хоче також включити EIP-2539 до тестування, але з цим не погоджуються розробники Geth
Врешті-решт на 99-й основній розробницькій зустрічі було вирішено вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin. Основною причиною є те, що EIP-2537 витрачає занадто багато часу основних розробників, що заважає розробці інших EIP. Додатковим фактором є пропозиція Фонду Ethereum щодо EVM384 як альтернативи.
У квітні 2021 року Ethereum завершив оновлення Berlin, основні елементи, такі як EIP-2565, не є складними, оновлення виглядає трохи бідно, оскільки найскладніший EIP-2537 був виключений.
У Лондоні після Берліна в процесі оновлення розробники розглядали можливість додавання EIP-2537, але через зміну залежностей, що може призвести до зміни ціни газу, врешті-решт через складність було знову відмовлено.
У червні 2021 року було офіційно запропоновано включити EIP-2537 до оновлення Shanghai. Але оновлення Merge зайняло велику частину часу розробників. Лише після завершення Merge у вересні 2022 року розробники отримали можливість продовжити обговорення мети Shanghai.
У листопаді 2022 року розробники вважали, що EIP-2537 потрібно відкласти, основним завданням оновлення Шанхай є підтримка виведення PoS. Оновлення Канкун також не обговорювало EIP-2537 через зосередження на EIP-4844.
До лютого 2024 року розробники лише обговорювали впровадження EIP-2537 в оновлення Pectra, вважаючи, що реалізація вже не є проблемою, а існує лише проблема з оцінкою витрат газу. З грудня 2024 року по січень 2025 року розробники обговорять конкретні моделі розрахунку витрат, врешті-решт вирішивши проблему витрат EIP-2537.
EIP-2537 від моменту запропонування в лютому 2020 року до остаточного затвердження в січні 2025 року пройшло майже 5 років. Протягом цього часу його неодноразово відкладали через складність реалізації або невідповідність тематиці оновлення. Це свідчить про те, що можливість включення EIP до оновлення Ethereum залежить не лише від його власної цінності, але й від історичних факторів. Кожне оновлення Ethereum має свою власну тему, хоча EIP-2537 колись був найважливішим EIP для оновлення Berlin, його відхилили через складність. Після цього Ethereum вступив в історичний процес PoS, і EIP на чистому рівні виконання не отримали належної уваги, що призвело до тривалого неприйняття EIP-2537.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
17 лайків
Нагородити
17
7
Репост
Поділіться
Прокоментувати
0/400
BakedCatFanboy
· 08-09 07:22
Чекали вісім років, і нарешті прийшло!
Переглянути оригіналвідповісти на0
rugpull_ptsd
· 08-06 22:13
П'ять років чекати на ланцюг, справді можна чекати.
Переглянути оригіналвідповісти на0
MetaverseHermit
· 08-06 08:26
П'ять років на одне оновлення, справжня нудьга.
Переглянути оригіналвідповісти на0
CoconutWaterBoy
· 08-06 08:25
П'ять років, щоб оновити, дійсно стабільно.
Переглянути оригіналвідповісти на0
SignatureVerifier
· 08-06 08:24
технічно цей bls імплементація потребує серйозного тестування на проникнення, ми вже бачили ці напівготові прекомпіляції раніше...
EIP-2537 довгий шлях: від відхилення оновлення Berlin до прийняття Pectra
EIP-2537: Довгий шлях обчислень кривих Ethereum
EIP-2537 є останньою EVM попередньо скомпільованою інструкцією, яка була визначена для додавання під час недавнього оновлення Pectra. Ця інструкція додає до EVM різні обчислювальні функції кривої BLS12-381, включаючи обчислення пар на області кривої тощо.
EIP-2573 спочатку був представлений у 2020 році, а лише у 2025 році був підтверджений для включення в оновлення Ethereum. У цій статті буде представлено процес управління EIP-2537, а також обговорено, чому знадобилося 5 років, щоб включити цю пропозицію в оновлення.
Фон пропозиції
У січні 2017 року Віталік Бутерин вперше представив алгоритм парування та криву alt_bn128. Пізніше Віталік та Крістіан Рейтвіссер запропонували EIP-196 та EIP-197, щоб додати підтримку обчислень кривої alt_bn128 до EVM. В жовтні 2017 року оновлення Byzantium офіційно включило криву alt_bn128, реалізувавши обчислення парування в полях кривих всередині EVM, що дозволило виконувати перевірку доказів ZK-Snarks безпосередньо в EVM.
У листопаді 2017 року команда zcash запропонувала криву BLS12-381, яка має вищу безпеку та продуктивність у порівнянні з alt_bn128. Багато блокчейн-протоколів згодом прийняли криву BLS12-381, відмовившись від кривої alt_bn128.
У травні 2018 року Джастін Дрейк зазначив, що майбутнє PoS та шардінгового оновлення Ethereum може використовувати алгоритм BLS мультипідпису на основі кривої BLS12-381. Це призвело до того, що попередній план EIP-1011 вийшов з історичної сцени, а пізніше оновлення ETH2 також врешті-решт використало криву BLS12-381.
З розвитком ETH2 зростає голос за впровадження BLS12-381 на виконавчий рівень ETH. У лютому 2020 року деякі дослідники запропонували EIP-2537, сподіваючись протестувати його на тестовій мережі ETH2. Автор EIP-2537 Алекс Стокс закликав включити його до Берлінського хардфорку.
Цікаво, що автор EIP-2537 є також співзасновником Matter Labs, найбільш відомим продуктом якого є ZKSync.
! Годинник управління Ethereum: подорож EIP-2537 перед складанням
Берлінські заворушення
Перед тим, як представити подальший зміст, потрібно спочатку згадати EIP-1962. Це перша пропозиція попередньо скомпільованого парного алгоритму еліптичних кривих, запропонована Matter Labs у квітні 2019 року, яка підтримує три криві: BLS12, BN та MNT4/6. Цей EIP планує одноразово додати 10 попередньо скомпільованих інструкцій для обробки різних кривих. Проте багато розробників ставлять під сумнів, що пропозиція є занадто складною для реалізації, а також незручною для використання інженерами смарт-контрактів. Як сторона пропозиції, Matter Labs завершила розробку алгоритму еліптичних кривих та надала багатомовні посилання на реалізації.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонувала кілька EIP, які розділяють EIP-1962, частково успадковуючи його інтерфейс:
Серед них EIP-2537 є найважливішим, оскільки рівень консенсусу також використовує криву BLS12-381. Основною метою EIP-1962 та EIP-2537 є реалізація верифікації підписів BLS на рівні консенсусу в основній мережі. Тоді ETH2 розробляв контракт на депозити, і через відсутність алгоритму верифікації BLS на рівні виконання, у первісному дизайні контракт на депозити не верифікував підпис, а це робив рівень консенсусу; якщо виявлялася помилка, це могло призвести до втрати коштів користувачів.
У цьому контексті основні розробники прагнуть впровадити BLS12-381 попередньо скомпільовану функцію для перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів. Це була причина, чому в той час багато розробників звертали увагу на EIP-1962 та EIP-2537.
Коли EIP-2537 тільки був запропонований, Віталік вказав на низку проблем, які в основному зосереджені на змісті документації EIP. Після цього автор відповів на обговорення. На зустрічі основних розробників 6 березня 2020 року Віталік вважав, що EIP-2537 та інші є дуже ефективними для рекурсивних SNARK-доказів, і в довгостроковій перспективі не зашкодять Ethereum. На зустрічі було підтверджено пріоритет EIP-2537, всі клієнти погодилися якнайшвидше реалізувати його та запланували завершити розробку до оновлення Berlin.
Потім EIP-2537 став завданням високого пріоритету. На засіданні 20 березня було підтверджено, що EIP-2537 замінює EIP-1962 як основну пропозицію BLS та входить до попереднього списку оновлення Berlin. На засіданні в квітні офіційно було включено EIP-2537 до жорсткого форка Berlin, визначивши терміни реалізації на квітень та тестування на травень-червень, і було включено його до списку найвищих пріоритетів.
Далі EIP-2537 переходить до великої стадії розробки та тестування, в подальшому майже на кожній з близько 20 основних зустрічей розробників обговорювались відповідні питання. Основний зміст включає:
Отже, можна зробити висновок, що важливість EIP-2537 значно знизилася після завершення контракту на депозити, і розробники Geth вважають, що реалізувати його до Berlin буде важко. Виглядає так, що EIP-2537 не буде прийнято Berlin.
У подальших засіданнях виникли більше питань:
Врешті-решт на 99-й основній розробницькій зустрічі було вирішено вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin. Основною причиною є те, що EIP-2537 витрачає занадто багато часу основних розробників, що заважає розробці інших EIP. Додатковим фактором є пропозиція Фонду Ethereum щодо EVM384 як альтернативи.
У квітні 2021 року Ethereum завершив оновлення Berlin, основні елементи, такі як EIP-2565, не є складними, оновлення виглядає трохи бідно, оскільки найскладніший EIP-2537 був виключений.
! Годинник управління Ethereum: подорож до компіляції EIP-2537
Подальший розвиток
У Лондоні після Берліна в процесі оновлення розробники розглядали можливість додавання EIP-2537, але через зміну залежностей, що може призвести до зміни ціни газу, врешті-решт через складність було знову відмовлено.
У червні 2021 року було офіційно запропоновано включити EIP-2537 до оновлення Shanghai. Але оновлення Merge зайняло велику частину часу розробників. Лише після завершення Merge у вересні 2022 року розробники отримали можливість продовжити обговорення мети Shanghai.
У листопаді 2022 року розробники вважали, що EIP-2537 потрібно відкласти, основним завданням оновлення Шанхай є підтримка виведення PoS. Оновлення Канкун також не обговорювало EIP-2537 через зосередження на EIP-4844.
До лютого 2024 року розробники лише обговорювали впровадження EIP-2537 в оновлення Pectra, вважаючи, що реалізація вже не є проблемою, а існує лише проблема з оцінкою витрат газу. З грудня 2024 року по січень 2025 року розробники обговорять конкретні моделі розрахунку витрат, врешті-решт вирішивши проблему витрат EIP-2537.
! Годинник управління Ethereum: подорож EIP-2537 перед складанням
Підсумок
EIP-2537 від моменту запропонування в лютому 2020 року до остаточного затвердження в січні 2025 року пройшло майже 5 років. Протягом цього часу його неодноразово відкладали через складність реалізації або невідповідність тематиці оновлення. Це свідчить про те, що можливість включення EIP до оновлення Ethereum залежить не лише від його власної цінності, але й від історичних факторів. Кожне оновлення Ethereum має свою власну тему, хоча EIP-2537 колись був найважливішим EIP для оновлення Berlin, його відхилили через складність. Після цього Ethereum вступив в історичний процес PoS, і EIP на чистому рівні виконання не отримали належної уваги, що призвело до тривалого неприйняття EIP-2537.
! Годинник управління Ethereum: подорож до компіляції EIP-2537