- Тема
88k Популярність
42k Популярність
15k Популярність
4k Популярність
5k Популярність
29k Популярність
16k Популярність
22k Популярність
13k Популярність
3k Популярність
- Закріпити
88k Популярність
42k Популярність
15k Популярність
4k Популярність
5k Популярність
29k Популярність
16k Популярність
22k Популярність
13k Популярність
3k Популярність
Ethereum майбутній розвиток: The Purge має на меті спростити протокол Падіння вимог до зберігання
Можливе майбутнє Ethereum: чистка
З 14 жовтня засновник Ethereum Віталік Бутерін поступово опублікував серію статей-обговорень щодо майбутнього розвитку Ethereum, від «The Merge» до останньої «The Purge», демонструючи свої уявлення про майбутнє розвитку основної мережі Ethereum та рішення для поточних проблем.
Стаття «The Purge» досліджує, як Ethereum може зменшити складність і вимоги до зберігання в довгостроковій перспективі, зберігаючи при цьому довговічність і децентралізацію мережі. Основні заходи включають зменшення навантаження на зберігання клієнтів за рахунок "історичного терміну придатності" та "терміну придатності стану", а також спрощення протоколу через "очищення характеристик", щоб забезпечити стійкість і масштабованість мережі.
! Віталік: Можливе майбутнє для Ethereum, очищення
Історія закінчення терміну дії
Яку проблему вирішує?
Наразі повністю синхронізований вузол Ethereum потребує близько 1,1 ТБ дискового простору для виконання клієнта, а також кілька сотень ГБ для консенсусного клієнта. Абсолютна більшість – це історичні дані, навіть якщо обмеження Gas залишиться незмінним, розмір вузла щороку зростатиме на кілька сотень ГБ.
Що це таке, як це працює?
Ключовою особливістю історичного зберігання є те, що досягнення консенсусу в теперішньому часі є достатнім для досягнення консенсусу в історії. Це надає різні варіанти для зберігання історичних записів, такі як мережа, в якій кожен вузол зберігає лише частину даних.
Ethereum вже почав позбуватися моделі, за якої всі вузли постійно зберігають всю історію. Блоки консенсусу зберігають лише близько 6 місяців, Blob зберігається лише приблизно 18 днів. EIP-4444 має на меті впровадження однорічного терміну зберігання для історичних блоків та квитанцій. Довгостроковою метою є встановлення єдиного терміну зберігання близько 18 днів, а потім створення P2P-мережі з вузлів Ethereum для розподіленого зберігання старих даних.
Коди стирання можуть бути використані для підвищення надійності, одночасно зберігаючи той же фактор копіювання. Найпростіше рішення може полягати в повторному використанні існуючих кодів стирання Blob та включенні виконання та даних блоків консенсусу також у blob.
! Віталік: Можливе майбутнє Ethereum, Очищення
Що ще потрібно зробити, що потрібно зважити?
Основні завдання включають в себе побудову та інтеграцію конкретного розподіленого рішення для зберігання історії. Найпростішим рішенням є впровадження існуючої торент-бібліотеки або так званого рішень Ethereum, відомого як мережа Portal.
Основні вагомості стосуються того, як намагатися надати "давні" історичні дані. Найпростіше рішення – негайно припинити зберігати давню історію, покладаючись на наявні архівні вузли. Безпечніше, але складніше рішення – спочатку побудувати та інтегрувати торрент-мережу.
з іншими частинами дорожньої карти
Зменшення вимог до зберігання історії є вкрай важливим для спрощення роботи вузлів. Лише реалізуючи безстанність та EIP-4444, можна реалізувати бачення запуску вузлів Ethereum на смарт-годинниках.
Обмеження історичного зберігання також робить реалізацію нових вузлів Ethereum, які підтримують лише останню версію протоколу, більш доцільною, спрощуючи клієнт.
State expiry стан досягнення терміну
Яку проблему вирішує?
Навіть якщо вимоги до зберігання історії будуть усунені, вимоги до зберігання клієнтів все ще зростатимуть приблизно на 50 ГБ щороку, оскільки статус (, залишок рахунку, код контракту тощо ) будуть постійно зростати. Користувачі можуть сплатити один раз, що створить постійний тягар для теперішніх і майбутніх клієнтів.
Що це таке, як це працює?
Статус складніше "вичерпати" в історії, оскільки EVM припускає, що об'єкт статусу існує вічно після його створення. Мета полягає в тому, щоб об'єкти автоматично вичерпувалися з часом, зберігаючи при цьому ефективність, зручність для користувачів та дружелюбність для розробників.
Основні два типи рішень:
Частковий термін дії статусу: розділити статус на блоки, зберігати лише дані, які були нещодавно відвідані. EIP-7736 пропонує рішення на основі Verkle-дерева, дані, які не відвідувалися протягом 6 місяців, зберігають лише 32 байти кореня.
Стан закінчення терміну дії на основі циклу адрес: використання постійно зростаючого списку дерев стану, щорічне додавання нових порожніх дерев. Повні вузли зберігають лише два останні дерева. Для читання та запису застарілих даних потрібно надати докази.
! Віталік: Можливе майбутнє Ethereum, The Purge
Що ще потрібно зробити, що потрібно зважити?
Можливі шляхи в майбутньому включають:
Реалізувати безстан, не вводити терміни стану. Стан продовжує зростати, але лише спеціальні користувачі зберігають.
Реалізувати часткове закінчення терміну дії, прийняти нижчий, але не нульовий постійний темп зростання.
Реалізація термінації стану через розширення адресного простору. Потрібен багаторічний процес для забезпечення безпечної та ефективної конверсії формату адрес.
Реалізація терміна дії стану через стиснення адресного простору. Потрібен багаторічний процес для забезпечення вирішення всіх ризиків безпеки.
Незалежно від обраного рішення, потрібно вирішити проблему розширення та скорочення адресного простору, оскільки в майбутньому атаки на конфлікти адрес будуть ставати простішими.
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Прибирання функцій 特征清理
Що вирішує?
Простота протоколу є ключем до безпеки, доступності та надійної нейтральності. Але протокол за замовчуванням стає складнішим з часом. Нам потрібно мати можливість видаляти функції та зменшувати складність.
Що це таке, як це працює?
Не існує єдиного значного виправлення, яке могло б зменшити складність протоколу, а натомість потрібно багато малих рішень. Деякі ключові приклади включають:
Приклади в EVM:
Що ще потрібно зробити, що потрібно зважити?
Основні міркування - це ступінь спрощення та швидкість у порівнянні з зворотною сумісністю. Необхідно створити стандартизований процес для не термінових змін, що порушують зворотну сумісність, включаючи аналіз впливу, офіційне скасування EIP, остаточне видалення та інші етапи.
Формат об'єкта EVM (EOF ) пропонує ряд змін до EVM, метою яких є дозволити більше оновлень. Потрібно зважити збільшену складність і спрощення всього EVM.
Більш радикальний підхід полягає в перетворенні більшої частини змісту протоколу в код контракту, наприклад, перетворенні EVM в агрегат або заміні EVM на нову VM. Це може значно спростити протокол, але необхідно зважити на сумісність.
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-dcbf40e0c1bc28d9082b35ed7741f911.webp0192837465674839201