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

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

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

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

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

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

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

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

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

• Зменшити складність протоколу, усуваючи непотрібні функції.

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

• Історія закінчення терміну дії（历史记录到期）
• Закінчення терміну дії
• Очистка функцій

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

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

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

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

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

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

Це надає нам багато варіантів для зберігання історичних записів. Природним вибором є мережа, в якій кожен вузол зберігає лише невелику частину даних. Саме так функціонують мережі насіння протягом десятиліть: хоча мережа загалом зберігає та розповсюджує мільйони файлів, кожен учасник зберігає та розповсюджує лише кілька з них. Можливо, всупереч інтуїції, цей підхід навіть не обов'язково знижує стійкість даних. Якщо, зробивши роботу вузлів більш економічною, ми зможемо створити мережу з 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) просто впровадити існуючу бібліотеку торрентів, а також (ii) рішення, що базується на Ethereum, яке називається Portal Network. Як тільки ми впровадимо одне з них, ми зможемо активувати EIP-4444. EIP-4444 сам по собі не потребує жорсткого хардфорку, але він дійсно потребує нової версії мережевого протоколу. Тому корисно активувати його одночасно для всіх клієнтів, інакше існує ризик, що клієнти з'єднаються з іншими вузлами, сподіваючись завантажити повну історію, але насправді не отримають її.

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

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

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

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

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

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

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

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

Вичерпання стану

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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