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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часткова експірація стану

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

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

Основна різниця між цими пропозиціями полягає в тому, як ми визначаємо "