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

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

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

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

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

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

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

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

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

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

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

Історія закінчення терміну дії(історичних записів досягла терміну дії) Стан закінчення терміну дії( Очищення функцій)特征清理(

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

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

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

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

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

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

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

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

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

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

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

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

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

)# Частковий термін дії стану

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

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