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

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

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

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

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

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

Якщо ми вирішимо знайти баланс між цими двома потребами і максимально зменшити або повернути назад громіздкість, складність і занепад, зберігаючи при цьому безперервність, це абсолютно можливо. Організми можуть це зробити: хоча більшість організмів старіють з часом, деякі щасливчики цього не роблять. Навіть соціальні системи можуть мати дуже тривалий термін життя. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT більшою мірою зник, вузли Beacon Chain зберігали максимум шість місяців старих даних. Знайти цей шлях для 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.

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

• ІП-4444
• Торренти та EIP-4444
• Портал мережі
• Портальна мережа та EIP-4444
• Розподілене зберігання та отримання об'єктів SSZ у Portal
• Як підвищити ліміт gas ### Paradigm (

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

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

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

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

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

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

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

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

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

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

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

Закінчення терміну дії держави

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

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

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

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

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

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

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

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

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

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

• Часткове рішення для застарілих статусів
• Пропозиція про закінчення стану на основі періоду адреси

( ЧастковаExpiry частини стану

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

Основна різниця між цими пропозиціями полягає в тому: )i### як ми визначаємо "недавній", а також (ii) як ми визначаємо "блок"? Однією з конкретних пропозицій є EIP-7736, яка базується на дизайні "гілки-лістя", введеному для Verkle-дерев (, хоча і сумісна з будь-якою формою безстану, наприклад, бінарними деревами ). У цьому дизайні сусідні заголовки, код і сховища зберігаються під одним "стовбуром". Дані, що зберігаються під однією гілкою, можуть становити максимум 256 * 31 = 7,936 байтів. У багатьох випадках весь заголовок і код облікового запису, а також багато ключів сховищ будуть зберігатися під одним і тим же стовбуром. Якщо дані, що зберігаються під даним стовбуром, не були прочитані або записані протягом 6 місяців, ці дані більше не зберігаються, а зберігається лише 32 байти цих даних.