Краткое изложение

• Увеличение требований к хранению представляет существенные вызовы для узлов Ethereum.
• Некоторые клиенты начали обрезать исторические данные из-за ограничений по объему хранения, что привело к несогласованному поведению хранения среди полных узлов в сети.
• Для обеспечения согласованности у всех клиентов историческое усечение данных стандартизировано в EIP-4444 и EIP-4844
• Следовательно, восстановление последнего состояния L1 или L2 путем повторного воспроизведения исторических данных зависит от централизованных, внепротокольных служб, что способствует исследованию более децентрализованных решений, соответствующих Ethereum.
• Сеть портала Ethereum - это легкая, децентрализованная P2P-сеть для всех типов данных Ethereum, включая исторические данные. Она предназначена для устройств с ограниченными ресурсами и предоставляет сервис Ethereum JSON-RPC. Историческая сеть и сеть маяка почти готовы к использованию.
• Сеть EthStorage - это инцентивная модульная сеть хранения для BLOB-ов EIP-4844. Чтобы сохранить BLOB, пользователь вызывает контракт хранения L1 put()метод с хэшем BLOB и комиссией в ETH. Комиссия будет постепенно распределяться среди поставщиков хранилищ при предоставлении действительного доказательства хранения внелинейных BLOB-ов с течением времени. Тестовая сеть EthStorage работает на тестовой сети Ethereum Sepolia с успешным участием нескольких участников сообщества, доказывающих свое локальное хранение.
• Будущие инициативы включают развитие децентрализованной сети государства, внедрение доказательства хранения для данных переменного размера и децентрализованный доступ непосредственно из браузеров.

Признание: Большое спасибо Пайперу Мерриаму из EF, Картику Раджу из Polychain, Цяну из EthStorage за обратную связь по статье.

Фон

22 октября 2023 года известный лидер разработчиков Go-Ethereum (Geth) Петер Силажи выразил свою глубокую обеспокоенность в Twitter. Он указал на то, что в то время как клиенты Geth сохраняют всю историческую информацию, другие клиенты Ethereum, такие как Nethermind и Besu, могут быть настроены на работу без определенных исторических данных Ethereum, таких как исторические тела блоков и заголовки. Это делает всех клиентов несогласованными и несправедливыми по отношению к Geth. Это привело к ожесточенным обсуждениям и дебатам вокруг проблемы хранения Ethereum в рамках дорожной карты Ethereum.

Проблема хранения

Почему Nethermind и Besu решили прекратить хранение исторических данных? Какие проблемы лежат в основе этого решения? С моей точки зрения, есть две основные причины:

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

Первая причина связана с растущими потребностями в хранении при работе с клиентом Ethereum. Чтобы погрузиться в конкретные требования, следующая круговая диаграмма иллюстрирует распределение затрат на хранение для свежего узла Geth на блоке 18 779 761 от 13 декабря 2023 года.

Как показано на картинке:

• Общее требование к хранилищу: 925.39 ГБ
• Исторические данные (блоки/квитанции): Примерно 628,69 ГБ
• Состояние в дереве Меркля-Патрисии (MPT): Примерно 269,74 ГБ

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

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

Иллюстрация: Конфигурация Nethermined для запуска узла без исторических блоков - экономия стоимости хранения ~460 ГБ на данный момент.

Вызов хранения ожидается усилиться с предстоящим обновлением доступности данных (DA) Ethereum. путьВ направлении полного масштабирования Ethereum DA начинается с EIP-4844 в DenCun, вводя фиксированный двоичный крупный объект (BLOB), сопровождаемый независимой моделью оплаты, известной как blobGasPrice. Каждый BLOB установлен на 128KB, и EIP-4844 разрешает каждому блоку содержать до 6 BLOBs. Для повышения масштабируемости данных план включает в себя внедрение 1D кода Рида-Соломона, позволяющего в начале по 32 BLOB на блок и в конечном итоге достигающего 256 BLOB на блок при полном масштабировании.

При полной емкости данных Ethereum DA с 256 BLOB на блок прогнозируется, что за один год сеть Ethereum DA примет около 80 ТБ данных, превысив запасы хранения большинства узлов Ethereum.

Дорожная карта хранения Ethereum и последствия

Vitalik’атвито дорожной карте Ethereum, в которой Очистка в основном занимается хранением.

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

1. EIP-4444: Привязка исторических данных в клиентах выполнения: Это предложение позволяет клиенту обрезать исторические блоки, старше одного года. Предполагая средний размер блока 100K, исторические данные блоков ограничены примерно 250 ГБ (100K (3600 24 * 365) / 12, учитывая время блока = 12с).
2. EIP-4844: Транзакции Shard BLOB: EIP-4844 отбрасывает BLOB, старше 18 дней. Это более агрессивный подход по сравнению с EIP-4444, ограничивая размер исторического BLOB примерно 100 ГБ ((18360024) 128K 6 / 12, учитывая время блока = 12s).

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

Аналогичное следствие применяется ко всем L2, то есть новый узел L2 не может полностью воспроизвести последнее состояние с L2 генезиса из Ethereum, воспроизводя блоки L2 с L2 генезиса. Кроме того, поскольку узлы L1 не поддерживают состояние L2, подход "snap sync" для L2 не может вывести последнее состояние L2 из L1, нарушая важное предположение L2 об обеспечении безопасности Ethereum. Проектируемое решение будет полагаться на услуги сторонних лиц, такие как Infura / Etherscan / сами проекты L2, для хранения копии исторических данных или состояния L2, централизованных с внепротокольным косвенным стимулированием.

Основные вопросы, которые мы задаем, -

• Можем ли мы иметь лучшее децентрализованное решение, как в части хранения, так и доступа, к проблеме?
• Возможно создать решение с минимальным доверием, ориентированное на Ethereum (например, поверх контракта L1) с прямым инцентивным решением?
• Со всеми этими данными мы можем проложить путь к прямому инцентивному решению в протоколе для хранения Ethereum и доступа к ним в полностью децентрализованном режиме в дорожной карте Ethereum?

Решения

Решение 1: Сеть портала Ethereum

Сеть портала Ethereum служит в качестве легкой децентрализованной сети доступа к протоколу Ethereum. Предлагая интерфейс Ethereum JSON-RPC, такой как eth_call, eth_getBlockByNumber, он преобразует запросы JSON-RPC в запросы P2P к распределенной хэш-таблице, аналогичной сети IPFS. В отличие от IPFS, который позволяет хранить любой тип данных и подвержен спаму, сеть P2P портала исключительно размещает данные Ethereum, такие как исторические заголовки и тела. Это достигается с помощью встроенной техники верификации легкого клиента в сети портала.

Одной из значительных особенностей сети Portal является ее дизайн для легкой работы и совместимость с ресурсами ограниченных устройств. Она может работать поверх узла с несколькими мегабайтами памяти и низкой памятью, способствуя децентрализации. Даже сотовый телефон или устройство Raspberry Pi потенциально могут присоединиться к сети и способствовать доступности данных Ethereum.

Развитие сети Portal соответствует философии разнообразия клиентов Ethereum, написанных на Rust, JavaScript, Nim и Go. Сеть маяка и сеть истории готовы к использованию, в то время как сеть состояния активно развивается. Следует отметить, что сеть Portal не предоставляет прямых стимулов для хранения данных — все узлы в сети действуют альтруистически.

Иллюстрация: Запуск сети порталов (Trin) с лимитом хранения 100 МБ.

Решение 2: Сеть EthStorage

Сеть EthStorage - это децентрализованная сеть инцентивного хранения, специально разработанная для хранения BLOB-объектов EIP-4844, поддерживаемая грантом программы ESP.

• Минимальное доверие: В отличие от существующих решений, которым требуется централизованный мост данных, EthStorage полагается на консенсус Ethereum и модель доверия $1/m$ без разрешения поставщиков хранилищ EthStorage. Процедура сохранения BLOB выглядит следующим образом: пользователь подписывает транзакцию с BLOB, которая вызывает метод put(key, blob_idx) контракта хранения. Затем контракт хранения записывает хеш BLOB и уведомляет поставщиков хранилищ событием. Поставщики хранилищ, получив событие, затем загружают и сохраняют BLOB непосредственно из сети Ethereum DA, обходя проблему моста данных.
• Стоимость хранения синхронизируется с инцентивами: при вызовеput()метод, должна быть отправлена комиссия за хранение (черезmsg.value) и депонируется в контракте. Эта плата за хранение постепенно распределяется поставщикам хранения со временем при успешной отправке и верификации доказательства хранения. По сравнению с текущей моделью оплаты платы за хранение в Ethereum, которая выплачивает единовременную плату за хранение предложителю, плата за хранение со временем идет по модели дисконтированного денежного потока — предполагая, что стоимость хранения уменьшается по сравнению с ETH со временем. Этот значительный инновационный шаг, внедренный EthStorage, согласовывает плату, которую оплачивают пользователи, и вклады поставщиков хранения со временем.
• Доказательство хранения: Доказательство хранения вдохновлено выборкой доступных данных, в то время как выборка в EthStorage выполняется в отношении BLOB-ов ​​с течением времени, а не тех, которые предлагаются блоком. Чтобы эффективно проверить выборку на цепи, EthStorage широко использует смарт-контракты и последние достижения в технологиях SNARK.
• Сеть без разрешения: Любой узел в EthStorage может получать оплату в качестве поставщика хранилища, пока он хранит данные и периодически предоставляет доказательства хранения on-chain.

С точки зрения модулярности блокчейна, EthStorage функционирует как уровень 2 Ethereum, но взимает плату за хранение вместо комиссий за транзакции. Индексируя хеши BLOB on-chain, EthStorage представляет собой модульный слой хранения Ethereum с значительной масштабируемостью хранения и экономией затрат, нацеленный на увеличение в 1000 раз.

В плане развития EthStorage уже интегрирован с EIP-4844 на тестовой сети Ethereum Sepolia. Был проведен стресс-тест EthStorage и тестовой сети Ethereum Sepolia, включающий запись около сотен гигабайт BLOBs в EthStorage. Более 50 участников сообщества присоединились к сети и успешно доказали их локальные хранилища.

Основное преимущество сети EthStorage заключается в предоставлении децентрализованного, непосредственного стимула поверх Ethereum - новаторской функции, насколько наши текущие знания позволяют судить. Однако ограничение сети заключается в том, что она специально разработана для BLOB-объектов фиксированного размера.

Панель инструментов EthStorage на сети разработчиков Ethereum

Проекция будущего

Хранение Ethereum, хотя и менее освещено, имеет значительное значение в экосистеме Ethereum. Поскольку сеть Ethereum переживает быстрый рост, хранение и доступность данных Ethereum возникают как критические вызовы. Хотя сети Portal и EthStorage находятся на ранних этапах, мы предвидим несколько увлекательных направлений на долгосрочную перспективу:

• Децентрализованный доступ с низкой задержкой к состоянию Ethereum. Доступ к состоянию Ethereum децентрализованным и проверяемым способом является критической, но сложной задачей. Учитывая традиционную настройку DHT, запрос учетной записи обычно требует множества запросов внутренних узлов трие, хранящихся в разных узлах P2P. Это часто приводит к значительно длительной задержке. Ключевым является то, как использовать структуру дерева состояния для ускорения доступа, как это предусмотрено предстоящей сетью состояния сети Ethereum Portal.
• Интеграция между сетью Portal и сетью EthStorage: Сеть Portal может без проблем расширить свою поддержку для включения BLOB в сеть, шаг, который уже частично сделала команда EthStorage. Естественным шагом будет объединить эти сети, чтобы предложить децентрализованную сеть JSON-RPC, способную вызывать контракты с доступом к BLOB. Совмещая логику приложения в контрактах и масштабное хранение BLOB с помощью EthStorage, мы обеспечиваем возможность создания новых dApps на Ethereum, таких как динамические децентрализованные веб-сайты (например, децентрализованный twitter/youtube/wikipedia и т.д.).
• Децентрализованный доступ из браузеров: Подобно протоколу ipfs://, используемому для доступа к данным в сети IPFS, существует растущая потребность в протоколе доступа к Ethereum из браузеров для разблокировки огромного потенциала богатых данных Ethereum. Эти данные охватывают широкий спектр - от владения токенами и балансов до изображений NFT и динамических децентрализованных веб-сайтов, все это становится возможным благодаря возможностям смарт-контрактов и будущего хранения Ethereum. В этой области протокол web3://, как определено в ERC-4804/6860, в настоящее время активно разрабатывается для достижения этой цели.
• Расширенное доказательство хранения для данных переменного размера: Помимо фиксированных BLOB-ов, изучение продвинутого доказательства хранения становится необходимым для работы с данными переменного размера, такими как исторические блоки или даже объекты состояния. Разработка сложных алгоритмов может улучшить адаптивность решений хранения.

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

заявление:

1. Этот статья воспроизводится из [ технологический поток глубокий прилив], оригинальное название “Ethereum Storage Roadmap: Challenges and Opportunities”, авторские права принадлежат оригинальному автору [EthStorage], если у вас есть возражения против перепечатки, пожалуйста, свяжитесь Команда Gate Learn, команда обработает это как можно скорее в соответствии с соответствующими процедурами.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.

3. Другие языковые версии статьи переведены командой Gate Learn, не упомянутой в Gate, переведенная статья не может быть воспроизведена, распространена или украдена.