Можливе майбутнє Ethereum: чистка

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

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

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

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

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

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

The Purge: Головна мета.

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

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

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

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

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

Очистка функцій

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

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

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

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

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

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

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

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

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

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

ІП-4444;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

! [Віталік: Можливе майбутнє Ethereum, The Purge]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(

) Державний термін дії

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

Навіть якщо ми усунемо потребу в зберіганні історії на клієнтській стороні, потреба в зберіганні на клієнті продовжить зростати приблизно на 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(

)# Часткова відміна стану

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

Основна різниця між цими пропозиціями полягає в тому, що: (i) як ми визначаємо "недавній", і (ii) як ми