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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Щодо (2), базова реалізація лише стосується роботи, яка вже була завершена сьогодні: 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))? Конкретна пропозиція - це EIP-7736, яка базується на дизайні "гілок і листків", введеному для дерев Веркла ((), хоча вона сумісна з будь-якою формою безстану, такою як двійкові дерева ()). У цьому дизайні заголовки, код та слоти зберігання, які знаходяться поряд один з одним, зберігаються під одним "стовбуром". Дані, що зберігаються під одним стовбуром, можуть становити максимум 256 * 31 = 7,936 байт. У багатьох випадках весь заголовок і код рахунку, а також багато ключів слота зберігання будуть зберігатися під одним і тим же стовбуром. Якщо дані під даним стовбуром не будуть прочитані або записані протягом 6 місяців, ці дані більше не зберігатимуться, а лише зберігатиметься їх 32-байтний комітмент "зразок" ((). Транзакції для доступу до цих даних у майбутньому вимагатимуть "воскресіння" даних і надання доказів для перевірки за зразком.

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

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