Один із викликів, з якими стикається Ethereum, полягає в тому, що за замовчуванням розширення та складність будь-якого блокчейн-протоколу з часом зростають. Це відбувається в двох аспектах:
Історичні дані: Будь-які транзакції, здійснені в будь-який момент в історії, та будь-які облікові записи, створені в цей час, повинні зберігатися всіма клієнтами назавжди і завантажуватися новими клієнтами, щоб повністю синхронізуватися з мережею. Це призведе до збільшення навантаження на клієнтів і часу синхронізації з плином часу, навіть якщо ємність ланцюга залишиться незмінною.
Функція протоколу: Додавати нові функції значно легше, ніж видаляти старі, що призводить до збільшення складності коду з часом.
Щоб Ethereum міг довгостроково зберігати свою життєздатність, нам потрібно посилити антипресії до цих двох тенденцій, зменшуючи складність і розширення з часом. Але водночас ми повинні зберегти одну з ключових властивостей, яка робить блокчейн великим: тривалість. Ви можете розмістити NFT, любовний лист у даних транзакцій або смарт-контракт на 1 мільйон доларів на ланцюгу, зайти в печеру на десять років, а коли вийдете, виявити, що він все ще чекає вас для читання та взаємодії. Щоб DApp могли повністю децентралізуватися та видалити ключі оновлення, їм потрібно бути впевненими, що їх залежності не оновляться у спосіб, який може їх зруйнувати - особливо L1.
Якщо ми вирішимо досягти балансу між цими двома потребами та максимально зменшити або повернути назад громіздкість, складність і занепад, зберігаючи при цьому безперервність, це абсолютно можливо. Біологічні організми можуть це зробити: хоча більшість організмів старіють з часом, нещасливчики не старіють. Навіть соціальні системи можуть мати дуже тривалий термін служби. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT в основному зник, вузли Beacon Chain зберігали старі дані до шести місяців. Знайти цей шлях для Ethereum більш загальним чином і рухатися до довгострокового стабільного кінцевого результату є остаточним викликом для довгострокової масштабованості 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), відоме як нативне рішення Ethereum під назвою Portal Network. Як тільки ми впровадимо будь-який з цих варіантів, ми зможемо відкрити EIP-4444. EIP-4444 сам по собі не вимагає жорсткого хардфорка, але дійсно вимагає нової версії мережевого протоколу. Тому було б доцільно активувати його одночасно для всіх клієнтів, інакше існує ризик, що клієнти зазнають збоїв через підключення до інших вузлів, очікуючи завантажити повну історію, але насправді не отримуючи її.
Основні компроміси стосуються того, як ми намагаємося надати "давні" історичні дані. Найпростіше рішення – це завтра зупинити зберігання давніх історій і покладатися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Це легко, але це підриває позицію Ethereum як постійного місця запису. Більш складний, але більш безпечний шлях – спочатку побудувати і інтегрувати торент-мережу для розподіленого зберігання історії. Тут "наскільки ми старанні" має два виміри:
Як ми намагаємось забезпечити, щоб найбільший набір вузлів дійсно зберігав усі дані?
Наскільки глибоким є інтеграція історичного зберігання в протокол?
Екстремальний параноїдальний підхід до (1) передбачає доказ володіння: фактично вимагає від кожного валідатора на основі підтвердження володіння зберігати певний відсоток історії та регулярно зашифровано перевіряти, чи вони це роблять. Помірніший підхід — встановити добровільний стандарт для відсотка історії, що зберігається кожним клієнтом.
Щодо (2), базова реалізація стосується лише роботи, яка вже була завершена сьогодні: Портал вже зберігає ERA-файл, що містить всю історію Ethereum. Більш ґрунтовна реалізація передбачатиме фактичне підключення до процесу синхронізації, так що, якщо хтось захоче синхронізувати повну історію зберігання вузлів або архівних вузлів, навіть якщо інші архівні вузли не активні онлайн, вони можуть досягти цього через пряму синхронізацію з мережі порталу.
Як це взаємодіє з іншими частинами дорожньої карти?
Якщо ми хочемо, щоб запуск або запуск вузлів став надзвичайно простим, то зменшення вимог до зберігання історії можна вважати важливішим за безстанність: з 1,1 ТБ, необхідних для вузлів, близько 300 ГБ — це стан, а решта приблизно 800 ГБ стала історією. Лише реалізувавши безстанність та EIP-4444, можна досягти візії, що дозволяє запускати вузол Ethereum на смарт-годиннику та налаштувати його всього за кілька хвилин.
Обмеження історичного зберігання також робить більш доцільним впровадження нових вузлів Ethereum, які підтримують лише останню версію протоколу, що робить їх простішими. Наприклад, тепер можна безпечно видалити багато рядків коду, оскільки всі порожні слоти пам'яті, створені під час DoS-атаки 2016 року, були видалені. Тепер, коли перехід до доказу частки став історією, клієнти можуть безпечно видалити весь код, пов'язаний з доказом роботи.
Державна сплату
Яку проблему вирішує?
Навіть якщо ми усунемо потребу в зберіганні історії клієнтом, потреба в зберіганні клієнта продовжить зростати, приблизно на 50 ГБ щороку, оскільки стан постійно зростає: баланси рахунків та випадкові числа, код контракту та зберігання контракту. Користувачі можуть сплатити одноразову плату, щоб назавжди покласти тягар на теперішніх і майбутніх клієнтів Ethereum.
Стан є більш складним, ніж історичний "термін придатності", оскільки EVM в основному був розроблений на основі припущення, що як тільки об'єкт стану створено, він завжди існуватиме і його можна буде читати з будь-якої транзакції в будь-який час. Якщо ми введемо безстанність, деякі вважають, що ця проблема може не бути такою вже й поганою: лише спеціалізованим класам будівельників блоків потрібно фактично зберігати стан, тоді як всі інші вузли (навіть ті, що містять генерацію списків!) можуть працювати без стану. Однак є думка, що ми не хочемо надмірно покладатися на безстанність, і зрештою ми можемо захотіти зробити стан застарілим для підтримки децентралізації Ethereum.
Сьогодні, коли ви створюєте новий об'єкт стану (це може статися одним із трьох способів: (i) відправивши ETH на новий рахунок, (ii) створивши новий рахунок за допомогою коду, (iii) налаштувавши раніше не торкнуту пам'ять), цей об'єкт стану залишиться в цьому стані назавжди. Натомість, ми хочемо, щоб об'єкт автоматично застарів з часом. Ключовим викликом є досягнення цього способом, який відповідає трьом цілям:
Ефективність: не потрібно великих додаткових обчислень для виконання процесу закінчення.
Дружність до користувача: якщо хтось зайде в печеру на п'ять років і повернеться, вони не повинні втратити доступ до ETH, ERC20, NFT, CDP позицій...
Дружелюбність до розробників: розробникам не потрібно переходити на зовсім незнайому модель мислення. Крім того, програми, які наразі є застарілими і не оновлюються, повинні продовжувати нормально працювати.
Недостатнє виконання цих цілей може легко призвести до проблем. Наприклад, ви можете змусити кожний об'єкт стану також зберігати лічильник дати закінчення (який може бути продовжений шляхом спалення ETH, що може відбуватися автоматично під час читання або запису в будь-який момент), і мати цикл, що проходить через стан для видалення об'єктів стану з простроченою датою. Проте це вводить додаткові обчислення (навіть вимоги до зберігання), і це, безсумнівно, не може задовольнити вимоги до зручності для користувача. Розробникам також важко логічно обґрунтувати крайні випадки, коли зберігані значення іноді скидаються до нуля. Якщо ви встановите таймер закінчення в межах контракту, це технічно полегшить життя розробникам, але ускладнить економіку: розробники повинні врахувати, як "перекласти" постійні витрати на зберігання на користувачів.
! [Віталік: Можливе майбутнє Ethereum, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Це все проблеми, які ядро розробницької спільноти Ethereum намагалося вирішити протягом багатьох років, включаючи пропозиції «оренда блокчейну» та «відновлення». Нарешті, ми об'єднали найкращі частини пропозицій і зосередилися на двох категоріях «найменш поганих відомих рішень»:
Рішення для деяких застарілих статусів
Пропозиція про терміни закінчення стану на основі циклів адрес.
Часткове закінчення стану
Частина термінових пропозицій дотримується тих самих принципів. Ми ділимо статуси на блоки. Кожен постійно зберігає "верхню мапу", в якій блоки порожні.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Ethereum The Purge: зменшення складності підвищення сталості та безпеки
Можливе майбутнє Ethereum: чистка
Один із викликів, з якими стикається Ethereum, полягає в тому, що за замовчуванням розширення та складність будь-якого блокчейн-протоколу з часом зростають. Це відбувається в двох аспектах:
Історичні дані: Будь-які транзакції, здійснені в будь-який момент в історії, та будь-які облікові записи, створені в цей час, повинні зберігатися всіма клієнтами назавжди і завантажуватися новими клієнтами, щоб повністю синхронізуватися з мережею. Це призведе до збільшення навантаження на клієнтів і часу синхронізації з плином часу, навіть якщо ємність ланцюга залишиться незмінною.
Функція протоколу: Додавати нові функції значно легше, ніж видаляти старі, що призводить до збільшення складності коду з часом.
Щоб Ethereum міг довгостроково зберігати свою життєздатність, нам потрібно посилити антипресії до цих двох тенденцій, зменшуючи складність і розширення з часом. Але водночас ми повинні зберегти одну з ключових властивостей, яка робить блокчейн великим: тривалість. Ви можете розмістити NFT, любовний лист у даних транзакцій або смарт-контракт на 1 мільйон доларів на ланцюгу, зайти в печеру на десять років, а коли вийдете, виявити, що він все ще чекає вас для читання та взаємодії. Щоб DApp могли повністю децентралізуватися та видалити ключі оновлення, їм потрібно бути впевненими, що їх залежності не оновляться у спосіб, який може їх зруйнувати - особливо L1.
Якщо ми вирішимо досягти балансу між цими двома потребами та максимально зменшити або повернути назад громіздкість, складність і занепад, зберігаючи при цьому безперервність, це абсолютно можливо. Біологічні організми можуть це зробити: хоча більшість організмів старіють з часом, нещасливчики не старіють. Навіть соціальні системи можуть мати дуже тривалий термін служби. У деяких випадках Ethereum вже досяг успіху: доказ роботи зник, операційний код SELFDESTRUCT в основному зник, вузли Beacon Chain зберігали старі дані до шести місяців. Знайти цей шлях для Ethereum більш загальним чином і рухатися до довгострокового стабільного кінцевого результату є остаточним викликом для довгострокової масштабованості Ethereum, технологічної стійкості та навіть безпеки.
! Віталік: Можливе майбутнє для Ethereum, очищення
The Purge: Основна мета.
Зменшити вимоги до зберігання клієнтів, зменшуючи або усуваючи потребу в постійному зберіганні всіх історичних записів або навіть остаточного стану кожним вузлом.
Зниження складності протоколу шляхом усунення непотрібних функцій.
Структура статті:
Історія закінчення терміну дії（历史记录到期）
Державна дата закінчення (状态到期)
Прибирання функцій
Історія закінчення терміну дії
Яку проблему вирішує?
Станом на момент написання цієї статті, повністю синхронізовані вузли Ethereum потребують близько 1,1 ТБ дискового простору для виконання клієнта, а також ще кілька сотень ГБ дискового простору для клієнта консенсусу. Переважна більшість — це історичні дані: дані про історичні блоки, транзакції та квитанції, більшість з яких має кількарічну історію. Це означає, що навіть якщо обмеження Gas зовсім не зростатимуть, розмір вузлів продовжуватиме збільшуватися на кілька сотень ГБ щороку.
Що це таке, як це працює?
Ключовою спрощеною характеристикою проблеми зберігання історії є те, що оскільки кожен блок через хеш-посилання (та інші структури) вказує на попередній блок, достатньо досягти консенсусу щодо поточного блоку, щоб досягти консенсусу щодо історії. Доки мережа досягає консенсусу щодо останнього блоку, будь-який історичний блок, транзакція чи стан (баланс рахунку, випадкове число, код, сховище) можуть бути надані будь-яким окремим учасником, а також доказом Меркла, і цей доказ дозволяє будь-кому іншому перевірити його правильність. Консенсус є моделлю довіри 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) просте впровадження існуючої бібліотеки torrent, а також (ii), відоме як нативне рішення Ethereum під назвою Portal Network. Як тільки ми впровадимо будь-який з цих варіантів, ми зможемо відкрити EIP-4444. EIP-4444 сам по собі не вимагає жорсткого хардфорка, але дійсно вимагає нової версії мережевого протоколу. Тому було б доцільно активувати його одночасно для всіх клієнтів, інакше існує ризик, що клієнти зазнають збоїв через підключення до інших вузлів, очікуючи завантажити повну історію, але насправді не отримуючи її.
Основні компроміси стосуються того, як ми намагаємося надати "давні" історичні дані. Найпростіше рішення – це завтра зупинити зберігання давніх історій і покладатися на існуючі архівні вузли та різні централізовані постачальники для копіювання. Це легко, але це підриває позицію Ethereum як постійного місця запису. Більш складний, але більш безпечний шлях – спочатку побудувати і інтегрувати торент-мережу для розподіленого зберігання історії. Тут "наскільки ми старанні" має два виміри:
Як ми намагаємось забезпечити, щоб найбільший набір вузлів дійсно зберігав усі дані?
Наскільки глибоким є інтеграція історичного зберігання в протокол?
Екстремальний параноїдальний підхід до (1) передбачає доказ володіння: фактично вимагає від кожного валідатора на основі підтвердження володіння зберігати певний відсоток історії та регулярно зашифровано перевіряти, чи вони це роблять. Помірніший підхід — встановити добровільний стандарт для відсотка історії, що зберігається кожним клієнтом.
Щодо (2), базова реалізація стосується лише роботи, яка вже була завершена сьогодні: Портал вже зберігає 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, Очищення] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
Це все проблеми, які ядро розробницької спільноти Ethereum намагалося вирішити протягом багатьох років, включаючи пропозиції «оренда блокчейну» та «відновлення». Нарешті, ми об'єднали найкращі частини пропозицій і зосередилися на двох категоріях «найменш поганих відомих рішень»:
Часткове закінчення стану
Частина термінових пропозицій дотримується тих самих принципів. Ми ділимо статуси на блоки. Кожен постійно зберігає "верхню мапу", в якій блоки порожні.