Перейти к основному содержанию

Последнее обновление страницы: 24 июля 2024 г.

Клиенты без состояния, экспирация состояний и истории

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

Сегодня высокие требования к объему жесткого диска — главный барьер на пути к повсеместному доступу к узлам. Главная причина этого — необходимость хранения больших массивов данных о состоянии Ethereum. Эти данные содержат критически важную информацию, необходимую, чтобы обрабатывать новые блоки и транзакции. На момент написания для запуска полного узла Ethereum требовался быстрый SSD объемом 2 ТБ. Для узла, который не удаляет старые данные, требования к хранилищу растут со скоростью 14 ГБ в неделю, а архивные узлы, хранящие абсолютно все записи с самого начала, занимают почти 12 ТБ (на момент написания в феврале 2023 г.).

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

Уменьшение размеров хранилища для узлов

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

  • Экспирация (истечение срока действия) истории: позволяет узлам избавляться от данных о состоянии более чем на Х блоков назад. При этом то, как клиент Ethereum обрабатывает данные о состоянии, не меняется.
  • Экспирация состояния: позволяет деактивировать данные о состоянии, которые используются редко. Неактивные данные могут игнорироваться клиентами, пока не будут восстановлены.
  • Слабое отсутствие состояния: только производители блоков нуждаются в доступе ко всем данным о состоянии, остальные узлы могут верифицировать блоки без локальной базы данных о нем.
  • Сильное отсутствие состояния: никаким узлам не требуется доступ ко всем данным о состоянии.

Экспирация данных

Экспирация истории

Под экспирацией истории понимается «обрезка» клиентами старых данных, которые им вряд ли понадобятся, так что они смогут хранить лишь небольшой объем исторических данных, отбрасывая старые данные при поступлении новых. Клиентам нужны исторические данные по двум причинам: синхронизация и обслуживание запросов данных. Изначально клиенты должны были синхронизироваться с начальным блоком, убеждаясь, что каждый последующий блок верен вплоть до самой вершины цепочки. Сегодня клиенты используют «контрольные точки слабой субъективности», чтобы упростить себе путь к вершине цепи. Это доверенные начальные точки, как бы делающие начальный блок ближе к текущим без необходимости проходить всю цепь Ethereum от начала. Это значит, что клиенты могут отбрасывать всю информацию, ведущую к самой недавней контрольной точке слабой субъективности, не теряя возможности синхронизироваться с вершиной цепочки. Сейчас клиенты выполняют запросы исторических данных (поступающие через JSON-RPC), получая их из собственных локальных баз данных. Но экспирация истории сделает это невозможным, если запрашиваемые данные окажутся обрезаны. Обработка исторических данных — это область, требующая инновационных решений.

Один из вариантов — возможность клиентов запрашивать исторические данные у одноранговых пользователей с помощью таких решений, как Portal Network. Portal Network — это одноранговая сеть, находящаяся в разработке и предназначенная для предоставления исторических данных. Каждый узел в ней хранит малую часть истории Ethereum, а вся история оказывается распределенной между участниками сети. Запросы выполняются путем поиска одноранговых пользователей, хранящих нужные данные, и обращения к ним. Поскольку приложения требуют доступа к историческим данным, в качестве альтернативы можно сделать их ответственными за хранение данных. Также в сообществе Ethereum могут найтись альтруисты, которые сами захотят обслуживать исторические архивы. Например, это может быть DAO, созданное для хранения исторических данных, или, в идеале, комбинация всех вышеизложенных вариантов. Такие поставщики могли бы предоставлять эти данные множеством способов, например через торрент, FTP, Filecoin или IPFS.

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

К запуску EIP-4444 еще не все готово, но он находится на стадии активного обсуждения. Любопытно, что вызовы, которые бросает EIP-4444, не столько технические, сколько связанные с управлением сообществом. Для запуска требуется не только поддержка сообщества, но и конкретные гарантии от доверенных лиц, касающиеся их согласия хранить и предоставлять исторические данные.

Это обновление фундаментально не меняет подход узлов Ethereum к хранению данных состояния, а лишь меняет способы доступа к историческим данным.

Экспирация состояния

Экспирация состояния — это устранение данных о состоянии из отдельных узлов, если к ним никто не обращался в последнее время. Есть несколько способов реализации, включая:

  • Экспирация по аренде: взимание «арендной платы» с акканутов и окончание их срока действия, когда арендная плата достигнет нуля.
  • Экспирация по времени: аккаунты становятся неактивными, если не было операций чтения/записи с аккаунта на протяжении определенного периода времени.

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

Чтобы это заработало, вероятно, потребуется создать дерево состояний с определенными периодами времени (возможно, около 1 года). При начале каждого нового периода создается полностью новое дерево состояний. Только текущее дерево состояний может меняться, все остальные неизменны. Ожидается, что узлы Ethereum будут хранить только текущее дерево состояния и ближайшее следующее. Для этого потребуется способ создавать метку времени в адресе, указываая период, в котором она существует. Есть несколько возможных способов(opens in a new tab) сделать это, но приоритетный требует удлинения адресов(opens in a new tab), чтобы включить в них дополнительную информацию, так как длинные адреса более безопасны. Этот пункт в дорожной карте называется расширением места для адресов(opens in a new tab).

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

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

Клиенты не использующие состояние

Клиенты без состояния — это немного неточная формулировка, потому что она не предполагает, что все «состояние» перестанет отслеживаться. Но при этом предусматривается изменение того, как узлы Ethereum обрабатывают данные о состоянии. Отсутствие состояния само по себе может быть двух видов: слабым и сильным. Слабое отсутствие состояния позволяет большинству узлов обходиться без состояния, передав ответственность за его хранение меньшинству. Сильное отсутствие состояния полностью избавляет все узлы от необходимости хранить полную версию данных о состоянии. И сильное, и слабое отсутствие состояния имеет следующие преимущества для обычных валидаторов:

  • Почти мгновенная синхронизация.
  • Возможность валидировать блоки не по порядку.
  • Очень низкие аппаратные требования для запуска узлов (например, возможность делать это на телефоне).
  • Возможность узлов работать на дешевых жестких дисках, поскольку необходимости в постоянном чтении и записи не будет.
  • Совместимость с будущими обновлениями криптографии Ethereum.

Частичное отсутствие фиксации

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

При слабом отсутствии состояния предложение новых блоков требует доступа к данным всего состояния, но верификация не требует никаких данных о состоянии.

Для этого деревья Веркла должны быть уже реализованы в клиентах Ethereum. Деревья Веркла — это изменение структуры хранения данных в Ethereum, позволяющее узлам обмениваться между собой маленькими «свидетельствами» фиксированного размера и использовать их для верификации блоков, вместо того чтобы верифицировать блоки на основе локальных баз данных. Разделение предлагающих и строителей также необходимо, поскольку это позволит строителям блоков выступать в роли специализированных узлов с более мощным оборудованием, и именно им потребуется доступ ко всем данным состояния.

Предлагающие блоки используют данные состояния для создания «свидетельств» — минимального набора данных, подтверждающего значения из состояния, изменяемого транзакциями в блоке. Другие валидаторы не хранят состояние, они хранят только его корень (хэш всего состояния). Они получают блок и свидетельство и используют их, чтобы обновить свой корень состояния. Это делает узел валидатора невероятно легковесным.

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

Полное отсутствие фиксации

При полном отсутствии фиксации узлам не нужно хранить данные о состоянии. Вместо этого транзакции отправляются со свидетельствами, которые собираются производителями блоков. Производители блоков затем отвечают за хранение только состояния, которое нужно для генерации свидетельств для соответствующих аккаунтов. Ответственность за состояние почти полностью переходит в руки пользователей, поскольку они отправляют свидетельства и «списки доступа», чтобы заявить о том, с какими аккаунтами и ключами в хранилище они взаимодействуют. Это значительно снизит размер узлов, но может усложнить выполнение транзакций с использованием смарт-контрактов.

Сильное отсутствие состояния было исследовано, но сейчас его включение в дорожную карту Ethereum не планируется — скорее всего, слабого отсутствия состояния будет достаточно для удовлетворения нужд Ethereum в масштабировании сети.

Текущий прогресс

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

Дополнительная литература

Была ли эта статья полезной?