Ще одна зустріч @ethereum #AllCoreDevs завершилася 15 вересня: обговорювалися оновлення мережі розробки, доповнення до Dencun і вичерпний огляд Reth!
Порядок денний: Посилання в прямому ефірі:
Нижче наведено підсумок зустрічі від @TimBeiko.
1. Оновлення статусу Devnet-8
По-перше, оновлення статусу на devnet-8: мережа перебуває на стадії остаточної розробки, і багато клієнтів уже надіслали їй нові оновлення. Тим часом ми почали тестувати процес збірки MEV/блоків за допомогою @KurtosisTech. @NethermindEth заявив, що їх пул транзакцій blob тепер готовий, і після кількох днів тестування на одному вузлі вони розгорнули його на всіх тестових вузлах Dencun.
Пул транзакцій блобів Geth також майже завершено. Besu значно вдосконалює свій пул транзакцій (обмежує загальний розмір транзакцій blob і non-blob), які, як очікується, буде випущено в наступному випуску. Erigon продовжує вдосконалювати свій пул транзакцій і сподівається бути готовим до devnet-9. Prysm також зазначає, що існує певна затримка в отриманні побічних колясок, які, за їхніми словами, зазвичай надходять із затримкою приблизно в 500 мілісекунд після блоку (у той час як обробка блоку займає близько 15 мілісекунд).
Вони досліджують цю проблему, щоб визначити, чи може вона бути спричинена умовою змагання між імпортованими блоками та блоками. Щодо питання про те, чи дозволити підтримку транзакцій blob у пулі пам’яті перед хардфорком, команда одноголосно погодилася не робити цього.
2、EIP-7514
Далі ми продовжили обговорення минулого тижня під час телефонної розмови ACDC про те, чи слід додавати постійне обмеження до черги активації валідатора. Ця пропозиція була офіційно оформлена як EIP-7514. Коротше кажучи, це сповільнить відсоткове зростання ставок ETH у найгіршому випадку. Dankrad висловив підтримку пропозиції під час дзвінка, сказавши, що це виграє нам час, щоб внести потенційно більш складні зміни до винагород валідатора.
Усі команди CL підтримують цю зміну, із застереженням, що це стосується лише черги депозитів, а не черги вилучення. Після додаткового обговорення ми вирішили встановити обмеження до 8. Тому EIP-7514 стане частиною оновлення Dencun! Очікується, що протягом наступних кількох днів EIP і відповідна специфікація CL буде оновлено, щоб відобразити цю зміну.
3. EVM і Blob
Далі ми обговорили іншу проміжну пропозицію: додавання коду операції до віртуальної машини Ethereum (EVM), щоб виявляти базові комісії blob. Цю пропозицію висунув @PlasmaPower0 з Arbitrum, який сказав на R&D Discord на початку цього тижня, що це буде корисно для них (та для інших рішень рівня 2). Ми вже маємо подібний код операції, який розкриває BASEFEE в EIP-1559, який було представлено одночасно з активацією EIP. Це спрощує рішення рівня 2 для визначення правильної ціни на газ для стягнення плати з користувачів на основі вартості даних L1.
@protolambda з Optimism також відвідав зустріч і припустив, що це не єдиний спосіб отримати базову плату за blob для L2, оскільки вони можуть дивитися на заголовок блоку (який містить значення, які використовуються для розрахунку базової комісії за blob) і надати Merkle проти цих цінностей довести. Тим не менш, він погоджується, що це приємна функція. Arbitrum наразі не виконує аналіз заголовка блоку, і покладатися на це може бути проблематично для незмінних рішень рівня 2, оскільки це може спричинити проблеми, якщо формат заголовка блоку зміниться.
Один із авторів EIP-4844 @adietrichs згадав, що цей код операції не було включено до оригінальної специфікації, оскільки було бажання розробити більш загальний спосіб доступу до інформації заголовка блоку (замість додавання одноразового коду операції). Тим не менш, прийняття цієї більш амбітної зміни було б більш амбітним завданням, ніж впровадження цього коду операції.
Інформація, яку відкриває цей код операції, вже є тим, що потрібно обчислити клієнту EL, і семантично вона майже ідентична коду операції BASEFEE. Команда клієнта одноголосно погодилася, що ми повинні додати цей код операції, лише щоб узгодити його з BASEFEE. Якщо в майбутньому ми запропонуємо «плавний» механізм, будь-яка зайва функціональність у цьому новому коді операції також стане проблемою для інших кодів операції, які використовують інформацію заголовка блоку. Крім того, варто підкреслити, що це дуже невелика зміна: @vdWijden реалізував її в Geth до того, як існував EIP, і це зайняло лише близько 20 хвилин, і команда Reth внесла зміни щодо цього під час PR-дзвінка ACD.
4、EIP-4788
Далі ми обговорили деякі оновлення EIP-4788, пропозицію зберігати корені маяка в контрактах основного ланцюга Ethereum. Протягом останніх кількох тижнів ми провели численні перевірки та тестування контракту, що призвело до деяких незначних змін, описаних у цьому PR. Хоча не всі аудити завершено, а звіти ще не опубліковані, @lightclients надав огляд змін, які розглядалися на даний момент. Перша зміна полягає в явній обробці позначок часу 0, щоб вони викликали відкат (як і інші недійсні позначки часу) замість повернення 0. Друга зміна стосується розміру буфера. Якщо припустити, що час інтервалу зміниться, вихідний контракт призведе до марної втрати пам’яті через те, як працює модульна арифметика.
5. Оптимізація газу
Нарешті, існує оптимізація газу, яка зменшує кількість завантажень CALLDATA. Аудитори переглянуть ці зміни, і ми очікуємо, що їхній остаточний звіт буде до наступного засідання ACDE. Щоб продовжити роботу над тестуванням і впровадженням fuzz, ми погодилися об’єднати запропоновані зміни зараз.
@shemnon також зазначив, що ці зміни мають бути задокументовані у фактичному EIP - ми працюємо над цим! Далі ми обговорили, як клієнти повинні впоратися з цим, якщо адреса системного контракту є частиною стану, але порожня в кінці виконання. Хоча насправді це навряд чи станеться в основній мережі (наскільки я розумію!), це граничний випадок, який стався під час тестування встановлення адреси в блоці genesis.
Враховуючи, що це досить особливий крайовий випадок і немає чіткої канонічної поведінки, ми домовилися приділити більше часу обмірковуванню цього питання та продовжити обговорення на тестовій зустрічі наступного тижня. Це все про зміни специфікацій! Все вищезазначене планується включити в devnet-9. Команда клієнта погоджується, що все має бути реалізовано та протестовано до ACDC наступного тижня. Під час цього дзвінка ми домовимося про дату запуску devnet-9.
Наступний ACDE запланований на 28 вересня о 14:00 за UTC. До того часу підписуйтеся на @terencechain, щоб отримати підсумки тестових зустрічей, @benjaminion_xyz, щоб отримати інформацію про зустрічі ACDC, і @christine_dkim, щоб отримати детальніше висвітлення всієї події.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
EIP-7514 стане частиною оновлення Ethereum Dencun
Автор: @TimBeiko Переклад: Huohuo/народний блокчейн
Ще одна зустріч @ethereum #AllCoreDevs завершилася 15 вересня: обговорювалися оновлення мережі розробки, доповнення до Dencun і вичерпний огляд Reth!
Порядок денний: Посилання в прямому ефірі:
Нижче наведено підсумок зустрічі від @TimBeiko.
1. Оновлення статусу Devnet-8
По-перше, оновлення статусу на devnet-8: мережа перебуває на стадії остаточної розробки, і багато клієнтів уже надіслали їй нові оновлення. Тим часом ми почали тестувати процес збірки MEV/блоків за допомогою @KurtosisTech. @NethermindEth заявив, що їх пул транзакцій blob тепер готовий, і після кількох днів тестування на одному вузлі вони розгорнули його на всіх тестових вузлах Dencun.
Пул транзакцій блобів Geth також майже завершено. Besu значно вдосконалює свій пул транзакцій (обмежує загальний розмір транзакцій blob і non-blob), які, як очікується, буде випущено в наступному випуску. Erigon продовжує вдосконалювати свій пул транзакцій і сподівається бути готовим до devnet-9. Prysm також зазначає, що існує певна затримка в отриманні побічних колясок, які, за їхніми словами, зазвичай надходять із затримкою приблизно в 500 мілісекунд після блоку (у той час як обробка блоку займає близько 15 мілісекунд).
Вони досліджують цю проблему, щоб визначити, чи може вона бути спричинена умовою змагання між імпортованими блоками та блоками. Щодо питання про те, чи дозволити підтримку транзакцій blob у пулі пам’яті перед хардфорком, команда одноголосно погодилася не робити цього.
2、EIP-7514
Далі ми продовжили обговорення минулого тижня під час телефонної розмови ACDC про те, чи слід додавати постійне обмеження до черги активації валідатора. Ця пропозиція була офіційно оформлена як EIP-7514. Коротше кажучи, це сповільнить відсоткове зростання ставок ETH у найгіршому випадку. Dankrad висловив підтримку пропозиції під час дзвінка, сказавши, що це виграє нам час, щоб внести потенційно більш складні зміни до винагород валідатора.
Усі команди CL підтримують цю зміну, із застереженням, що це стосується лише черги депозитів, а не черги вилучення. Після додаткового обговорення ми вирішили встановити обмеження до 8. Тому EIP-7514 стане частиною оновлення Dencun! Очікується, що протягом наступних кількох днів EIP і відповідна специфікація CL буде оновлено, щоб відобразити цю зміну.
3. EVM і Blob
Далі ми обговорили іншу проміжну пропозицію: додавання коду операції до віртуальної машини Ethereum (EVM), щоб виявляти базові комісії blob. Цю пропозицію висунув @PlasmaPower0 з Arbitrum, який сказав на R&D Discord на початку цього тижня, що це буде корисно для них (та для інших рішень рівня 2). Ми вже маємо подібний код операції, який розкриває BASEFEE в EIP-1559, який було представлено одночасно з активацією EIP. Це спрощує рішення рівня 2 для визначення правильної ціни на газ для стягнення плати з користувачів на основі вартості даних L1.
@protolambda з Optimism також відвідав зустріч і припустив, що це не єдиний спосіб отримати базову плату за blob для L2, оскільки вони можуть дивитися на заголовок блоку (який містить значення, які використовуються для розрахунку базової комісії за blob) і надати Merkle проти цих цінностей довести. Тим не менш, він погоджується, що це приємна функція. Arbitrum наразі не виконує аналіз заголовка блоку, і покладатися на це може бути проблематично для незмінних рішень рівня 2, оскільки це може спричинити проблеми, якщо формат заголовка блоку зміниться.
Один із авторів EIP-4844 @adietrichs згадав, що цей код операції не було включено до оригінальної специфікації, оскільки було бажання розробити більш загальний спосіб доступу до інформації заголовка блоку (замість додавання одноразового коду операції). Тим не менш, прийняття цієї більш амбітної зміни було б більш амбітним завданням, ніж впровадження цього коду операції.
Інформація, яку відкриває цей код операції, вже є тим, що потрібно обчислити клієнту EL, і семантично вона майже ідентична коду операції BASEFEE. Команда клієнта одноголосно погодилася, що ми повинні додати цей код операції, лише щоб узгодити його з BASEFEE. Якщо в майбутньому ми запропонуємо «плавний» механізм, будь-яка зайва функціональність у цьому новому коді операції також стане проблемою для інших кодів операції, які використовують інформацію заголовка блоку. Крім того, варто підкреслити, що це дуже невелика зміна: @vdWijden реалізував її в Geth до того, як існував EIP, і це зайняло лише близько 20 хвилин, і команда Reth внесла зміни щодо цього під час PR-дзвінка ACD.
4、EIP-4788
Далі ми обговорили деякі оновлення EIP-4788, пропозицію зберігати корені маяка в контрактах основного ланцюга Ethereum. Протягом останніх кількох тижнів ми провели численні перевірки та тестування контракту, що призвело до деяких незначних змін, описаних у цьому PR. Хоча не всі аудити завершено, а звіти ще не опубліковані, @lightclients надав огляд змін, які розглядалися на даний момент. Перша зміна полягає в явній обробці позначок часу 0, щоб вони викликали відкат (як і інші недійсні позначки часу) замість повернення 0. Друга зміна стосується розміру буфера. Якщо припустити, що час інтервалу зміниться, вихідний контракт призведе до марної втрати пам’яті через те, як працює модульна арифметика.
5. Оптимізація газу
Нарешті, існує оптимізація газу, яка зменшує кількість завантажень CALLDATA. Аудитори переглянуть ці зміни, і ми очікуємо, що їхній остаточний звіт буде до наступного засідання ACDE. Щоб продовжити роботу над тестуванням і впровадженням fuzz, ми погодилися об’єднати запропоновані зміни зараз.
@shemnon також зазначив, що ці зміни мають бути задокументовані у фактичному EIP - ми працюємо над цим! Далі ми обговорили, як клієнти повинні впоратися з цим, якщо адреса системного контракту є частиною стану, але порожня в кінці виконання. Хоча насправді це навряд чи станеться в основній мережі (наскільки я розумію!), це граничний випадок, який стався під час тестування встановлення адреси в блоці genesis.
Враховуючи, що це досить особливий крайовий випадок і немає чіткої канонічної поведінки, ми домовилися приділити більше часу обмірковуванню цього питання та продовжити обговорення на тестовій зустрічі наступного тижня. Це все про зміни специфікацій! Все вищезазначене планується включити в devnet-9. Команда клієнта погоджується, що все має бути реалізовано та протестовано до ACDC наступного тижня. Під час цього дзвінка ми домовимося про дату запуску devnet-9.
Наступний ACDE запланований на 28 вересня о 14:00 за UTC. До того часу підписуйтеся на @terencechain, щоб отримати підсумки тестових зустрічей, @benjaminion_xyz, щоб отримати інформацію про зустрічі ACDC, і @christine_dkim, щоб отримати детальніше висвітлення всієї події.