Віталік: можливе майбутнє Ethereum, The Purge

Однією з викликів, з якими стикається Ethereum, є те, що за замовчуванням розширення і складність будь-якого блокчейн-протоколу з часом зростає. Це відбувається в двох місцях:

Історичні дані: будь-яка транзакція, проведена в будь-який момент у минулому, та будь-який створений обліковий запис повинні постійно зберігатися всіма клієнтами та завантажуватися новими клієнтами, щоб повністю синхронізуватися з мережею. Це призводить до постійного збільшення навантаження на клієнтів та часу синхронізації з плином часу, навіть якщо ємність ланцюга залишається незмінною.

Функція протоколу: додавання нових функцій значно легше, ніж видалення старих, що призводить до збільшення складності коду з часом.

Щоб Ethereum міг довгостроково підтримуватися, нам потрібно посилити сильний зворотний тиск на ці дві тенденції, зменшуючи складність і розширення з часом. Але в той же час, нам потрібно зберегти одну з ключових властивостей, які роблять блокчейн великим: тривалість. Ви можете розмістити NFT, любовний лист у даних транзакцій або смарт-контракт на суму 1 мільйон доларів у ланцюзі, зайти в печеру на десять років і вийти, виявивши, що він все ще чекає на вас для читання та взаємодії. Щоб DApp могли повністю децентралізуватися і видалити ключі для оновлення, їм потрібно бути впевненими, що їхні залежності не оновляться у спосіб, що шкодитиме їм - особливо L1.

Якщо ми вирішимо знайти баланс між цими двома потребами і максимально зменшити або повернути назад об’ємність, складність і деградацію, зберігаючи при цьому безперервність, це абсолютно можливо. Організми можуть це зробити: хоча більшість організмів старіють з часом, небагато щасливчиків цього не роблять. Навіть соціальні системи можуть мати надзвичайно тривалу життєздатність. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT переважно зник, а вузли Beacon Chain зберігали максимум шість місяців старих даних. Знайти цей шлях для Ethereum більш загальним чином і рухатися до довгострокового стабільного фінального результату є остаточним викликом для довгострокової масштабованості Ethereum, технологічної стійкості і навіть безпеки.

! Віталік: Можливе майбутнє для Ethereum, очищення

The Purge: основна мета.

Зменшення вимог до зберігання клієнтів шляхом зменшення або усунення необхідності для кожного вузла постійно зберігати всі історичні записи або навіть остаточний стан.

Зниження складності протоколу шляхом усунення непотрібних функцій.

Структура статті:

Історія закінчення терміну дії (历史记录到期)

Державний термін дії（状态到期）

Очищення функцій（特征清理）

Історія закінчення терміну

Яку проблему вирішує?

На момент написання цієї статті, повністю синхронізованому вузлу Ethereum потрібно приблизно 1,1 ТБ дискового простору для запуску клієнта, а також кілька сотень ГБ дискового простору для клієнта консенсусу. Більшість із цього є історичними даними: дані про історичні блоки, транзакції та квитанції, більшість з яких має багаторічну історію. Це означає, що навіть якщо обмеження Gas зовсім не зросте, розмір вузла продовжуватиме збільшуватися на кілька сотень ГБ щороку.

Що це таке і як це працює?

Ключовою спрощеною характеристикою проблеми зберігання історії є те, що, оскільки кожен блок пов'язаний з попереднім через хеш-посилання (та інші структури), для досягнення консенсусу в поточному часі достатньо досягти консенсусу щодо історії. Як тільки мережа досягає консенсусу щодо останнього блоку, будь-який історичний блок, транзакція або стан (баланс рахунку, випадкове число, код, зберігання) можуть бути надані будь-яким окремим учасником разом із доказом Меркле, і це доказ дозволяє будь-кому іншому перевірити його правильність. Консенсус є моделлю довіри N/2 з N, тоді як історія є моделлю довіри N з N.

Це надає нам багато варіантів, як зберігати історію. Природним вибором є мережа, в якій кожен вузол зберігає лише невелику частину даних. Так працюють мережі насіння вже десятиліттями: хоча мережа в цілому зберігає та розповсюджує мільйони файлів, кожен учасник зберігає та розповсюджує лише кілька з них. Можливо, всупереч інтуїції, цей підхід навіть не обов'язково знижує надійність даних. Якщо ми зможемо зменшити витрати на роботу вузлів, ми можемо створити мережу з 100,000 вузлів, де кожен вузол зберігає випадкові 10% історії, тоді кожен запис буде скопійований 10,000 разів - що повністю відповідає фактору копіювання мережі з 10,000 вузлів, де кожен вузол зберігає все.

Сьогодні Ethereum вже починає позбуватися моделі, за якою всі вузли постійно зберігають всю історію. Консенсусні блоки (тобто частини, пов'язані з консенсусом на основі доказу часток) зберігають лише близько 6 місяців. Blob зберігається лише близько 18 днів. EIP-4444 має на меті ввести річний термін зберігання для історичних блоків та квитанцій. Довгострокова мета - створити єдиний період (можливо, близько 18 днів), протягом якого кожен вузол відповідатиме за зберігання всього, а потім створити мережу peer-to-peer з вузлів Ethereum, що зберігає старі дані в розподіленому мережевому форматі.

Коди стирання можуть бути використані для підвищення надійності, зберігаючи при цьому той же коефіцієнт копіювання. Насправді, Blob вже використовує коди стирання для підтримки вибірки доступності даних. Найпростіше рішення, ймовірно, полягає в повторному використанні цих кодів стирання та поміщенні даних виконання та консенсусних блоків також у blob.

! Віталік: Можливе майбутнє Ethereum, Очищення

має зв'язок з існуючими дослідженнями?

ІП-4444;

Торренти та EIP-4444；

Портал мережі;

Портальна мережа та EIP-4444;

Розподілене зберігання та пошук об'єктів SSZ у Portal;

Як підвищити обмеження gas (Paradigm).

Що ще потрібно зробити, які компроміси необхідно знайти?

Залишилися основні завдання, які включають побудову та інтеграцію конкретного розподіленого рішення для зберігання історії — принаймні виконуваної історії, але в кінцевому підсумку також включаючи консенсус і blob. Найпростіше рішення — це (i) просто впровадити існуючу бібліотеку torrent, а також (ii), що називається нативним рішенням Ethereum Portal. Як тільки ми впровадимо будь-який з них, ми зможемо відкрити EIP-4444. Сам EIP-4444 не потребує хард-форку, але дійсно вимагає нової версії мережевого протоколу. Тому було б доцільно активувати його одночасно для всіх клієнтів, інакше існує ризик, що клієнти зламаються через підключення до інших вузлів з очікуванням завантаження повної історії, але насправді не отримують її.

Основні компроміси стосуються того, як ми намагаємося забезпечити "древні" історичні дані. Найпростіше рішення — це завтра припинити зберігати древню історію та покладатися на існуючі архівні вузли та різні централізовані провайдери для її копіювання. Це просто, але це підриває статус Ефіру як місця для постійного запису. Більш складний, але безпечніший шлях — спочатку побудувати та інтегрувати торрент-мережу для розподіленого зберігання історії. Тут "наскільки ми старанні" має два виміри:

Як ми намагаємося забезпечити, щоб найбільший набір вузлів дійсно зберігав усі дані?

Наскільки глибоко ми інтегруємо зберігання історії в протокол?

Екстремальний параноідальний підхід до (1) включатиме доказ управління: фактично вимагатиме, щоб кожен валідатор підтвердження прав власності зберігав певний відсоток історичних даних і регулярно перевіряв, чи роблять вони це в зашифрованому вигляді. Помірніший підхід полягає в тому, щоб встановити добровільний стандарт для відсотка історії, що зберігається кожним клієнтом.

Щодо (2), базова реалізація лише стосується роботи, яка вже виконана на сьогодні: Портал вже зберіг файл ERA, що містить всю історію Ethereum. Більш повна реалізація буде включати фактичне підключення до процесу синхронізації, так що, якщо хтось хоче синхронізувати повну історію зберігання вузлів або архівних вузлів, навіть якщо немає інших архівних вузлів онлайн, вони можуть досягти цього шляхом прямої синхронізації з мережі порталу.

Як це взаємодіє з іншими частинами дорожньої карти?

Якщо ми хочемо, щоб запуск або запуск вузлів став надзвичайно простим, то зменшення вимог до зберігання історії, можна сказати, важливіше за безстанність: з 1,1 ТБ, які потрібні вузлу, приблизно 300 ГБ - це стан, а решта приблизно 800 ГБ стала історією. Тільки реалізувавши безстанність та EIP-4444, можна досягти бачення запуску вузла Ethereum на смарт-годиннику за кілька хвилин.

Обмеження історичного зберігання також робить більш доцільними нові вузли Ethereum, які підтримують лише останні версії протоколу, що робить їх простішими. Наприклад, тепер можна безпечно видалити багато рядків коду, оскільки всі порожні слоти зберігання, створені під час атаки DoS у 2016 році, були видалені. Оскільки перехід на доказ частки став історією, клієнти можуть безпечно видалити весь код, пов'язаний з доказом роботи.

! Віталік: Можливе майбутнє Ethereum, The Purge

Термін дії держави

Яку проблему вирішує?

Навіть якщо ми усунемо потребу в зберіганні історії на клієнтській стороні, потреба в зберіганні на клієнтській стороні продовжуватиме зростати приблизно на 50 ГБ щороку, оскільки стан продовжує зростати: баланси рахунків та випадкові числа, код контрактів та зберігання контрактів. Користувачі можуть сплачувати одноразову плату, щоб назавжди покласти тягар на теперішніх і майбутніх клієнтів Ethereum.

Стан важче «закінчити», ніж історію, тому що EVM в основному розроблений навколо припущення, що як тільки об'єкт стану створено, він завжди буде існувати і може бути прочитаний будь-якою транзакцією в будь-який час. Якщо ми введемо функцію безстатусності, дехто стверджує, що, можливо, проблема не така вже й погана: лише спеціалізовані класи конструкторів блоків повинні насправді зберігати стан, тоді як усі інші вузли (навіть ті, які містять генерацію списків!) ) може працювати без громадянства. Однак існує аргумент, що ми не хочемо занадто покладатися на безгромадянство, і в кінцевому підсумку ми можемо захотіти закінчити термін дії штату, щоб зберегти Ethereum децентралізованим.

Що це таке, як це працює

Сьогодні, коли ви створюєте новий об'єкт стану (це може статися одним із трьох способів: (i) надіславши ETH на новий рахунок, (ii) створивши новий рахунок за допомогою коду, (iii) налаштувавши раніше не торканий слот пам'яті), цей об'єкт стану назавжди залишається в цьому стані. Натомість ми хочемо, щоб об'єкт автоматично застарів з часом. Ключовою задачею є зробити це таким чином, щоб досягти трьох цілей:

Ефективність: не потрібно великої кількості додаткових обчислень для виконання процесу закінчення терміну.

Дружність до користувача: якщо хтось потрапить у печеру на п'ять років і повернеться, він не повинен втратити доступ до позицій ETH, ERC20, NFT, CDP...

Дружність до розробників: розробникам не потрібно переходити на зовсім незнайому модель мислення. Крім того, додатки, які вже стали застарілими та не оновлюються, повинні продовжувати працювати нормально.

Не виконання цих цілей може призвести до легшого вирішення проблем. Наприклад, ви можете дозволити кожному об'єкту стану також зберігати лічильник дати закінчення терміну (який може бути продовжений шляхом спалювання ETH, що може відбуватися автоматично під час читання або запису в будь-який момент), і мати цикл, що перебирає стани для видалення об'єктів стану з простроченими датами. Проте це вводить додаткові обчислення (навіть вимоги до зберігання), і це, безумовно, не може задовольнити вимоги до зручності для користувача. Розробникам також важко робити висновки з крайових випадків, які пов'язані зі зберіганням значень, які іноді скидаються до нуля. Якщо ви встановите таймер закінчення терміну в межах контракту, це технічно полегшить життя розробникам, але ускладнить економічну ситуацію: розробникам потрібно буде врахувати, як "перекласти" постійні витрати на зберігання на користувачів.

Це всі проблеми, які ядро розробників Ethereum протягом багатьох років намагається вирішити, включаючи пропозиції "оренда блокчейну" та "відновлення". Врешті-решт, ми об'єднали найкращі частини пропозицій і зосередилися на двох категоріях "найменш поганих відомих рішень":

• Рішення для деяких застарілих станів
• Рекомендації щодо термінів дії стану на основі адресного циклу.

! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)

Часткова закінчення стану

Деякі пропозиції про терміни дії стану дотримуються тих самих принципів. Ми розділяємо стан на блоки. Кожен назавжди зберігає "топове відображення".