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

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

Компіляція: Як це?

Особлива подяка за відгуки та рецензії Джастіну Дрейку, Тіму Бейко, Метту Гарнетту, Пайперу Мерріаму, Маріусу ван дер Вайдену та Томашу Станчаку.

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

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

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

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

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

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

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

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

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

Зміст статті:

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

Термін дії стану（状态到期）

Прибирання функцій（特征清理）

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

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

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

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

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

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

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

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

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

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

ІП-4444;

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

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

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

Розподіл та пошук об'єктів SSZ у Portal;

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

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

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

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

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

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

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

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

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

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

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

Державна сплата

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

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

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

! [Віталік: Можливе майбутнє Ethereum, The Purge]###https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(

)# Що це таке і як воно працює

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

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

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

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

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

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

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

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

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