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

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

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

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

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

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

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

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

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

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

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

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

Державна дата закінчення (状态到期)

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

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

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

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

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

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

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

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

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

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

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

ІП-4444;

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

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

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

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

Як підвищити ліміт газу (Paradigm).

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

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

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

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

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

Екстремальний параноїдальний підхід до (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) налаштувавши раніше не використане сховище), цей об'єкт стану назавжди залишатиметься в цьому стані. Натомість, що ми хочемо, так це те, щоб об'єкт автоматично застарів з часом. Ключовим викликом є досягнення цього трьох цілей.

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

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

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

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

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

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

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

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

Основна різниця між цими пропозиціями полягає в тому, як ми визначаємо "недавній"