20 квітня 2023 року команда розробників Ethereum провела 107-му зустріч ключових розробників консенсусу (ACDC). Зустріч була проведена дослідником Фонду Ethereum, основна увага була приділена змінам в консенсусному шарі Ethereum (CL), оновленню прогресу Deneb, а також іншим пропозиціям, окрім EIP-4844, у наступному оновленні Канкуна.
Deneb测试网#5
Після успішної активації після оновлення Шанхаю, команда розробників швидко перемістила свою увагу на підготовку до Канкуна. Канкун — це назва наступного оновлення рівня виконання Ethereum (EL), а Deneb — відповідна назва оновлення CL. Під час зустрічі розробники обговорили остаточний обсяг оновлення Cancun/Deneb, яке буде зосереджено на EIP-4844, що передбачає впровадження типу транзакцій blob.
Підготовка Deneb починається з запуску тестової мережі #5. З жовтня минулого року розробники запустили кілька тестових мереж клієнтів для EIP-4844. Голова конференції повідомив, що п'ята тестова мережа EIP-4844 буде запущена десь на наступному тижні. Один інженер зазначив, що він проводить пробні запуски для кількох клієнтів у підготовці до випуску тестової мережі наступного тижня.
API двигуна має невелику зміну, яка об'єднує два виклики в один. Це зміна ще не була об'єднана до специфікації EIP-4844, але буде завершена в найближчі кілька днів для тестування на тестовій мережі #5.
Розробники також обговорили питання, як повторно вставити blob-транзакції в блок під час реорганізації ланцюга. Оскільки blob-транзакції відокремлені від звичайних транзакцій, блоби, що були реорганізовані, можна отримати лише з транзакцій загального пулу пам'яті. Ураховуючи, що багато транзакцій обминають пул пам'яті, одним із рішень є те, що CL передає дані blob кожного блоку EL, а потім EL може кешувати їх до завершення блоку. Іншим варіантом є вимога до користувачів, які подали транзакції, що обійшли пул пам'яті, повторно подавати свої транзакції під час подій реорганізації ланцюга.
Розробник зазначив, що він більше схиляється до першого варіанту, тобто передачі blob-даних до EL. Він вважає, що це не створює великого додаткового навантаження на EL, і якщо цей процес стане громіздким, розробники можуть налаштувати повідомлення між EL та CL, щоб зменшити навантаження. Проте, деякі вказують, що це рішення може ще більше порушити абстракцію між шарами EL та CL, а також може вплинути на майбутнє впровадження зразків доступності даних (DAS).
Через відсутність участі команди EL-клієнта це питання буде знову обговорено на наступній нараді.
Додаткова пропозиція Deneb
Окрім EIP-4844, оновлення Deneb також враховувало інші оновлення коду:
EIP-4788: Публікація стану CL Beacon Chain в EL, що дозволяє смарт-контрактам, виконуваним в EL, мінімізувати довірчий доступ до CL.
EIP-6914: Повторне використання індексних номерів валідаторів, які повністю вийшли з мережі та тривалий час неактивні, допомагає зменшити нескінченне зростання списку валідаторів.
Потенційна зміна коду, що стосується зворотного заповнення даних з генезис-блоку Beacon Chain та створення нового вмісту "історичного підсумку".
PR 3175: Запобігання тому, щоб верифікатори, які отримали покарання, подавали блоки під час виходу з черги, забезпечуючи захист від "високої відмови".
EIP-6493: вирішення питання, як вузли обробляють транзакції типу blob, які форматуються у форматі SSZ на CL, але кодуються по-іншому на EL.
Розробники, як правило, схильні включати EIP-4788, PR 3175 разом з EIP-4844 в наступне оновлення.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
18 лайків
Нагородити
18
5
Репост
Поділіться
Прокоментувати
0/400
StablecoinEnjoyer
· 12год тому
Знову Тестова мережа V просто зростання
Переглянути оригіналвідповісти на0
HashBandit
· 08-13 17:01
омг ще одне оновлення... досі згадую останній танець мого майнінг-риг під час злиття, чесно кажучи
Переглянути оригіналвідповісти на0
HallucinationGrower
· 08-13 16:58
Добре, це EIP вже 4844, відчуваю, що грати більше не зможу.
Переглянути оригіналвідповісти на0
MondayYoloFridayCry
· 08-13 16:52
Майже вже Канкун, а завтра знову купувати просадку.
Переглянути оригіналвідповісти на0
GateUser-aa7df71e
· 08-13 16:36
Короткостроково має бути пробиття, акули чекають на обдурювання людей, як лохів.
Конференція розробників Ethereum зосереджена на EIP-4844, оновлення Канкун незабаром представить Тестову мережу Deneb#5
以太坊核心开发者共识会议#107резюме
20 квітня 2023 року команда розробників Ethereum провела 107-му зустріч ключових розробників консенсусу (ACDC). Зустріч була проведена дослідником Фонду Ethereum, основна увага була приділена змінам в консенсусному шарі Ethereum (CL), оновленню прогресу Deneb, а також іншим пропозиціям, окрім EIP-4844, у наступному оновленні Канкуна.
Deneb测试网#5
Після успішної активації після оновлення Шанхаю, команда розробників швидко перемістила свою увагу на підготовку до Канкуна. Канкун — це назва наступного оновлення рівня виконання Ethereum (EL), а Deneb — відповідна назва оновлення CL. Під час зустрічі розробники обговорили остаточний обсяг оновлення Cancun/Deneb, яке буде зосереджено на EIP-4844, що передбачає впровадження типу транзакцій blob.
Підготовка Deneb починається з запуску тестової мережі #5. З жовтня минулого року розробники запустили кілька тестових мереж клієнтів для EIP-4844. Голова конференції повідомив, що п'ята тестова мережа EIP-4844 буде запущена десь на наступному тижні. Один інженер зазначив, що він проводить пробні запуски для кількох клієнтів у підготовці до випуску тестової мережі наступного тижня.
API двигуна має невелику зміну, яка об'єднує два виклики в один. Це зміна ще не була об'єднана до специфікації EIP-4844, але буде завершена в найближчі кілька днів для тестування на тестовій мережі #5.
Розробники також обговорили питання, як повторно вставити blob-транзакції в блок під час реорганізації ланцюга. Оскільки blob-транзакції відокремлені від звичайних транзакцій, блоби, що були реорганізовані, можна отримати лише з транзакцій загального пулу пам'яті. Ураховуючи, що багато транзакцій обминають пул пам'яті, одним із рішень є те, що CL передає дані blob кожного блоку EL, а потім EL може кешувати їх до завершення блоку. Іншим варіантом є вимога до користувачів, які подали транзакції, що обійшли пул пам'яті, повторно подавати свої транзакції під час подій реорганізації ланцюга.
Розробник зазначив, що він більше схиляється до першого варіанту, тобто передачі blob-даних до EL. Він вважає, що це не створює великого додаткового навантаження на EL, і якщо цей процес стане громіздким, розробники можуть налаштувати повідомлення між EL та CL, щоб зменшити навантаження. Проте, деякі вказують, що це рішення може ще більше порушити абстракцію між шарами EL та CL, а також може вплинути на майбутнє впровадження зразків доступності даних (DAS).
Через відсутність участі команди EL-клієнта це питання буде знову обговорено на наступній нараді.
Додаткова пропозиція Deneb
Окрім EIP-4844, оновлення Deneb також враховувало інші оновлення коду:
EIP-4788: Публікація стану CL Beacon Chain в EL, що дозволяє смарт-контрактам, виконуваним в EL, мінімізувати довірчий доступ до CL.
EIP-6914: Повторне використання індексних номерів валідаторів, які повністю вийшли з мережі та тривалий час неактивні, допомагає зменшити нескінченне зростання списку валідаторів.
Потенційна зміна коду, що стосується зворотного заповнення даних з генезис-блоку Beacon Chain та створення нового вмісту "історичного підсумку".
PR 3175: Запобігання тому, щоб верифікатори, які отримали покарання, подавали блоки під час виходу з черги, забезпечуючи захист від "високої відмови".
EIP-6493: вирішення питання, як вузли обробляють транзакції типу blob, які форматуються у форматі SSZ на CL, але кодуються по-іншому на EL.
Розробники, як правило, схильні включати EIP-4788, PR 3175 разом з EIP-4844 в наступне оновлення.