Возможное будущее Ethereum: чистка

С 14 октября основатель Ethereum Виталик Бутерин последовательно опубликовал серию обсуждающих статей о будущем развития Ethereum, от «Слияния» до последней «Очистки», демонстрируя свои идеи о будущем развития основной сети Ethereum и решения текущих проблем.

Статья «The Purge» исследует, как Ethereum может снизить сложность и требования к хранению в долгосрочной перспективе, сохраняя при этом долговечность и децентрализацию цепочки. Основные меры включают снижение нагрузки на хранение клиентов за счет «исторического истечения» и «состояния истечения», а также упрощение протокола с помощью «очистки характеристик» для обеспечения устойчивости и масштабируемости сети.

! Виталик: возможное будущее для Ethereum, чистка

History expiry История истекла

Решает какую проблему?

В настоящее время для полноценной синхронизации узла Ethereum требуется около 1,1 ТБ дискового пространства для выполнения клиента, а также несколько сотен ГБ для клиентской части консенсуса. Большая часть этого объема - это исторические данные, и даже если лимит Gas останется неизменным, размер узла будет увеличиваться на несколько сотен ГБ каждый год.

Что это такое и как это работает?

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

Ethereum уже начала отходить от модели, при которой все узлы постоянно хранят всю историю. Консенсусные блоки хранятся только около 6 месяцев, а Blob только около 18 дней. EIP-4444 нацелен на введение одного года срока хранения для исторических блоков и квитанций. Долгосрочной целью является установление единого срока хранения около 18 дней, а затем создание P2P сети, состоящей из узлов Эфира, для распределенного хранения старых данных.

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

! Виталик: Возможное будущее Ethereum, Чистка

Что еще нужно сделать, что нужно учесть?

Основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения истории. Самое простое решение – это внедрение существующих торрент-библиотек или использование нативного решения Эфира, известного как Portal сеть.

Основные весы касаются того, как стараться предоставить "древние" исторические данные. Самое простое решение — немедленно прекратить хранение древней истории, полагаясь на существующие архивные узлы. Более безопасное, но более сложное решение — сначала построить и интегрировать торрент-сеть.

с взаимодействием других частей дорожной карты

Снижение потребности в историческом хранении данных крайне важно для упрощения работы узлов. Только реализовав безсостояние и EIP-4444, можно достичь видения о запуске узла Ethereum на смарт-часах.

Ограничение исторического хранения также делает более жизнеспособным внедрение новых узлов Ethereum, поддерживающих только последние версии протокола, тем самым упрощая клиент.

Срок действия состояния истекает

Что решает?

Даже если устранить потребность в хранении истории, потребность в хранении на стороне клиента будет увеличиваться примерно на 50 ГБ в год, так как состояние (, баланс счетов, коды контрактов и другие ) будут продолжать расти. Пользователи могут заплатить единовременно, что создаст постоянную нагрузку для нынешних и будущих клиентов.

Что это такое и как это работает?

Статус сложнее "исторического", потому что EVM предполагает, что объект состояния существует вечно после его создания. Цель состоит в том, чтобы объекты автоматически устаревали со временем, при этом оставаясь эффективными, удобными для пользователей и разработчиков.

Существует два основных типа решений:

1. Часть состояния истекает: состояние разбивается на блоки, хранятся только недавно посещенные данные. EIP-7736 предлагает решение на основе дерева Verkle, 32 байта корня хранятся для данных, не посещенных в течение 6 месяцев.

2. Истечение состояния на основе адресного цикла: использование постоянно растущего списка деревьев состояния, с добавлением нового пустого дерева каждый год. Полные узлы хранят только последние два дерева. Истекшие данные требуют предоставления доказательства для чтения и записи.

! Виталик: Возможное будущее Ethereum, Чистка

Что еще нужно сделать, что нужно взвесить?

Будущие возможные пути включают:

1. Реализовать безсостояние, не вводить состояние срока действия. Состояние продолжает расти, но требует хранения только для специальных пользователей.

2. Реализовать частичное истечение статуса, принимая более низкий, но не нулевой постоянный темп роста статуса.

3. Реализация истечения состояния через расширение адресного пространства. Необходим многолетний процесс, чтобы гарантировать безопасность и эффективность конверсии формата адреса.

4. Реализация истечения состояния через сжатие адресного пространства. Необходимо много лет, чтобы гарантировать решение всех рисков безопасности.

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

! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)

Уборка функций

Что решает?

Простота протокола является ключом к безопасности, доступности и доверительной нейтральности. Однако протокол по умолчанию со временем становится более сложным. Нам нужно иметь возможность удалять функции и снижать сложность.

Что это такое и как это работает?

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

• Преобразование RLP в SSZ: замена кодирования RLP на лучшее кодирование SSZ
• Удалить старый тип транзакции
• Реформа LOG: удаление неиспользуемых функций, таких как фильтр Блума
• Удалить механизм синхронизации комитета по маячным цепочкам
• Унифицированный формат данных
• Удалить комитет по цепочке маяков
• Удалить смешанный порядок байтов

Некоторые примеры в EVM:

• Упрощение механизма газа
• Удалить предкомпилированный
• Удалить наблюдаемость газа
• Улучшение статического анализа: удаление динамических переходов

Что еще нужно сделать, что нужно взвесить?

Основные соображения – это степень упрощения и скорость по сравнению с обратной совместимостью. Необходимо создать стандартизированный процесс для внесения неэкстренных изменений, нарушающих обратную совместимость, включая анализ воздействия, официальное устаревание EIP, окончательное удаление и другие шаги.

Формат объекта EVM ( EOF ) предложил ряд изменений EVM, цель которых - позволить большее количество обновлений. Необходимо взвесить увеличенную сложность в сравнении с целью упрощения всей EVM.

Более радикальный подход заключается в том, чтобы преобразовать большую часть содержания протокола в код контрактов, например, преобразовать EVM в сводку или заменить EVM на новую VM. Это может значительно упростить протокол, но требует взвешивания совместимости.