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

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

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

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

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

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

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

ІП-4444;

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

Портал мережі;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Державний термін дії

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

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

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

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

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

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

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

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

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

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

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

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

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

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