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

Одним із викликів, з якими стикається 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 як місця для постійного запису. Складніший, але більш безпечний шлях – спочатку побудувати та інтегрувати торент-мережу для розподіленого зберігання історії. Тут "як сильно ми намагаємося" має два виміри:

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

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

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

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

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