Можливе майбутнє Ethereum: The Purge

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

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

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

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

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

! [Віталік: Можливе майбутнє Ethereum, чистка] (ian/2024/10/27/images/82bf476df163c6707fccf140ec382f88.jpg)

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

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

Зменшити складність протоколу, усунувши непотрібні функції.

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

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

Дата закінчення ( статус досягнуто )

Feature cleanup(очищення функцій)

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

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

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

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

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

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

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

! [Віталік: Можливе майбутнє для Ethereum, The Purge] (ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg)

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

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

ІП-4444;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

! [Віталік: Можливе майбутнє Ethereum, чистка] ###ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg(

Закінчення терміну дії держави

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

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

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

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

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

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

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

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

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

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

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

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

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

![Vitalik: Можливе майбутнє Ethereum, The Purge]###