Одним із важливих викликів, з якими стикається Ethereum, є те, як зменшити складність і вимоги до зберігання в довгостроковій перспективі, зберігаючи при цьому довговічність і децентралізацію ланцюга. Щоб Ethereum міг існувати в довгостроковій перспективі, нам потрібно чинити потужний зворотний тиск на складність і розширення, зменшуючи складність і розширення з часом. Але водночас ми повинні зберегти цю ключову властивість довговічності блокчейну.
Основні цілі очищення включають:
Зменшити вимоги до зберігання клієнта, зменшивши або усунувши потребу в тому, щоб кожен вузол постійно зберігав усі історичні записи, навіть остаточний стан.
Зниження складності протоколу шляхом усунення непотрібних функцій.
Станом на сьогодні, повністю синхронізований вузол Ethereum потребує близько 1,1 ТБ дискового простору для виконання клієнта, а також ще кілька сотень ГБ для клієнта консенсусу. Більшість з цього є історичними даними, навіть якщо розмір блоку залишається незмінним, розмір вузла щорічно продовжуватиме зростати на кілька сотень ГБ.
Що це таке, як це працює?
Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок хешем вказує на попередній блок, то для досягнення консенсусу щодо поточного стану достатньо досягти консенсусу щодо історії. Це надає нам безліч варіантів, як зберігати історичні записи. Природним вибором є мережа, в якій кожен вузол зберігає лише невелику частину даних.
Сьогодні Ethereum почав відходити від моделі, в якій всі вузли постійно зберігають всю історію. Блоки консенсусу зберігають лише близько 6 місяців. Blob зберігається лише приблизно 18 днів. EIP-4444 має на меті ввести річний термін зберігання для історичних блоків і квитанцій. Довгострокова мета полягає в створенні єдиного періоду (, який може становити приблизно 18 днів ), протягом якого кожен вузол несе відповідальність за зберігання всього, а потім створити мережу рівноправних вузлів Ethereum, яка зберігатиме старі дані в розподіленій мережевій формі.
ще потрібно зробити що, потрібно зважити що?
Залишилася основна робота, яка включає в себе побудову та інтеграцію конкретного розподіленого рішення для зберігання історії. Найпростіше рішення полягає у впровадженні існуючої бібліотеки торрентів або так званого рідного рішення Ethereum від Portal Network. Основні компроміси стосуються того, як ми намагаємося надати "давні" історичні дані. Найпростіше рішення - це завтра припинити зберігати давню історію і покладатися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Складніший, але безпечніший шлях - спочатку побудувати та інтегрувати торрент-мережу для розподіленого зберігання історії.
як взаємодіє з іншими частинами дорожньої карти?
Якщо ми хочемо, щоб запуск або запуск вузлів став надзвичайно простим, то зменшення вимог до зберігання історії можна вважати більш важливим, ніж безстанність. Лише реалізувавши безстанність та EIP-4444, можна досягти бачення запуску вузла Ethereum на смарт-годиннику з налаштуванням всього за кілька хвилин.
Навіть якщо ми усунемо необхідність зберігати історію в клієнті, потреба в зберіганні клієнта продовжуватиме зростати, приблизно на 50 ГБ щороку, оскільки стан постійно зростає. Користувачі можуть сплатити одноразовий збір, щоб назавжди зменшити навантаження на теперішніх і майбутніх клієнтів Ethereum.
Що це таке, як це працює?
Сьогодні, коли створюється новий об'єкт стану, цей об'єкт стану завжди залишається в цьому стані. Натомість ми хочемо, щоб об'єкт автоматично закінчувався з часом. Ключовим викликом є досягнення цього у спосіб, який забезпечує ефективність, зручність для користувача та дружність для розробників.
Наразі існує два типи "найменш поганих рішень":
Часткове рішення для термінових статусів
Рекомендації щодо терміну дії стану на основі адресного циклу
Частина статусу терміни пропозицій розділяє статус на блоки. Кожен зберігає "топове відображення" постійно, де блоки можуть бути порожніми або непорожніми. Дані в кожному блоці зберігаються лише якщо ці дані нещодавно відвідувалися. Є механізм "відродження", якщо дані більше не зберігаються.
Дизайн на основі циклу адрес використовує постійно зростаючий список дерев станів, і будь-який стан, який читається або записується, зберігається в останньому дереві станів. Кожен період (, наприклад: 1 рік ), додає одне нове порожнє дерево станів. Старі дерева заморожуються. Повні вузли зберігають лише останні два дерева.
Що ще потрібно зробити, що потрібно зважити?
Я вважаю, що в майбутньому є чотири можливі шляхи:
Ми досягаємо безстанності та ніколи не вводимо стан з терміном дії.
Ми приймаємо часткове закінчення стану та погоджуємося на набагато нижчу, але все ж ненульову постійну швидкість зростання стану.
Ми здійснюємо термін дії стану через розширення адресного простору.
Ми здійснюємо термін дії стану через скорочення адресного простору.
Важливим є те, що незалежно від того, чи буде реалізовано план закінчення терміну, що залежить від зміни формату адреси, врешті-решт необхідно вирішити питання, пов'язані з розширенням і скороченням адресного простору.
Однією з ключових передумов безпеки, доступності та довірчої нейтральності є простота. Якщо протокол привабливий і простий, це зменшує ймовірність виникнення помилок. Це підвищує можливості участі нових розробників у будь-якій частині процесу. Імовірніше, що він буде справедливим, а також легше протистояти особливим інтересам. На жаль, протокол, як і будь-яка соціальна система, за замовчуванням з часом стає більш складним.
Що це таке, як це працює?
Немає жодного суттєвого єдиного виправлення, яке могло б зменшити складність протоколу; суть цієї проблеми полягає в тому, що існує безліч невеликих рішень. Деякі ключові приклади включають:
Перетворення RLP → SSZ
Видалити старий тип交易
LOG реформа
Остаточне видалення механізму синхронізації комітету Beacon Chain
Уніфікований формат даних
Видалити комітет Beacon Chain
Видалити змішаний порядок байтів
Спрощення механізму газу
Видалити попередньо скомпільоване
Видалити спостережуваність газу
Покращення статичного аналізу
Що ще потрібно зробити, що потрібно зважити?
Основним компромісом при здійсненні такого виду функціонального спрощення є ступінь і швидкість нашого спрощення в порівнянні зі зворотною сумісністю. Більш широкою соціальною проблемою є створення стандартизованого конвеєра для нетермінових змін, що порушують зворотну сумісність.
Формат об'єкта EVM ( EOF ) є набором основних змін, запропонованих для EVM. Його перевагою є створення природного шляху для додавання нових функцій EVM та заохочення міграції до більш строгого EVM з сильнішими гарантіями. Недоліком є значне збільшення складності протоколу, якщо ми не зможемо знайти спосіб остаточно відмовитися від старого EVM та видалити його.
Більш радикальна стратегія спрощення Ethereum полягає в тому, щоб зберегти протокол незмінним, але перенести більшість його функцій з протоколу на код контракту. Найекстримальніша версія полягає в тому, щоб зробити Ethereum L1 "технічно" лише сигнальною ланцюгом і ввести мінімальну віртуальну машину, що дозволяє іншим створювати свої власні зведення. Тоді EVM стане першим з цих зведень.
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-dcbf40e0c1bc28d9082b35ed7741f911.webp0192837465674839201
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Шлях Ethereum до очищення: довгострокова проблема зниження складності та вимог до зберігання
Майбутнє Ethereum: очищення
Одним із важливих викликів, з якими стикається Ethereum, є те, як зменшити складність і вимоги до зберігання в довгостроковій перспективі, зберігаючи при цьому довговічність і децентралізацію ланцюга. Щоб Ethereum міг існувати в довгостроковій перспективі, нам потрібно чинити потужний зворотний тиск на складність і розширення, зменшуючи складність і розширення з часом. Але водночас ми повинні зберегти цю ключову властивість довговічності блокчейну.
Основні цілі очищення включають:
Зменшити вимоги до зберігання клієнта, зменшивши або усунувши потребу в тому, щоб кожен вузол постійно зберігав усі історичні записи, навіть остаточний стан.
Зниження складності протоколу шляхом усунення непотрібних функцій.
! Віталік: Можливе майбутнє для Ethereum, очищення
Історія закінчення терміну
Яку проблему вирішує?
Станом на сьогодні, повністю синхронізований вузол Ethereum потребує близько 1,1 ТБ дискового простору для виконання клієнта, а також ще кілька сотень ГБ для клієнта консенсусу. Більшість з цього є історичними даними, навіть якщо розмір блоку залишається незмінним, розмір вузла щорічно продовжуватиме зростати на кілька сотень ГБ.
Що це таке, як це працює?
Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок хешем вказує на попередній блок, то для досягнення консенсусу щодо поточного стану достатньо досягти консенсусу щодо історії. Це надає нам безліч варіантів, як зберігати історичні записи. Природним вибором є мережа, в якій кожен вузол зберігає лише невелику частину даних.
Сьогодні Ethereum почав відходити від моделі, в якій всі вузли постійно зберігають всю історію. Блоки консенсусу зберігають лише близько 6 місяців. Blob зберігається лише приблизно 18 днів. EIP-4444 має на меті ввести річний термін зберігання для історичних блоків і квитанцій. Довгострокова мета полягає в створенні єдиного періоду (, який може становити приблизно 18 днів ), протягом якого кожен вузол несе відповідальність за зберігання всього, а потім створити мережу рівноправних вузлів Ethereum, яка зберігатиме старі дані в розподіленій мережевій формі.
ще потрібно зробити що, потрібно зважити що?
Залишилася основна робота, яка включає в себе побудову та інтеграцію конкретного розподіленого рішення для зберігання історії. Найпростіше рішення полягає у впровадженні існуючої бібліотеки торрентів або так званого рідного рішення Ethereum від Portal Network. Основні компроміси стосуються того, як ми намагаємося надати "давні" історичні дані. Найпростіше рішення - це завтра припинити зберігати давню історію і покладатися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Складніший, але безпечніший шлях - спочатку побудувати та інтегрувати торрент-мережу для розподіленого зберігання історії.
як взаємодіє з іншими частинами дорожньої карти?
Якщо ми хочемо, щоб запуск або запуск вузлів став надзвичайно простим, то зменшення вимог до зберігання історії можна вважати більш важливим, ніж безстанність. Лише реалізувавши безстанність та EIP-4444, можна досягти бачення запуску вузла Ethereum на смарт-годиннику з налаштуванням всього за кілька хвилин.
! Віталік: Можливе майбутнє Ethereum, Очищення
Статус закінчився
Яку проблему це вирішує?
Навіть якщо ми усунемо необхідність зберігати історію в клієнті, потреба в зберіганні клієнта продовжуватиме зростати, приблизно на 50 ГБ щороку, оскільки стан постійно зростає. Користувачі можуть сплатити одноразовий збір, щоб назавжди зменшити навантаження на теперішніх і майбутніх клієнтів Ethereum.
Що це таке, як це працює?
Сьогодні, коли створюється новий об'єкт стану, цей об'єкт стану завжди залишається в цьому стані. Натомість ми хочемо, щоб об'єкт автоматично закінчувався з часом. Ключовим викликом є досягнення цього у спосіб, який забезпечує ефективність, зручність для користувача та дружність для розробників.
Наразі існує два типи "найменш поганих рішень":
Частина статусу терміни пропозицій розділяє статус на блоки. Кожен зберігає "топове відображення" постійно, де блоки можуть бути порожніми або непорожніми. Дані в кожному блоці зберігаються лише якщо ці дані нещодавно відвідувалися. Є механізм "відродження", якщо дані більше не зберігаються.
Дизайн на основі циклу адрес використовує постійно зростаючий список дерев станів, і будь-який стан, який читається або записується, зберігається в останньому дереві станів. Кожен період (, наприклад: 1 рік ), додає одне нове порожнє дерево станів. Старі дерева заморожуються. Повні вузли зберігають лише останні два дерева.
Що ще потрібно зробити, що потрібно зважити?
Я вважаю, що в майбутньому є чотири можливі шляхи:
Важливим є те, що незалежно від того, чи буде реалізовано план закінчення терміну, що залежить від зміни формату адреси, врешті-решт необхідно вирішити питання, пов'язані з розширенням і скороченням адресного простору.
! Віталік: Можливе майбутнє Ethereum, The Purge
Очищення функцій
Яку проблему це вирішує?
Однією з ключових передумов безпеки, доступності та довірчої нейтральності є простота. Якщо протокол привабливий і простий, це зменшує ймовірність виникнення помилок. Це підвищує можливості участі нових розробників у будь-якій частині процесу. Імовірніше, що він буде справедливим, а також легше протистояти особливим інтересам. На жаль, протокол, як і будь-яка соціальна система, за замовчуванням з часом стає більш складним.
Що це таке, як це працює?
Немає жодного суттєвого єдиного виправлення, яке могло б зменшити складність протоколу; суть цієї проблеми полягає в тому, що існує безліч невеликих рішень. Деякі ключові приклади включають:
Що ще потрібно зробити, що потрібно зважити?
Основним компромісом при здійсненні такого виду функціонального спрощення є ступінь і швидкість нашого спрощення в порівнянні зі зворотною сумісністю. Більш широкою соціальною проблемою є створення стандартизованого конвеєра для нетермінових змін, що порушують зворотну сумісність.
Формат об'єкта EVM ( EOF ) є набором основних змін, запропонованих для EVM. Його перевагою є створення природного шляху для додавання нових функцій EVM та заохочення міграції до більш строгого EVM з сильнішими гарантіями. Недоліком є значне збільшення складності протоколу, якщо ми не зможемо знайти спосіб остаточно відмовитися від старого EVM та видалити його.
Більш радикальна стратегія спрощення Ethereum полягає в тому, щоб зберегти протокол незмінним, але перенести більшість його функцій з протоколу на код контракту. Найекстримальніша версія полягає в тому, щоб зробити Ethereum L1 "технічно" лише сигнальною ланцюгом і ввести мінімальну віртуальну машину, що дозволяє іншим створювати свої власні зведення. Тоді EVM стане першим з цих зведень.
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-dcbf40e0c1bc28d9082b35ed7741f911.webp0192837465674839201