Что такое исторический рост?

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

На рисунке 1 показана связь между историческим ростом, различными метриками протокола и ограничениями аппаратного обеспечения узлов Ethereum. В отличие от роста состояния, исторический рост ограничен другим набором аппаратных ограничений. Этот рост оказывает давление на сеть I/O, поскольку новые блоки и транзакции должны передаваться по сети. Он также нагружает место хранения узла, поскольку каждый узел Ethereum хранит полную копию исторической записи. Если исторический рост превышает эти аппаратные ограничения, узлы больше не смогут достичь стабильного консенсуса со своими сверстниками. Для обзора роста состояния и других узких мест в масштабировании обратитесь кЧасть 1этой серии.

Рисунок 1: узкое место расширения Ethereum

До недавнего времени большая часть пропускной способности сети каждого узла использовалась для передачи исторических записей (например, новых блоков и транзакций). Это изменилось с введением блобов в DencunХардфорк. Теперь блобы составляют значительную часть активности узла сети. Однако блобы не считаются частью исторической записи, потому что 1) узлы хранят их всего 2 недели, прежде чем избавиться от них, и 2) они не требуются для повторного воспроизведения цепочки с Генезиса. Из-за (1) блобы не значительно увеличивают нагрузку на хранение на каждом узле Ethereum. Мы обсудим блобы более подробно позже в этой статье.

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

Как быстро развивается история?

На рисунке 2 показана скорость исторического роста со времени генезиса Ethereum. Каждый вертикальный столбец представляет собой рост за один месяц. Ось Y представляет количество добавленных ГБ в историю за этот месяц. Транзакции классифицируются по их «адресу назначения», а их размер определяется с использованием ихRLPпредставление байта. Контракты, которые нельзя легко идентифицировать, классифицируются как «неизвестные». Категория «другие» включает в себя длинный хвост более мелких категорий, таких как инфраструктура и игры.

Из этой диаграммы можно сделать несколько ключевых выводов:

1. Исторический темп роста в 6-8 раз быстрее, чем темп роста государства: Исторический рост недавно достиг пика в 36,0 ГиБ/месяц и в настоящее время составляет 19,3 ГиБ/месяц. Рост государства достиг пика около 6,0 ГиБ/месяц и сейчас составляет 2,5 ГиБ/месяц. Сравнение между историческим и государственным ростом, как по темпу, так и по накопительному объему, можно найти позже в этой статье.
2. Историческая скорость роста стремительно ускорялась до Денкун: в то время как рост государства был примерно линейным на протяжении многих лет (см. Часть 1) исторический рост был сверхлинейным. Линейный рост приводит к квадратному увеличению общего размера, тогда как сверхлинейный рост приводит к увеличению быстрее квадратичного. Это ускорение внезапно остановилось после Dencun, отметив первое значительное замедление исторического роста в истории Ethereum.
3. Последний исторический рост в основном обусловлен Rollups: каждый L2 отправляет копию своих транзакций обратно на главную сеть, генерируя значительное количество исторических данных и делая rollups крупнейшим вкладчиком в исторический рост за последний год. Однако Dencun позволяет L2 использовать блобы вместо исторических записей для отправки своих данных о транзакциях, поэтому rollups больше не генерируют большую часть исторических записей Ethereum. Мы рассмотрим rollups более подробно позже в этой статье.

Какие самые большие вкладчики в историю Ethereum?

Объем исторических данных, генерируемых каждой категорией контрактов, показывает, как со временем эволюционировали шаблоны использования Ethereum. На рисунке 3 показаны относительные вклады различных категорий контрактов. Эти данные используются те же, что и на рисунке 2, нормализованные до 100%.

Данные показывают четыре различных эпохи паттернов использования Ethereum:

Первый период (фиолетовый): В начальные годы существования Ethereum активность на цепи была минимальной. Большинство из этих ранних контрактов сейчас трудно идентифицировать и обозначить как «неизвестные» на графике.

Эпоха ERC-20 (зеленая):стандарт ERC-20был завершен в конце 2015 года, но не получил значительного развития до 2017 и 2018 годов. К 2019 году контракты ERC-20 стали крупнейшей категорией в историческом росте.

Эра DEX/DeFi (Коричневый): DEX и DeFi контракты появились on-chain уже в 2016 году и начали привлекать внимание в 2017 году. Однако они не стали самой крупной исторической категорией до лета DeFi 2020Контракты DeFi и DEX достигли пика более чем на 50% исторического роста в разное время в 2021 и 2022 годах.

Эра Rollup (серая): В начале 2023 года L2 Rollups начали последовательно выполнятьбольше транзакций, чем главная сеть.Это совпало с тем, что их контракты генерировали большую часть исторических данных, составляющих около двух третей исторического роста Ethereum в месяцах, предшествующих Dencun.

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

В самых последних данных (апрель 2024 года) роллапы больше не генерируют большинство исторических записей. Неясно, будет ли будущий исторический рост доминироваться DEX и DeFi или появятся новые модели использования.

Что насчет блобов?

Введение блобов в жесткий форк Dencun значительно изменило динамику исторического роста, позволяя Rollups использовать недорогие блобы вместо исторических записей для публикации данных. Рисунок 4 увеличивает историческую скорость роста вокруг даты обновления Dencun. Этот график аналогичен Рисунку 2, но каждая вертикальная полоса представляет собой один день вместо одного месяца.

Из этой диаграммы можно сделать несколько ключевых выводов:

Исторический рост от роллапов уменьшился примерно на две трети с Dencun: Большинство роллапов перешли от использования вызова данных к блобам, что значительно сократило объем исторических данных, которые они генерируют. Однако, по состоянию на апрель 2024 года, некоторые rollupsпока не перешли от вызова данных к блобам.

Общий исторический рост уменьшился примерно на треть с момента Dencun: Dencun в основном сократил исторический рост от роллапов. Исторический рост от других категорий контрактов немного увеличился. Даже после Dencun исторический рост остается примерно в восемь раз больше, чем рост государства (подробности в следующем разделе).

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

На сколько приемлем рост в истории?

Увеличение предела газа увеличит исторический темп роста. Поэтому предложения о повышении предела газа ( например, Pump the GasНужно учитывать взаимосвязь между историческим ростом и аппаратными ограничениями на каждом узле.

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

На рисунке 5 показана нагрузка хранения узлов Ethereum со временем и также прогнозируется, как эта нагрузка может расти в ближайшие 3 года. Прогнозы делаются с использованием темпов роста с апреля 2024 года. Этот темп может увеличиваться или уменьшаться в будущем из-за изменений в шаблонах использования или газовых лимитов.

Из этой диаграммы можно сделать несколько ключевых выводов:

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

Критический порог около 1,8 TiB: Многие узлы будут вынуждены обновить свои накопители на этом этапе. Диск объемом 2 ТБ, распространенный размер, обеспечивает только 1,8 TiB полезного пространства. Обратите внимание, что TB (терабайты) и TiB (тебибайты, = 1024^4 байт) - это разные единицы измерения. Для многих операторов узлов «реальный» критический порог еще ниже, потому что валидаторы должны запускать клиент консенсуса вместе с клиентом исполнения после слияния.

Порог достигнут через 2-3 года: Любое увеличение предела газа ускорит этот график. Достижение этого порога наложит значительную нагрузку на обслуживание узловых операторов, потребуется покупка дополнительного оборудования, такого как $300 накопитель NVME.

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

Сетевой ввод-вывод как аппаратное ограничение: Помимо объема хранения, сетевой ввод-вывод является еще одним основным аппаратным ограничением для исторического роста. В отличие от объема хранения, ограничения сетевого ввода-вывода не вызовут немедленных проблем для узлов, но станут значительными при увеличении предела газа в будущем.

Для понимания того, насколько исторический рост сетевой мощности типичного узла Ethereum может поддерживать, необходимо описать взаимосвязь между историческим ростом и различными метриками сетевого здоровья, такими как скорость реорганизации, пропуски слотов, отсутствие окончательности, отсутствие аттестаций, пропуски синхронизации комитета и задержки предложения блока. Анализ этих метрик выходит за рамки этой статьи, но их можно найти в предыдущих исследованиях здоровья слоя согласования [1] [2] [3]4]. Кроме того, Фонд Ethereum @ethpandaops/xatu-overview">Проект Xatu создает общедоступные наборы данных для облегчения таких анализов.

Как решить исторический рост?

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

На рисунке 6 показано, как EIP-4444 повлияет на объем хранения каждого узла в течение следующих 3 лет. Это то же самое, что и на рисунке 4, с добавлением более тонких линий, представляющих объем хранения после внедрения EIP-4444.

Из этой диаграммы можно сделать несколько ключевых выводов:

EIP-4444 уменьшит текущее хранилище вдвое: общий объем хранилища уменьшится с 1,2 ТБ до 633 ГБ.

EIP-4444 стабилизирует историческое хранилище: при постоянной скорости исторического роста исторические данные будут удаляться с той же скоростью, с которой они генерируются.

После EIP-4444 потребуется много лет, чтобы нагрузка на хранение достигла сегодняшнего уровня: это произойдет потому, что рост состояния, который медленнее исторического роста, будет единственным фактором, увеличивающим нагрузку на хранение.

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

Как сохранить историю Ethereum?

EIP-4444 raises the question: if Ethereum nodes themselves do not preserve the history, how should it be preserved? History is crucial for Ethereum’s verification, accounting, and analysis, so it must be preserved. Fortunately, preserving history is straightforward, requiring only 1/n honest data providers, compared to the state consensus problem, which needs 1/3 to 2/3 honest participants. Node operators can verify the authenticity of any historical dataset by: 1) replaying all transactions from Genesis; and 2) checking if these transactions reproduce the same state root as the current chain tip.

Существует несколько методов сохранения истории, каждый из которых следует применять параллельно, чтобы максимизировать шансы на сохранение:

Торренты / P2P: Торрентысамый простой и надежный метод. Узлы Ethereum могут периодически упаковывать части истории и делиться ими в виде общедоступных торрент-файлов. Например, узел может создавать новый торрент-файл истории каждые 100 000 блоков. Некоторые клиенты узлов, такие как Erigon, уже выполняют этот процесс нестандартизированным образом. Чтобы стандартизировать этот процесс, все клиенты узлов должны использовать один и тот же формат данных, параметры и P2P-сеть. Узлы могут выбирать участие в этой сети на основе их объема хранения и пропускной способности. Преимущество торрентов заключается в использовании зрелых открытых стандартов, поддерживаемых обширной экосистемой инструментов для обработки данных.

Сеть Portal: Сеть порталаЭто новая сеть, специально разработанная для размещения данных Ethereum. Этот подход аналогичен торрентам, но предоставляет дополнительные функции, облегчающие проверку данных. Преимущество Portal Network в том, что эти дополнительные уровни проверки предлагают легким клиентам эффективные средства проверки и запросов для общих наборов данных.

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

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

L2 также могут использовать все эти методы для сохранения данных блоба, которые они публикуют на mainnet. Сохранение блоба представляет собой 1) более сложную задачу из-за более крупного общего объема данных; 2) менее критической, поскольку блобы не требуются для воспроизведения истории mainnet. Однако сохранение блоба необходимо для каждого L2 для воспроизведения собственной истории. Поэтому какая-то форма сохранения блоба необходима для всей экосистемы Ethereum. Более того, если L2 разработают надежную инфраструктуру хранения блобов, они также могут легко хранить исторические данные L1.

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

Рисунок 7: Объем хранения узлов Ethereum

В языке,

1. Узлы архивирования хранят данные состояния, исторические данные и архивные данные. Они используются, когда требуется легкий запрос исторического состояния цепи.
2. Полные узлы хранят только исторические данные и данные состояния. Сегодня большинство узлов являются полными узлами. Объем хранения полных узлов составляет примерно половину объема архивных узлов.
3. После EIP-4444 полные узлы будут хранить только данные состояния и исторические данные прошлого года. Это уменьшит объем хранимых данных с 1,2 TiB до 633 GiB и стабилизирует использование хранилища для исторических данных.
4. Безсостоятельные узлы, также известные как «лёгкие узлы», не хранят ни один из этих наборов данных и могут мгновенно провериться на кончике цепи. Этот тип узла становится возможным, как только Verkle пытаетсяили другие схемы обязательств государства добавляются в Ethereum.

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

EIP-7623: В этом предложении предлагается изменить цены на вызов данных, чтобы транзакции с избыточными вызовами данных стали дороже. Сделав эти шаблоны использования более затратными, можно побудить некоторых переключиться с вызова данных на блобы, тем самым снизив историческую темпы роста.

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

Эти EIP легче внедрить, чем EIP-4444, и могут служить в качестве временных мер до того, как EIP-4444 будет готов к производству.

Заключение

Цель этой статьи - предоставить понимание того, как работает исторический рост на основе данных и как решить эту проблему. Большая часть данных, представленных в этой статье, традиционно была труднодоступной, поэтому мы стремимся предложить новые идеи по проблеме исторического роста.

Исторический рост как узкое место для масштабируемости Ethereum не получил достаточного внимания. Даже без увеличения газовых лимитов текущая практика сохранения истории на Ethereum потребует, чтобы многие узлы обновили свое оборудование в течение нескольких лет. К счастью, это не особенно сложная проблема, которую можно решить. Четкие решения были изложены в EIP-4444. Мы считаем, что следует ускорить внедрение этого EIP, чтобы предоставить место для будущих увеличений газовых лимитов.

Если вас интересует исследование масштабируемости Ethereum, пожалуйста, свяжитесь storm@paradigm.xyzиgeorgios@paradigm.xyz.Мы с удовольствием выслушаем ваши точки зрения по этому вопросу и рассмотрим потенциальные сотрудничества. Данные и код, использованные в этой статье, могут быть найдено наGithub.

Благодарности

Большое спасибо Томас Тьери、Команда Beiko、Toni Wahrstaetter、Оливер НордбергиРоман Красюкдля их рассмотрения и обратной связи. Спасибо имAchal Srinivasanдля цифр, представленных на рис. 1 и рис. 7.

Отказ от ответственности:

1. Этот статья перепечатана из [Marsbit]. Все авторские права принадлежат оригинальному автору [Сторм Сливков, Георгиос Константопулос]. Если есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.