Способность запускать узлы Эфириума на скромном оборудовании критически важна для истинной децентрализации. Это связано с тем, что запуск узла дает пользователям возможность проверять информацию, выполняя криптографические проверки независимо, а не доверяя третьей стороне предоставлять им данные. Запуск узла позволяет пользователям отправлять транзакции напрямую в одноранговую сеть Эфириума, вместо того чтобы доверять посреднику. Децентрализация невозможна, если эти преимущества доступны только пользователям с дорогим оборудованием. Вместо этого узлы должны иметь возможность работать с крайне скромными требованиями к процессору и памяти, чтобы их можно было запускать на мобильных телефонах, микрокомпьютерах или незаметно на домашнем компьютере.
Сегодня высокие требования к дисковому пространству являются главным барьером, препятствующим всеобщему доступу к узлам. В первую очередь это связано с необходимостью хранить большие объемы данных состояния Эфириума. Эти данные состояния содержат критически важную информацию, необходимую для правильной обработки новых блоков и транзакций. На момент написания статьи для запуска полного узла Эфириума рекомендуется быстрый SSD-накопитель объемом 2 ТБ. Для узла, который не удаляет старые данные, требования к хранилищу растут примерно на 14 ГБ в неделю, а архивные узлы, хранящие все данные начиная с генезис-блока, приближаются к 12 ТБ (на момент написания статьи в феврале 2023 года).
Более дешевые жесткие диски можно использовать для хранения старых данных, но они слишком медленные, чтобы успевать за поступающими блоками. Сохранение текущих моделей хранения для клиентов при одновременном удешевлении и упрощении хранения данных является лишь временным и частичным решением проблемы, поскольку рост состояния Эфириума «неограничен», что означает, что требования к хранилищу могут только увеличиваться, и технологические улучшения всегда должны будут идти в ногу с постоянным ростом состояния. Вместо этого клиенты должны найти новые способы проверки блоков и транзакций, которые не зависят от поиска данных в локальных базах данных.
Сокращение объема хранилища для узлов
Существует несколько способов уменьшить объем данных, которые должен хранить каждый узел, и каждый из них требует обновления базового протокола Эфириума в разной степени:
- Экспирация истории: позволяет узлам отбрасывать данные состояния старше X блоков, но не меняет того, как клиенты Эфириума обрабатывают данные состояния.
- Истечение срока действия состояния: позволяет данным состояния, которые не используются часто, становиться неактивными. Неактивные данные могут игнорироваться клиентами до тех пор, пока они не будут восстановлены.
- Слабое отсутствие состояния: только создателям блоков нужен доступ к полным данным состояния, остальные узлы могут проверять блоки без локальной базы данных состояния.
- Сильное отсутствие состояния: ни одному узлу не нужен доступ к полным данным состояния.
Экспирация данных
Экспирация истории
Экспирация истории означает, что клиенты удаляют старые данные, которые им вряд ли понадобятся, так что они хранят лишь небольшой объем исторических данных, отбрасывая старые данные при поступлении новых. Есть две причины, по которым клиентам требуются исторические данные: синхронизация и обслуживание запросов данных. Изначально клиентам приходилось выполнять синхронизацию начиная с генезис-блока, проверяя правильность каждого последующего блока вплоть до вершины цепи. Сегодня клиенты используют «контрольные точки слабой субъективности», чтобы ускорить свой путь к вершине цепи. Эти контрольные точки являются доверенными отправными точками, подобно наличию генезис-блока ближе к настоящему времени, а не в самом начале существования Эфириума. Это означает, что клиенты могут отбросить всю информацию до самой последней контрольной точки слабой субъективности, не теряя возможности синхронизации с вершиной цепи. В настоящее время клиенты обслуживают запросы (поступающие через JSON-RPC) на исторические данные, извлекая их из своих локальных баз данных. Однако при экспирации истории это будет невозможно, если запрошенные данные были удалены. Именно для обслуживания этих исторических данных требуются некоторые инновационные решения.
Один из вариантов заключается в том, что клиенты запрашивают исторические данные у пиров, используя такое решение, как Портал Нетворк. Портал Нетворк — это разрабатываемая одноранговая сеть для обслуживания исторических данных, где каждый узел хранит небольшую часть истории Эфириума, так что вся история существует в распределенном виде по всей сети. Запросы обслуживаются путем поиска пиров, хранящих соответствующие данные, и их запроса у них. В качестве альтернативы, поскольку доступ к историческим данным обычно требуется приложениям, их хранение может стать их обязанностью. В пространстве Эфириума также может быть достаточно альтруистичных участников, которые были бы готовы поддерживать исторические архивы. Это может быть ДАО, созданная для управления хранением исторических данных, или, в идеале, это будет комбинация всех этих вариантов. Эти провайдеры могли бы предоставлять данные множеством способов, например, через торренты, FTP, Filecoin или IPFS.
Экспирация истории вызывает некоторые споры, поскольку до сих пор Эфириум всегда неявно гарантировал доступность любых исторических данных. Полная синхронизация начиная с генезис-блока всегда была возможна по умолчанию, даже если она опирается на восстановление некоторых старых данных из снимков. Экспирация истории переносит ответственность за предоставление этой гарантии за пределы базового протокола Эфириума. Это может создать новые риски цензуры, если в конечном итоге предоставлением исторических данных займутся централизованные организации.
EIP-4444 еще не готов к выпуску, но активно обсуждается. Интересно, что проблемы с EIP-4444 носят не столько технический характер, сколько связаны с управлением сообществом. Для того чтобы это было реализовано, необходима поддержка сообщества, которая включает не только согласие, но и обязательства по хранению и предоставлению исторических данных от заслуживающих доверия организаций.
Это обновление не меняет фундаментально то, как узлы Эфириума обрабатывают данные состояния, оно лишь меняет способ доступа к историческим данным.
Истечение срока действия состояния
Истечение срока действия состояния означает удаление состояния с отдельных узлов, если к нему не обращались в последнее время. Существует несколько способов реализации этого, включая:
- Истечение срока по аренде: взимание «арендной платы» с аккаунтов и истечение их срока действия, когда их арендная плата достигает нуля.
- Истечение срока по времени: перевод аккаунтов в неактивное состояние, если в течение некоторого времени не происходит чтения/записи в этот аккаунт.
Истечение срока по аренде может представлять собой прямую арендную плату, взимаемую с аккаунтов за их сохранение в базе данных активного состояния. Истечение срока по времени может осуществляться путем обратного отсчета с момента последнего взаимодействия с аккаунтом, или это может быть периодическое истечение срока действия всех аккаунтов. Также могут существовать механизмы, объединяющие элементы моделей, основанных как на времени, так и на аренде, например, отдельные аккаунты сохраняются в активном состоянии, если они платят небольшую комиссию до истечения срока действия по времени. В случае истечения срока действия состояния важно отметить, что неактивное состояние не удаляется, оно просто хранится отдельно от активного состояния. Неактивное состояние может быть восстановлено в активное состояние.
Вероятно, это будет работать так: будет существовать дерево состояния для определенных периодов времени (возможно, ~1 год). Всякий раз, когда начинается новый период, создается совершенно новое дерево состояния. Только текущее дерево состояния может быть изменено, все остальные являются неизменяемыми. Ожидается, что узлы Эфириума будут хранить только текущее дерево состояния и предыдущее. Для этого требуется способ присвоения адресу временной метки с указанием периода, в котором он существует. Существует несколько возможных способов (opens in a new tab) сделать это, но ведущий вариант требует удлинения адресов (opens in a new tab) для размещения дополнительной информации с дополнительным преимуществом, заключающимся в том, что более длинные адреса намного безопаснее. Пункт дорожной карты, который это реализует, называется расширением адресного пространства (opens in a new tab).
Аналогично экспирации истории, при истечении срока действия состояния ответственность за хранение старых данных состояния снимается с отдельных пользователей и перекладывается на другие организации, такие как централизованные провайдеры, альтруистичные члены сообщества или более футуристические децентрализованные решения, такие как Портал Нетворк.
Истечение срока действия состояния все еще находится на стадии исследования и пока не готово к выпуску. Истечение срока действия состояния вполне может произойти позже, чем внедрение клиентов без состояния и экспирации истории, поскольку эти обновления делают большие размеры состояния легко управляемыми для большинства валидаторов.
Отсутствие состояния
Термин «отсутствие состояния» немного ошибочен, поскольку он не означает устранение концепции «состояния», но он подразумевает изменения в том, как узлы Эфириума обрабатывают данные состояния. Само отсутствие состояния бывает двух видов: слабое отсутствие состояния и сильное отсутствие состояния. Слабое отсутствие состояния позволяет большинству узлов работать без состояния, возлагая ответственность за хранение состояния на немногих. Сильное отсутствие состояния полностью устраняет необходимость для любого узла хранить полные данные состояния. Как слабое, так и сильное отсутствие состояния предлагают обычным валидаторам следующие преимущества:
- почти мгновенная синхронизация
- возможность проверять блоки вне очереди
- узлы могут работать с очень низкими требованиями к оборудованию (например, на телефонах)
- узлы могут работать на дешевых жестких дисках, поскольку не требуется чтение/запись на диск
- совместимость с будущими обновлениями криптографии Эфириума
Слабое отсутствие состояния
Слабое отсутствие состояния действительно включает изменения в том, как узлы Эфириума проверяют изменения состояния, но оно не полностью устраняет необходимость хранения состояния на всех узлах в сети. Вместо этого слабое отсутствие состояния возлагает ответственность за хранение состояния на предлагающих блоки, в то время как все остальные узлы в сети проверяют блоки без хранения полных данных состояния.
При слабом отсутствии состояния предложение блоков требует доступа к полным данным состояния, но проверка блоков не требует данных состояния
Для того чтобы это произошло, деревья Веркла уже должны быть реализованы в клиентах Эфириума. Деревья Веркла — это заменяющая структура данных для хранения данных состояния Эфириума, которая позволяет передавать небольшие «свидетели» фиксированного размера между пирами и использовать их для проверки блоков вместо проверки блоков по локальным базам данных. Также требуется разделение предлагающего и создающего (PBS), поскольку это позволяет создателям блоков быть специализированными узлами с более мощным оборудованием, и именно им требуется доступ к полным данным состояния.
Отсутствие состояния опирается на то, что создатели блоков поддерживают копию полных данных состояния, чтобы они могли генерировать свидетелей, которые можно использовать для проверки блока. Другим узлам не нужен доступ к данным состояния, вся информация, необходимая для проверки блока, доступна в свидетеле. Это создает ситуацию, когда предложение блока обходится дорого, а проверка блока — дешево, что подразумевает, что меньше операторов будут запускать узел, предлагающий блоки. Однако децентрализация предлагающих блоки не является критичной до тех пор, пока как можно больше участников могут независимо проверять, что предложенные ими блоки действительны.
Подробнее в заметках Данкрада (opens in a new tab)Предлагающие блоки используют данные состояния для создания «свидетелей» — минимального набора данных, подтверждающего значения состояния, которые изменяются транзакциями в блоке. Другие валидаторы не хранят состояние, они хранят только корень состояния (хеш всего состояния). Они получают блок и свидетеля и используют их для обновления своего корня состояния. Это делает проверяющий узел чрезвычайно легковесным.
Слабое отсутствие состояния находится на продвинутой стадии исследования, но оно опирается на то, что разделение предлагающего и создающего (PBS) и деревья Веркла уже реализованы, чтобы небольшие свидетели могли передаваться между пирами. Это означает, что до внедрения слабого отсутствия состояния в основную сеть Ethereum, вероятно, пройдет еще несколько лет.
zkEVM для проверки на уровне 1 (l1) — это дополняющая технология, которая может еще больше улучшить проверку без состояния. Вместо того чтобы просто проверять свидетелей, валидаторы могли бы проверять доказательство с нулевым разглашением того, что весь блок был выполнен правильно, обеспечивая криптографическую уверенность без повторного выполнения транзакций.
Сильное отсутствие состояния
Сильное отсутствие состояния устраняет необходимость для любого узла хранить данные состояния. Вместо этого транзакции отправляются со свидетелями, которые могут быть агрегированы создателями блоков. Затем создатели блоков несут ответственность за хранение только того состояния, которое необходимо для генерации свидетелей для соответствующих аккаунтов. Ответственность за состояние почти полностью перекладывается на пользователей, поскольку они отправляют свидетелей и «списки доступа», чтобы объявить, с какими аккаунтами и ключами хранилища они взаимодействуют. Это позволило бы создать чрезвычайно легковесные узлы, но есть и компромиссы, включая усложнение транзакций со смарт-контрактами.
Сильное отсутствие состояния исследовалось специалистами, но в настоящее время не ожидается, что оно станет частью дорожной карты Эфириума — более вероятно, что слабого отсутствия состояния будет достаточно для потребностей масштабирования Эфириума.
Текущий прогресс
Слабое отсутствие состояния, экспирация истории и истечение срока действия состояния находятся на стадии исследования, и ожидается, что они будут выпущены через несколько лет. Нет никаких гарантий, что все эти предложения будут реализованы; например, если сначала будет реализовано истечение срока действия состояния, возможно, не будет необходимости также реализовывать экспирацию истории. Существуют также другие пункты дорожной карты, такие как деревья Веркла и разделение предлагающего и создающего (PBS), которые необходимо завершить в первую очередь.
Дополнительная литература
- Что такое Эфириум без состояния? (opens in a new tab)
- AMA с Виталиком об отсутствии состояния (opens in a new tab)
- Теория управления размером состояния (opens in a new tab)
- Ограничение состояния с минимизацией конфликтов при восстановлении (opens in a new tab)
- Пути к отсутствию состояния и истечению срока действия состояния (opens in a new tab)
- Спецификация EIP-4444 (opens in a new tab)
- Алекс Стоукс о EIP-4444 (opens in a new tab)
- Почему так важно перейти к отсутствию состояния (opens in a new tab)
- Оригинальные заметки о концепции клиента без состояния (opens in a new tab)
- Подробнее об истечении срока действия состояния (opens in a new tab)
- Еще больше об истечении срока действия состояния (opens in a new tab)
- Информационная страница об Эфириуме без состояния (opens in a new tab)
Последнее обновление страницы: 6 июня 2026 г.