Одним из важных вызовов, с которыми сталкивается Ethereum, является снижение сложности и потребностей в хранении в долгосрочной перспективе, сохраняя при этом долговечность и децентрализованность цепочки. Чтобы Ethereum мог существовать в долгосрочной перспективе, нам необходимо оказать сильное противодействие сложности и расширению, снижая их с течением времени. Однако в то же время нам нужно сохранить долговечность блокчейна как ключевое свойство.
Основные цели очистки включают:
Снизить требования к хранению клиента, уменьшив или устранив необходимость в том, чтобы каждый узел постоянно хранил все исторические записи и даже окончательное состояние.
На текущий момент полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ для клиентской части консенсуса. Большая часть из этого — исторические данные, и даже если размер блока остается неизменным, размер узла будет продолжать увеличиваться на несколько сотен ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной характеристикой проблемы хранения истории является то, что каждый блок ссылается на предыдущий блок через хэш-ссылку, поэтому для достижения консенсуса в настоящем достаточно достичь консенсуса в истории. Это дает нам множество вариантов того, как хранить исторические записи. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных.
Теперь Ethereum начинает избавляться от модели, при которой все узлы перманентно хранят всю историю. Консенсусные блоки хранятся лишь около 6 месяцев. Blob хранится примерно 18 дней. EIP-4444 нацелен на введение годового срока хранения для исторических блоков и квитанций. Долгосрочная цель состоит в создании единого периода, который может составлять около 18 дней, в течение которого каждый узел отвечает за хранение всего, а затем создание одноранговой сети из узлов Ethereum, которая будет хранить старые данные в распределенном виде.
( что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения исторических данных. Самым простым решением будет использование существующей библиотеки торрент или так называемого нативного решения Ethereum, известного как Portal Network. Основные компромиссы касаются того, как мы будем стремиться предоставлять "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные поставщики для репликации. Более сложный, но более безопасный путь — сначала построить и интегрировать сеть торрент для распределенного хранения исторических данных.
) как взаимодействует с другой частью дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то можно сказать, что снижение требований к историческому хранилищу важнее, чем без состояния. Только реализовав без состояния и EIP-4444, можно осуществить видение работы узла Ethereum на смарт-часах и его настройку всего за несколько минут.
Даже если мы устраним необходимость клиентам хранить историю, потребность в хранении у клиентов будет продолжать расти, примерно на 50 ГБ в год, так как состояние продолжает увеличиваться. Пользователи могут оплатить единовременный взнос, чтобы навсегда избавить нынешних и будущих клиентов Ethereum от этой нагрузки.
) Что это такое и как это работает?
Сегодня, когда создается новый объект состояния, этот объект всегда находится в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал с течением времени. Ключевым вызовом является достижение этого при реализации трех целей: эффективности, удобства для пользователей и удобства для разработчиков.
В настоящее время существует два типа "известных наименее плохих решений":
Решение по истечению срока некоторых статусов
Рекомендации по истечению срока состояния на основе временных периодов адреса
Часть предлагаемых статусов разбивает статус на блоки. Каждый навсегда хранит "верхнюю карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только если эта информация была недавно доступна. Существует механизм "воскрешения", если данные больше не хранятся.
Дизайн, основанный на периодах адресов, использует постоянно растущий список деревьев состояния, и любое чтение или запись состояния будет сохраняться в последнем дереве состояния. Каждый период ###, например: раз в год ### добавляется новое пустое дерево состояния. Старые деревья замораживаются. Полные узлы хранят только последние два дерева.
( Что еще нужно сделать, что нужно учесть?
Я считаю, что в будущем существует четыре жизнеспособных пути:
Мы достигаем безсостояния и никогда не вводим истекшее состояние.
Мы осуществляем частичный срок действия статуса и принимаем гораздо более низкую, но все же ненулевую скорость роста постоянного размера статуса.
Мы осуществляем истечение состояния через расширение адресного пространства.
Мы осуществляем истечение состояния через сжатие адресного пространства.
Важный момент заключается в том, что независимо от того, будет ли реализована схема истечения срока, зависящая от изменения формата адреса, в конечном итоге необходимо решить проблему расширения и сжатия адресного пространства.
Один из ключевых предварительных условий безопасности, доступности и доверительной нейтральности — это простота. Если протокол красив и прост, это снижает вероятность возникновения ошибок. Это увеличивает шансы новых разработчиков участвовать в любой части. Он с большей вероятностью будет справедливым и легче противостоять специальным интересам. К сожалению, протокол, как и любая социальная система, по умолчанию со временем становится все более сложным.
) Что это такое и как это работает?
Нет никакого единого значительного решения, которое могло бы снизить сложность протокола; суть проблемы заключается в том, что существует множество небольших решений. Некоторые ключевые примеры включают:
Преобразование RLP → SSZ
Удалить старый тип транзакции
ЛОГ Реформа
Окончательное удаление механизма синхронизации комитета маяка
Унифицированный формат данных
Удалить комитет по цепочке сигналов
Удалить смешанный порядок байтов
Упрощение механизма газа
Удалить предкомпилированный
Удаление наблюдаемости газа
Улучшение статического анализа
Что еще нужно сделать, что нужно учитывать?
Основной компромисс при упрощении этой функции заключается в степени и скорости упрощения и обратной совместимости. Более широкая социальная проблема заключается в создании стандартизированного канала для внесения изменений, которые нарушают обратную совместимость, не относящихся к экстренным случаям.
Формат объекта EVM ###EOF### представляет собой набор основных изменений, предложенных для EVM. Его преимущества заключаются в создании естественного пути для добавления новых функций EVM и поощрении перехода на более строгий EVM с более высокими гарантиями. Его недостатком является значительное увеличение сложности протокола, если только мы не сможем найти способ окончательно отказаться от старого EVM и удалить его.
Более радикальная стратегия упрощения Ethereum заключается в том, чтобы оставить протокол неизменным, но перенести большую часть функциональности протокола в код контрактов. Самая крайняя версия заключается в том, чтобы сделать Ethereum L1 "технически" просто цепочкой сигналов, и ввести минимальную виртуальную машину, позволяющую другим создавать свои собственные агрегаты. Затем EVM станет первым из этих агрегатов.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Путь к очищению Ethereum: Падение сложности и долгосрочные проблемы с хранением
Будущее Ethereum: очищение
Одним из важных вызовов, с которыми сталкивается Ethereum, является снижение сложности и потребностей в хранении в долгосрочной перспективе, сохраняя при этом долговечность и децентрализованность цепочки. Чтобы Ethereum мог существовать в долгосрочной перспективе, нам необходимо оказать сильное противодействие сложности и расширению, снижая их с течением времени. Однако в то же время нам нужно сохранить долговечность блокчейна как ключевое свойство.
Основные цели очистки включают:
Снизить требования к хранению клиента, уменьшив или устранив необходимость в том, чтобы каждый узел постоянно хранил все исторические записи и даже окончательное состояние.
Снизить сложность протокола, устранив ненужные функции.
! Виталик: возможное будущее для Ethereum, чистка
История истекает
Какую проблему решает?
На текущий момент полностью синхронизированному узлу Ethereum требуется около 1,1 ТБ дискового пространства для работы клиента, а также несколько сотен ГБ для клиентской части консенсуса. Большая часть из этого — исторические данные, и даже если размер блока остается неизменным, размер узла будет продолжать увеличиваться на несколько сотен ГБ каждый год.
Что это такое и как это работает?
Ключевой упрощенной характеристикой проблемы хранения истории является то, что каждый блок ссылается на предыдущий блок через хэш-ссылку, поэтому для достижения консенсуса в настоящем достаточно достичь консенсуса в истории. Это дает нам множество вариантов того, как хранить исторические записи. Естественным выбором является сеть, в которой каждый узел хранит лишь небольшую часть данных.
Теперь Ethereum начинает избавляться от модели, при которой все узлы перманентно хранят всю историю. Консенсусные блоки хранятся лишь около 6 месяцев. Blob хранится примерно 18 дней. EIP-4444 нацелен на введение годового срока хранения для исторических блоков и квитанций. Долгосрочная цель состоит в создании единого периода, который может составлять около 18 дней, в течение которого каждый узел отвечает за хранение всего, а затем создание одноранговой сети из узлов Ethereum, которая будет хранить старые данные в распределенном виде.
( что еще нужно сделать, что нужно взвесить?
Оставшаяся основная работа включает в себя создание и интеграцию конкретного распределенного решения для хранения исторических данных. Самым простым решением будет использование существующей библиотеки торрент или так называемого нативного решения Ethereum, известного как Portal Network. Основные компромиссы касаются того, как мы будем стремиться предоставлять "древние" исторические данные. Самое простое решение — остановить хранение древней истории завтра и полагаться на существующие архивные узлы и различные централизованные поставщики для репликации. Более сложный, но более безопасный путь — сначала построить и интегрировать сеть торрент для распределенного хранения исторических данных.
) как взаимодействует с другой частью дорожной карты?
Если мы хотим, чтобы запуск или работа узлов стали исключительно простыми, то можно сказать, что снижение требований к историческому хранилищу важнее, чем без состояния. Только реализовав без состояния и EIP-4444, можно осуществить видение работы узла Ethereum на смарт-часах и его настройку всего за несколько минут.
! [Виталик: Возможное будущее Ethereum, Чистка]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp###
Состояние истекло
( Какую проблему решает?
Даже если мы устраним необходимость клиентам хранить историю, потребность в хранении у клиентов будет продолжать расти, примерно на 50 ГБ в год, так как состояние продолжает увеличиваться. Пользователи могут оплатить единовременный взнос, чтобы навсегда избавить нынешних и будущих клиентов Ethereum от этой нагрузки.
) Что это такое и как это работает?
Сегодня, когда создается новый объект состояния, этот объект всегда находится в этом состоянии. Напротив, мы хотим, чтобы объект автоматически истекал с течением времени. Ключевым вызовом является достижение этого при реализации трех целей: эффективности, удобства для пользователей и удобства для разработчиков.
В настоящее время существует два типа "известных наименее плохих решений":
Часть предлагаемых статусов разбивает статус на блоки. Каждый навсегда хранит "верхнюю карту", где блоки могут быть пустыми или непустыми. Данные в каждом блоке хранятся только если эта информация была недавно доступна. Существует механизм "воскрешения", если данные больше не хранятся.
Дизайн, основанный на периодах адресов, использует постоянно растущий список деревьев состояния, и любое чтение или запись состояния будет сохраняться в последнем дереве состояния. Каждый период ###, например: раз в год ### добавляется новое пустое дерево состояния. Старые деревья замораживаются. Полные узлы хранят только последние два дерева.
( Что еще нужно сделать, что нужно учесть?
Я считаю, что в будущем существует четыре жизнеспособных пути:
Важный момент заключается в том, что независимо от того, будет ли реализована схема истечения срока, зависящая от изменения формата адреса, в конечном итоге необходимо решить проблему расширения и сжатия адресного пространства.
! [Виталик: Возможное будущее Ethereum, Чистка])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###
Очистка функций
( Какую проблему решает?
Один из ключевых предварительных условий безопасности, доступности и доверительной нейтральности — это простота. Если протокол красив и прост, это снижает вероятность возникновения ошибок. Это увеличивает шансы новых разработчиков участвовать в любой части. Он с большей вероятностью будет справедливым и легче противостоять специальным интересам. К сожалению, протокол, как и любая социальная система, по умолчанию со временем становится все более сложным.
) Что это такое и как это работает?
Нет никакого единого значительного решения, которое могло бы снизить сложность протокола; суть проблемы заключается в том, что существует множество небольших решений. Некоторые ключевые примеры включают:
Что еще нужно сделать, что нужно учитывать?
Основной компромисс при упрощении этой функции заключается в степени и скорости упрощения и обратной совместимости. Более широкая социальная проблема заключается в создании стандартизированного канала для внесения изменений, которые нарушают обратную совместимость, не относящихся к экстренным случаям.
Формат объекта EVM ###EOF### представляет собой набор основных изменений, предложенных для EVM. Его преимущества заключаются в создании естественного пути для добавления новых функций EVM и поощрении перехода на более строгий EVM с более высокими гарантиями. Его недостатком является значительное увеличение сложности протокола, если только мы не сможем найти способ окончательно отказаться от старого EVM и удалить его.
Более радикальная стратегия упрощения Ethereum заключается в том, чтобы оставить протокол неизменным, но перенести большую часть функциональности протокола в код контрактов. Самая крайняя версия заключается в том, чтобы сделать Ethereum L1 "технически" просто цепочкой сигналов, и ввести минимальную виртуальную машину, позволяющую другим создавать свои собственные агрегаты. Затем EVM станет первым из этих агрегатов.
! [Виталик: возможное будущее Ethereum, чистка] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)