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

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

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

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

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

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

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

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

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

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

Зміст статті:

Історія закінчення терміну дії ( історичні записи закінчилися )

Держава закінчується( статус закінчується)

Прибирання функцій(特征清理)

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

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

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

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

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

Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок через хеш-посилання ( та інші структури ) вказує на попередній блок, для досягнення консенсусу щодо поточного стану достатньо досягти консенсусу щодо історії. Щойно мережа досягне консенсусу щодо останнього блоку, будь-який історичний блок або транзакція чи стан ( залишку рахунку, випадкового числа, коду, зберігання ) можуть бути надані будь-яким окремим учасником разом із доказом Меркла, і це доведення дозволяє будь-кому іншому перевірити його правильність. Консенсус є моделлю довіри N/2-of-N, тоді як історія є моделлю довіри N-of-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 як місця для постійного запису. Більш складний, але безпечний шлях — спочатку побудувати та інтегрувати торент-мережу для розподіленого зберігання історії. Тут "наскільки ми старалися" має два виміри:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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