Віталік: можливе майбутнє Ethereum, The Purge

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

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

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

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

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

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

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

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

Список статей:

Історія закінчення терміну дії（历史记录到期）

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

Очищення функцій（特征清理）

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

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

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

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

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

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

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

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

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

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

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

ІП-4444;

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

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

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

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

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

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

Залишилася основна робота, яка включає в себе створення та інтеграцію конкретного розподіленого рішення для зберігання історії ------ принаймні для виконання історії, але зрештою також включає консенсус і blob. Найпростіше рішення - це (i) просте введення існуючої бібліотеки torrent, а також (ii) відома як рідне рішення Ethereum під назвою Portal Network. Як тільки ми впровадимо будь-яке з них, ми зможемо відкрити 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(

) Часткова експірація стану

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