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

Автор: Віталік Бутерін

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

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

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

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

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

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

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

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

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

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

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

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

Очистка функцій（特征清理）

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

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

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

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

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

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

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

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

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

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

ІП-4444;

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

Portal мережа;

Portal мережа та EIP-4444；

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

Як підвищити обмеження gas (Paradigm).

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

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

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

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

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

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

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

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

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

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

Державна втрата дії

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основна різниця між цими пропозиціями полягає в тому, що: (i) ми як