Vitalik написав статтю про майбутній розвиток протоколу Ethereum з назвою The Purge, метою якої є зниження потреб у сховищах Падіння та складності протоколу Ethereum.

Odaily Зоряна Новин Віталік оголосив про майбутній розвиток протоколу Ethereum (частина 5: The Purge), основні цілі наступні: Шляхом зменшення або усунення потреби кожної Нода в постійному зберіганні всіх історичних навіть станових даних, Падіння вимог до зберігання клієнтського програмного забезпечення; Шляхом усунення непотрібних особливостей Падінняпротоколу складності. У тексті зазначено, що Ethereum вже почав вийти з режиму, в якому ноди постійно зберігають всю історію. Частина блока консенсусу (тобто частина, пов'язана з Proof of Stake) зберігається лише протягом близько 6 місяців. Blob зберігається лише протягом близько 18 днів. EIP-4444 спрямований на введення однорічного терміну зберігання для старих блоків та квитанцій. Довгостроковою метою є наявність координованого періоду (можливо, близько 18 днів), протягом якого кожна нода відповідає за зберігання всього вмісту, а потім старі дані розподіляються мережею парних нод Ethereum у розподіленому режимі. Помимо потребности в хранении истории клиента, потребность в хранении клиента все еще будет расти, примерно на 50 ГБ в год, поскольку состояние продолжает расти: баланс счета и случайное число, код контракта и хранилище контракта. Пользователи могут заплатить единовременную плату, чтобы облегчить нагрузку на клиент ETH для настоящего и будущего. У складних умовах Падінняпротоколу потрібно зробити дві речі: Зупиніть зміни та зробітьпротокол僵化; Може фактично видалити функціональність та Падіння складності. Крім того, Віталік зазначає, що більш радикальний підхід до складності Падіння залишає протокол таким, яким він є, але переносить більшу його частину з функціоналу протоколу на код контракту; Більш м'яким підходом було б зберегти зв'язок між сигнальною мережею та поточним середовищем виконання ETH Fang, вибравши RISC-V, Cairo або іншу віртуальну машину як нову «Офіційну віртуальну машину ETH Fang», а потім примусово конвертувавши всі контракти EVM у новий код віртуальної машини, який пояснює оригінальну логіку коду (або компіляцією, або інтерпретацією). Теоретично це можна зробити навіть за допомогою «цільової віртуальної машини» як версії EOF.