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

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

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

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

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

Якщо ми вирішимо знайти баланс між цими двома вимогами і максимізувати зменшення або повернення до стану безладності, складності та занепаду, зберігаючи при цьому безперервність, це абсолютно можливо. Біологічні організми можуть це зробити: хоча більшість організмів старіють з часом, небагато щасливців цього не роблять. Навіть соціальні системи можуть мати дуже тривале життя. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT в основному зник, вузли мережі Beacon зберігали старі дані максимум шість місяців. Знайти цей шлях для 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 днів), протягом якого кожен вузол відповідатиме за зберігання всього, а потім створити мережу рівний до рівного з вузлів Ethereum, яка зберігатиме старі дані розподіленим способом.

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

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

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

ІП-4444;

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

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

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

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

Як підвищити gas-ліміт (Paradigm).

Що ще потрібно зробити, які питання потрібно зважити?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часткова втрата стану

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

![Віталік: Майбутнє Ethereum, The Purge](https://