EIP-2537: Довгий шлях до попередньої компіляції команд BLS12-381 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. Ці пропозиції були офіційно прийняті під час оновлення Byzantium у жовтні 2017 року, реалізувавши обчислення парування в межах кривої в EVM, що дозволило виконувати перевірку доказів ZK-Snarks всередині EVM.
З розвитком криптографії команда zcash у листопаді 2017 року запропонувала криву BLS12-381. У порівнянні з alt_bn128, BLS12-381 має вищу безпеку та кращу продуктивність. Багато блокчейн-протоколів почали використовувати криву 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 у жорстке розгалуження Berlin.
Слід зазначити, що автором EIP-2537 є також співзасновник ZKSync, компанії Matter Labs.
Перед тим, як представити подальший контент, нам спочатку потрібно зрозуміти EIP-1962. Це перша пропозиція Matter Labs щодо попередньої компіляції парування еліптичних кривих, запропонована в квітні 2019 року, яка підтримує три види кривих: BLS12, BN та MNT4/6.
EIP-1962 планує одноразове збільшення на 10 попередньо скомпільованих інструкцій для обробки різних кривих. Але ця пропозиція занадто складна, розробникам важко її реалізувати. Водночас через високу універсальність, інженерам смарт-контрактів також важко її викликати. Проте Matter Labs вже завершила розробку алгоритму еліптичних кривих і надала кілька реалізацій на різних мовах.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонувала кілька EIP, що розділяють EIP-1962, деякі з яких успадкували його інтерфейс. Ці EIP включають:
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, контракт на депозит не перевіряє підписи, конкретні підписи BLS будуть перевірені шаром консенсусу після внесення користувачем депозиту, а у разі виявлення помилки це може призвести до втрати коштів користувача.
На цьому фоні основні розробники сподіваються впровадити BLS12-381 попередньо скомпільований код для реалізації перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів ETH2. Це була причина, чому тоді багато розробників звертали увагу на EIP-1962 та EIP-2537.
Після запропонування EIP-2537 Віталік відразу вказав на ряд проблем, які в основному зосереджені на змісті документа EIP. Автори EIP потім відповіли та обговорили. На засіданні основних розробників 6 березня 2020 року Віталік вважав, що EIP-2537 та інші EIP дуже ефективні для рекурсивних SNARK-доказів, і в довгостроковій перспективі це не зашкодить Ethereum. Засідання підтвердило пріоритет EIP-2537, всі клієнти погодилися реалізувати його якомога швидше і запланували завершити розробку перед оновленням Berlin.
Після цього EIP-2537 став завданням високого пріоритету. На нараді 20 березня було підтверджено, що EIP-2537 замінює EIP-1962 і стає основною пропозицією BLS, а також потрапляє до попереднього списку оновлення Berlin. На нараді в квітні EIP-2537 офіційно включили до оновлення жорсткого хардфорку Berlin, було визначено терміни реалізації в квітні та тестування в травні-червні, і його включили до списку найвищих пріоритетів.
Потім EIP-2537 увійшов у стадію активної розробки та тестування, і його обговорювали на майже 20 наступних зустрічах основних розробників.
На 85-му засіданні розробники обговорили проблеми кодування ABI для EIP-2537. Клієнт Besu заявив, що в основному реалізував функціональність, але з боку Geth поки ніхто не розпочав відповідну роботу.
На 86-й конференції Geth заявив, що частина роботи завершена, але все ще залишилось багато роботи.
87-ме засідання зосередилося на питанні реалізації EIP-2537. Розробники Geth зазначили, що існує PR на 16000 рядків для реалізації EIP-2537, але не можна визначити його безпеку та ефективність, можна лише оцінити за допомогою простого фузз-тестування. Розробники Geth вважають, що не зможуть завершити розробку EIP-2537 до запланованого часу в Берліні.
Конференція вирішила збільшити тестування YOLO тестової мережі спеціально для тестування EIP-2537. На цей момент важливість EIP-2537 значно знизилася, розробники Geth вважають, що цей EIP, ймовірно, не буде включено в оновлення Berlin.
На 88-й конференції розробники Geth виявили низку проблем з реалізацією EIP-2537 у PR, які потребують подальшого тестування та виправлення. У системі Geth існує дві реалізації EIP-2537: одна містить оптимізацію асемблера, а інша повністю написана на Go. Дехто запропонував безпосередньо використовувати версію на Go, щоб знизити складність перевірки коду.
На 89-му засіданні виникли серйозні проблеми, у тестовій мережі YOLO виникли аномалії, підозрюють, що це викликано підписами BLS, але розробники EIP-2537 це заперечують. Хороша новина полягає в тому, що контракт на депозит на основі EIP-2537 практично завершено, зараз очікує на аудит.
90-та зустріч закріпила термін запуску оновлення Berlin на липень. На зустрічі також обговорювалося питання домінування Geth, де хтось запропонував заморозити реалізацію поточного EIP, щоб зменшити витрати на розробку інших клієнтів.
92-га зустріч все ще підтверджує EIP-2537 як необхідний EIP для оновлення Berlin.
На 96-му засіданні Matter Labs висловила бажання включити EIP-2539 до тестування YOLO v2 та до оновлення Berlin. Але розробники Geth виступили проти, вважаючи, що EIP-2537 ще не пройшов повне тестування в Geth. Остаточно вирішено не додавати 2696 в оновлення Berlin.
99-те засідання вирішило вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin, головною причиною цього є те, що воно витратило занадто багато часу основних розробників, що вплинуло на розробку інших EIP. Вторинним фактором стало те, що Фонд Ethereum запропонував EVM384 як альтернативу.
У квітні 2021 року Ethereum завершив оновлення Berlin, яке включає EIP-2565 та інші, реалізація яких не є складною, тому оновлення виглядає бідно. Це відбувається через те, що найскладніший EIP-2537 був вилучений.
Оновлення Berlin і оновлення London впровадили EIP-1559. Для EIP-2537, який раніше був основною пропозицією, подальші оновлення будуть важко включити.
Лондон на стадії оновлення, розробники розглядали можливість додавання EIP-2537. На 109-й нараді було синхронізовано інформацію про розробку EIP-2537, обговорено питання використання газу, деякі пропонували замінити EIP-2537 на EVM384. Але на 111-й нараді через складність EIP-2537 було виключено з оновлення Лондона. Основною причиною стало те, що стандарт EIP-2537 змінив залежності, що могло призвести до зміни цін на газ, і всім клієнтам потрібно було повторно оцінити споживання газу.
У червні 2021 року офіційно було запропоновано включити EIP-2537 до оновлення Shanghai. Але оновлення Merge зайняло значну частину часу розробників. Лише після завершення Merge у вересні 2022 року розробники виконавчого рівня отримали можливість продовжити обговорення цілей оновлення Shanghai.
У листопаді 2022 року на 150-й зустрічі коротко обговорювалося питання про включення EIP-2537 до оновлення Shanghai, але вирішили відкласти, оскільки основою оновлення Shanghai є підтримка виведення PoS. Врешті-решт EIP-2537 не було включено до оновлення Shanghai, яке фокусується на функції виведення.
Cancun оновлення досі не обговорювало EIP-2537, оскільки його основа підтримує EIP-4844, що забезпечує доступність даних Blob для другого рівня.
У лютому 2024 року на 181-й конференції обговорювалося впровадження EIP-2537 у оновлення Pectra, вважаючи, що реалізація вже не є проблемою, єдина проблема полягає в ціноутворенні витрат газу.
19 грудня 2024 року на 202-му засіданні розробники Nethermind визначили модель ціноутворення EIP-2537. Початковий пропонент Matter Labs на той час майже вийшов з обговорення. На 203-му засіданні в січні 2025 року обговорювалося повторне ціноутворення BLS попередньо скомпільованого коду, розробники Geth запропонували підвищити витрати на газ на 20%, що отримало підтримку команди Besu під час бенчмаркінгу.
Лютий 2020 року: розділення EIP-1962 офіційно запропонувало EIP-2537
Квітень-жовтень 2020: кілька разів обговорювали питання реалізації, врешті-решт через неможливість реалізації відмовилися від оновлення Berlin
Березень-квітень 2021 року: обговорення проблеми вартості газу, через складність відмовились від оновлення London
Листопад 2022 року: обговорення можливості включення оновлення Shanghai, безрезультатно
Лютий 2024: вважається, що реалізація не викликає проблем, однак існує проблема з витратами на газ, що може бути включено в оновлення Pectra
Грудень 2024 - Січень 2025: обговорення конкретної моделі витрат, офіційне вирішення проблеми витрат
Чи може EIP бути включеним в оновлення Ethereum залежить не лише від власних зусиль, а й від історичного процесу. Кожне оновлення має свою тему, EIP-2537 колись був ключовим для оновлення Berlin, але був відхилений через складність. Після цього Ethereum зосередився на PoS, чисті виконавчі EIP не отримували уваги, що призвело до тривалого неприйняття EIP-2537. Лише нещодавно розробники знову зосередилися на ньому та вирішили його невирішені проблеми.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
19 лайків
Нагородити
19
5
Репост
Поділіться
Прокоментувати
0/400
UncleLiquidation
· 22год тому
П'ять років тільки почали розробку, темп розвитку Ethereum справді повільний.
Переглянути оригіналвідповісти на0
Anon32942
· 22год тому
Грав, чекав п'ять років, нещодавно зробив спред.
Переглянути оригіналвідповісти на0
GasWrangler
· 22год тому
насправді їм знадобилося 5 років, щоб оптимізувати щось таке математично тривіальне... смх через неефективність layer1
Ethereum BLS препроцесорна команда EIP-2537 після 5 років нарешті була прийнята
EIP-2537: Довгий шлях до попередньої компіляції команд BLS12-381 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. Ці пропозиції були офіційно прийняті під час оновлення Byzantium у жовтні 2017 року, реалізувавши обчислення парування в межах кривої в EVM, що дозволило виконувати перевірку доказів ZK-Snarks всередині EVM.
З розвитком криптографії команда zcash у листопаді 2017 року запропонувала криву BLS12-381. У порівнянні з alt_bn128, BLS12-381 має вищу безпеку та кращу продуктивність. Багато блокчейн-протоколів почали використовувати криву 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 у жорстке розгалуження Berlin.
Слід зазначити, що автором EIP-2537 є також співзасновник ZKSync, компанії Matter Labs.
! Годинник управління Ethereum: подорож EIP-2537 перед складанням
Перешкоди оновлення Берліна
Перед тим, як представити подальший контент, нам спочатку потрібно зрозуміти EIP-1962. Це перша пропозиція Matter Labs щодо попередньої компіляції парування еліптичних кривих, запропонована в квітні 2019 року, яка підтримує три види кривих: BLS12, BN та MNT4/6.
EIP-1962 планує одноразове збільшення на 10 попередньо скомпільованих інструкцій для обробки різних кривих. Але ця пропозиція занадто складна, розробникам важко її реалізувати. Водночас через високу універсальність, інженерам смарт-контрактів також важко її викликати. Проте Matter Labs вже завершила розробку алгоритму еліптичних кривих і надала кілька реалізацій на різних мовах.
Щоб вирішити проблему EIP-1962, Matter Labs у лютому 2020 року запропонувала кілька EIP, що розділяють EIP-1962, деякі з яких успадкували його інтерфейс. Ці EIP включають:
Серед них EIP-2537 є найважливішим, оскільки шар консенсусу також використовує криву BLS12-381. Основна мета EIP-1962 та EIP-2537 полягає в реалізації перевірки підписів BLS на шарі консенсусу в основній мережі. На той час ETH2 проектував контракт на депозит, оскільки шар виконання не має алгоритму перевірки BLS, контракт на депозит не перевіряє підписи, конкретні підписи BLS будуть перевірені шаром консенсусу після внесення користувачем депозиту, а у разі виявлення помилки це може призвести до втрати коштів користувача.
На цьому фоні основні розробники сподіваються впровадити BLS12-381 попередньо скомпільований код для реалізації перевірки підписів у контракті депозиту, щоб уникнути можливих втрат коштів користувачів ETH2. Це була причина, чому тоді багато розробників звертали увагу на EIP-1962 та EIP-2537.
Після запропонування EIP-2537 Віталік відразу вказав на ряд проблем, які в основному зосереджені на змісті документа EIP. Автори EIP потім відповіли та обговорили. На засіданні основних розробників 6 березня 2020 року Віталік вважав, що EIP-2537 та інші EIP дуже ефективні для рекурсивних SNARK-доказів, і в довгостроковій перспективі це не зашкодить Ethereum. Засідання підтвердило пріоритет EIP-2537, всі клієнти погодилися реалізувати його якомога швидше і запланували завершити розробку перед оновленням Berlin.
Після цього EIP-2537 став завданням високого пріоритету. На нараді 20 березня було підтверджено, що EIP-2537 замінює EIP-1962 і стає основною пропозицією BLS, а також потрапляє до попереднього списку оновлення Berlin. На нараді в квітні EIP-2537 офіційно включили до оновлення жорсткого хардфорку Berlin, було визначено терміни реалізації в квітні та тестування в травні-червні, і його включили до списку найвищих пріоритетів.
Потім EIP-2537 увійшов у стадію активної розробки та тестування, і його обговорювали на майже 20 наступних зустрічах основних розробників.
На 85-му засіданні розробники обговорили проблеми кодування ABI для EIP-2537. Клієнт Besu заявив, що в основному реалізував функціональність, але з боку Geth поки ніхто не розпочав відповідну роботу.
На 86-й конференції Geth заявив, що частина роботи завершена, але все ще залишилось багато роботи.
87-ме засідання зосередилося на питанні реалізації EIP-2537. Розробники Geth зазначили, що існує PR на 16000 рядків для реалізації EIP-2537, але не можна визначити його безпеку та ефективність, можна лише оцінити за допомогою простого фузз-тестування. Розробники Geth вважають, що не зможуть завершити розробку EIP-2537 до запланованого часу в Берліні.
Конференція вирішила збільшити тестування YOLO тестової мережі спеціально для тестування EIP-2537. На цей момент важливість EIP-2537 значно знизилася, розробники Geth вважають, що цей EIP, ймовірно, не буде включено в оновлення Berlin.
На 88-й конференції розробники Geth виявили низку проблем з реалізацією EIP-2537 у PR, які потребують подальшого тестування та виправлення. У системі Geth існує дві реалізації EIP-2537: одна містить оптимізацію асемблера, а інша повністю написана на Go. Дехто запропонував безпосередньо використовувати версію на Go, щоб знизити складність перевірки коду.
На 89-му засіданні виникли серйозні проблеми, у тестовій мережі YOLO виникли аномалії, підозрюють, що це викликано підписами BLS, але розробники EIP-2537 це заперечують. Хороша новина полягає в тому, що контракт на депозит на основі EIP-2537 практично завершено, зараз очікує на аудит.
90-та зустріч закріпила термін запуску оновлення Berlin на липень. На зустрічі також обговорювалося питання домінування Geth, де хтось запропонував заморозити реалізацію поточного EIP, щоб зменшити витрати на розробку інших клієнтів.
92-га зустріч все ще підтверджує EIP-2537 як необхідний EIP для оновлення Berlin.
На 96-му засіданні Matter Labs висловила бажання включити EIP-2539 до тестування YOLO v2 та до оновлення Berlin. Але розробники Geth виступили проти, вважаючи, що EIP-2537 ще не пройшов повне тестування в Geth. Остаточно вирішено не додавати 2696 в оновлення Berlin.
99-те засідання вирішило вивести EIP-2537 з тестової мережі YOLO v3 та оновлення Berlin, головною причиною цього є те, що воно витратило занадто багато часу основних розробників, що вплинуло на розробку інших EIP. Вторинним фактором стало те, що Фонд Ethereum запропонував EVM384 як альтернативу.
У квітні 2021 року Ethereum завершив оновлення Berlin, яке включає EIP-2565 та інші, реалізація яких не є складною, тому оновлення виглядає бідно. Це відбувається через те, що найскладніший EIP-2537 був вилучений.
! Годинник управління Ethereum: подорож до компіляції EIP-2537
Подальший розвиток
Оновлення Berlin і оновлення London впровадили EIP-1559. Для EIP-2537, який раніше був основною пропозицією, подальші оновлення будуть важко включити.
Лондон на стадії оновлення, розробники розглядали можливість додавання EIP-2537. На 109-й нараді було синхронізовано інформацію про розробку EIP-2537, обговорено питання використання газу, деякі пропонували замінити EIP-2537 на EVM384. Але на 111-й нараді через складність EIP-2537 було виключено з оновлення Лондона. Основною причиною стало те, що стандарт EIP-2537 змінив залежності, що могло призвести до зміни цін на газ, і всім клієнтам потрібно було повторно оцінити споживання газу.
У червні 2021 року офіційно було запропоновано включити EIP-2537 до оновлення Shanghai. Але оновлення Merge зайняло значну частину часу розробників. Лише після завершення Merge у вересні 2022 року розробники виконавчого рівня отримали можливість продовжити обговорення цілей оновлення Shanghai.
У листопаді 2022 року на 150-й зустрічі коротко обговорювалося питання про включення EIP-2537 до оновлення Shanghai, але вирішили відкласти, оскільки основою оновлення Shanghai є підтримка виведення PoS. Врешті-решт EIP-2537 не було включено до оновлення Shanghai, яке фокусується на функції виведення.
Cancun оновлення досі не обговорювало EIP-2537, оскільки його основа підтримує EIP-4844, що забезпечує доступність даних Blob для другого рівня.
У лютому 2024 року на 181-й конференції обговорювалося впровадження EIP-2537 у оновлення Pectra, вважаючи, що реалізація вже не є проблемою, єдина проблема полягає в ціноутворенні витрат газу.
19 грудня 2024 року на 202-му засіданні розробники Nethermind визначили модель ціноутворення EIP-2537. Початковий пропонент Matter Labs на той час майже вийшов з обговорення. На 203-му засіданні в січні 2025 року обговорювалося повторне ціноутворення BLS попередньо скомпільованого коду, розробники Geth запропонували підвищити витрати на газ на 20%, що отримало підтримку команди Besu під час бенчмаркінгу.
! Годинник управління Ethereum: подорож EIP-2537 перед складанням
Підсумок
Розвиток EIP-2537 можна підсумувати так:
Чи може EIP бути включеним в оновлення Ethereum залежить не лише від власних зусиль, а й від історичного процесу. Кожне оновлення має свою тему, EIP-2537 колись був ключовим для оновлення Berlin, але був відхилений через складність. Після цього Ethereum зосередився на PoS, чисті виконавчі EIP не отримували уваги, що призвело до тривалого неприйняття EIP-2537. Лише нещодавно розробники знову зосередилися на ньому та вирішили його невирішені проблеми.
! Годинник управління Ethereum: подорож до компіляції EIP-2537