Парадигма: Подробное объяснение проблем роста Ethereum в исторической перспективе и способы их решения
В этой статье мы продолжим изучать проблемы масштабируемости Ethereum, обсуждаемые в части 1, смещая наше внимание с роста состояния на исторический рост. С помощью подробного набора данных наши цели состоят в том, чтобы 1) технически понять узкие места масштабируемости Ethereum и 2) способствовать обсуждениям об оптимальном решении вокруг пределов газа Ethereum.
EIP-4444 может решить проблему исторического роста Ethereum и оставить место для увеличения лимита газа.
Связанное чтение: " Парадигма: Проблемы и решения для роста состояния Ethereum "
Автор: Сторм Сливкофф, Георгиос Константопулос
Перевод: Луффи, Новости Предвидения
Исторический рост в настоящее время является самым большим узким местом для масштабируемости Ethereum. Удивительно, что исторический рост стал более серьезной проблемой, чем рост состояния. Через несколько лет исторические данные превысят объем хранения многих узлов Ethereum.
Хорошая новость:
- Исторический рост - проблема, которую легче решить, чем рост состояния.
- Решения активно разрабатываются.
- Решение исторического роста смягчит проблему роста состояния.
В этой статье мы продолжим исследовать проблемы масштабируемости Ethereum с части 1, сместив фокус с роста состояния на исторический рост. Используя подробные наборы данных, наша цель состоит в том, чтобы 1) технически понять узкие места масштабируемости Ethereum и 2) способствовать обсуждениям об оптимальном решении вокруг лимитов газа Ethereum.
Что такое исторический рост?
История - это совокупность всех блоков и транзакций, выполненных Ethereum за все время ее существования, охватывающая все данные с генезис-блока до текущего блока. Исторический рост - это накопление новых блоков и транзакций со временем.
На рисунке 1 показана связь между историческим ростом и различными протокольными метриками и ограничениями аппаратного обеспечения узлов Ethereum. По сравнению с ростом состояния, исторический рост подвержен другому набору аппаратных ограничений. Исторический рост оказывает давление на сетевой ввод-вывод, так как новые блоки и транзакции должны быть переданы по всей сети. Исторический рост также создает напряжение на место хранения узла, так как каждый узел Ethereum хранит полную копию исторических записей. Если исторический рост ускоряется за пределы этих аппаратных лимитов, узлы больше не смогут достичь стабильного консенсуса со своими пиринговыми узлами. Для обзора роста состояния и других узких мест масштабируемости обратитесь к части 1 этой серии.
Рисунок 1: Узкие места масштабируемости EthereumДо недавнего времени большая часть пропускной способности сети каждого узла использовалась для передачи исторических записей (таких как новые блоки и транзакции). Это изменилось с введением блобов в хардфорке Денкун. Блобы теперь составляют значительную часть сетевой активности узла. Однако блобы не считаются частью исторических записей, потому что 1) они хранятся узлами всего 2 недели, а затем уничтожаются, и 2) они не требуют повторения данных Ethereum с генезиса. Из-за (1) блобы не увеличивают значительно объем хранения каждого узла Ethereum. Мы обсудим блобы позже в этой статье.
В этой статье мы сосредоточимся на историческом росте и обсудим взаимосвязь между историей и состоянием. Поскольку рост состояния и исторический рост имеют некоторые общие аппаратные ограничения, они являются взаимосвязанными проблемами, и решение одной проблемы может помочь решить другую.
Насколько быстр исторический рост?
На рисунке 2 показана скорость исторического роста Ethereum с момента ее создания. Каждая вертикальная линия представляет собой месяц роста. Ось y представляет собой ежемесячный исторический рост в гигабайтах. Транзакции категоризируются по их "целевому адресу" и представлены в байтах с использованием RLP. Неидентифицируемые контракты классифицируются как "неизвестные". Категория "другие" включает ряд маленьких категорий, таких как инфраструктура и игры.
Рисунок 2: Исторический рост EthereumНесколько ключевых моментов из вышеуказанной диаграммы:
- Исторические темпы роста в 6-8 раз быстрее, чем темпы роста состояния: Исторические темпы роста недавно достигли пика в 36,0 ГиБ/месяц, в настоящее время составляют 19,3 ГиБ/месяц. Темпы роста состояния достигли пика примерно в 6,0 ГиБ/месяц, в настоящее время составляют 2,5 ГиБ/месяц. Сравнение исторического и состояния роста в терминах роста и накопительного объема будет обсуждаться позже в этой статье.
- До Dencun исторические темпы роста ускорялись: В то время как темпы роста состояния были примерно линейными на протяжении многих лет (см. Часть 1), исторический рост был сверхлинейным. Учитывая, что темпы роста линейного роста приводят к квадратичному росту общего масштаба, сверхлинейные темпы роста приводят к масштабу, превышающему квадратичный рост. Это ускорение внезапно прекратилось после Dencun. Это стало первым значительным снижением исторических темпов роста Ethereum.
- Большая часть последнего исторического роста происходит в основном из Rollup: Каждый L2 публикует копии своих транзакций обратно на главную сеть. Это генерирует значительное количество исторических записей и делает Rollup самым значительным вкладчиком в исторический рост за последний год. Однако благодаря Dencun L2 теперь могут использовать блобы вместо исторических записей для публикации своих данных о транзакциях, поэтому Rollup больше не генерирует большинство исторических записей Ethereum. Мы более подробно рассмотрим Rollup позже в этой статье.
Кто является крупнейшими участниками исторического роста Ethereum?
Количество истории, созданной различными категориями контрактов, показывает, как со временем эволюционировали паттерны использования Ethereum. Фигура 3 показывает относительные вклады различных категорий контрактов. Эти данные нормализованы по тем же данным, что и на Фигуре 2.
Фигура 3: Вклады различных категорий контрактов в исторический ростЭти данные раскрывают четыре различных периода паттернов использования Ethereum:
- Ранние дни (фиолетовый): Ethereum имел минимальную активность on-chain в свои первые годы. Многие из этих ранних контрактов сейчас трудно идентифицировать, они обозначены как "неизвестные" на диаграмме.
- Эра ERC-20 (зеленый): Стандарт ERC-20 был завершен к концу 2015 года, но значительное развитие он увидел только в 2017 и 2018 годах. Контракты ERC-20 стали крупнейшим источником исторического роста в 2019 году.
- Эра DEX/DeFi (коричневый): Контракты DEX и DeFi появились on-chain уже в 2016 году и привлекли внимание в 2017 году. Однако только летом 2020 года, став DeFi, они стали крупнейшей категорией исторического роста. Контракты DeFi и DEX составляли более 50% исторического роста в некоторых частях 2021 и 2022 годов.
- Эра Rollup (серый): В начале 2023 года L2 Rollups начали выполнять больше транзакций, чем главная сеть. В месяцы, предшествующие Dencun, они генерировали около 2/3 исторических записей Ethereum.
Каждая эра представляет более сложные паттерны использования Ethereum, чем предыдущая. Со временем сложность можно рассматривать как форму расширения Ethereum, которую нельзя измерить простыми метриками, такими как количество транзакций в секунду.
В самом последнем месяце данных (апрель 2024 года) Rollup больше не генерирует большинство исторических записей. В настоящее время неясно, будут ли будущие исторические записи поступать от DEX и DeFi или появятся новые паттерны использования.
Что такое блобы?
Хардфорк Dencun представил блобы, значительно изменяя динамику исторического роста, позволяя Rollup использовать недорогие блобы вместо исторических записей для публикации данных. Фигура 4 углубляется в влияние Dencun на темпы исторического роста до и после обновления. Диаграмма аналогична Фигуре 2, за исключением того, что каждая вертикальная линия представляет собой день, а не месяц.
Фигура 4: Влияние Dencun на исторический ростКлючевыеВыводы, сделанные по этой диаграмме:
- С момента Dencun исторический рост rollup уменьшился примерно на 2/3: Большинство rollups перешли от вызова данных к блобам, что значительно сократило объем исторических записей, которые они генерируют. Однако к апрелю 2024 года некоторые rollups еще не перешли от вызова данных к блобам.
- С момента Dencun общий исторический рост уменьшился примерно на 1/3: Dencun только снизил исторический рост rollups. Другие категории контрактов видели небольшой прирост исторического роста. Даже после Dencun исторический рост остается в 8 раз больше, чем рост состояния (подробности в следующем разделе).
Хотя блобы снизили исторические темпы роста, они остаются новой функцией Ethereum. В настоящее время неясно, на каком уровне стабилизируются темпы исторического роста с появлением блобов.
На сколько приемлемым является исторический рост?
?Увеличение лимита газа увеличит темпы исторического роста. Поэтому предложения о повышении лимита газа (например, Pump the Gas) должны учитывать взаимосвязь между историческим ростом и аппаратными узкими местами на каждом узле.
Для определения приемлемого темпа исторического роста сначала необходимо понять, насколько долго текущее аппаратное обеспечение узла может поддерживать сеть и хранение. Сетевое оборудование, вероятно, сможет бесконечно поддерживать статус-кво, потому что темпы исторического роста вряд ли вернутся к пиковым уровням до Dencun без увеличения лимита газа. Однако бремя исторического хранения будет продолжать увеличиваться со временем. По текущей стратегии хранения диск каждого узла в конечном итоге будет заполнен историческими записями, что неизбежно.
На рисунке 5 показано бремя хранения узлов Ethereum с течением времени и прогноз роста бремени хранения в течение следующих 3 лет. Прогноз основан на темпе роста в апреле 2024 года. В зависимости от изменений в будущих шаблонах использования или лимитах газа этот темп роста может увеличиться или уменьшиться.
图 5: Размер исторических записей, состояния и бремени хранения полного узлаИз этого рисунка мы можем сделать несколько ключевых выводов:
- Пространство, занимаемое историческими записями, примерно в 3 раза больше, чем у состояния. Это различие будет увеличиваться со временем, поскольку темпы исторического роста примерно в 8 раз больше, чем у состояния.
- 1,8 ТиБ - критический порог, и многим узлам придется обновить свои диски. 2 ТБ - это обычный размер диска, предоставляющий только 1,8 ТиБ доступного пространства. Обратите внимание, что ТБ (1 триллион байт) и ТиБ (= 1024^4 байт) - это разные единицы. Для многих операторов узлов "реальный" критический порог может быть даже ниже, потому что объединенные валидаторы должны запускать клиентов консенсуса вместе с клиентами исполнения.
- Критический порог будет достигнут в течение 2-3 лет. Увеличение любого количества лимита газа соответственно ускорит приближение этого времени. Достижение этого порога принесет значительную нагрузку по обслуживанию операторам узлов и потребует покупки дополнительного оборудования (например, дисков NVME за $300).
В отличие от данных состояния, исторические данные доступны только для добавления и гораздо реже запрашиваются. Теоретически исторические данные могут храниться отдельно от данных состояния на более дешевых носителях информации. Это можно достичь некоторыми клиентами, такими как Geth.
Помимо емкости хранения, еще одним основным ограничением для исторического роста является сетевой ввод-вывод. В отличие от емкости хранения, ограничения сетевого ввода-вывода не вызовут проблем для узлов в краткосрочной перспективе, но эти ограничения станут важными для будущего увеличения лимитов газа.
Для понимания того, насколько много исторического роста может поддержать типичная сетевая емкость узлов Ethereum, необходимо знать взаимосвязь между историческим ростом и различными метриками сетевого здоровья, такими как скорость реорганизации, пропуски слотов, пропуски финальности, пропуски доказательств, пропуски комитета синхронизации и блокЗадержки в представлении. Анализ этих метрик выходит за рамки данной статьи, но его можно найти в предыдущих исследованиях здоровья уровня консенсуса. Кроме того, проект Xatu Ethereum Foundation строит общедоступные наборы данных для ускорения такого анализа.
Как решить проблемы исторического роста?
Исторический рост - проблема, которую легче решить, чем рост состояния. Его можно практически полностью решить с помощью предложенного EIP-4444. Этот EIP изменяет каждый узел с хранения всей исторической информации Ethereum на хранение только одного года исторических данных. После внедрения EIP-4444 хранение данных больше не будет узким местом для масштабируемости Ethereum, и увеличение лимитов газа не будет ограничено в долгосрочной перспективе. EIP-4444 необходим для долгосрочной устойчивости сети; в противном случае темпы исторического роста быстро потребуют регулярных обновлений аппаратного обеспечения узлов сети.
На рисунке 6 показано влияние EIP-4444 на нагрузку хранения каждого узла в течение следующих 3 лет. Это аналогично рисунку 4, но с дополнительными светлыми линиями, представляющими нагрузку хранения после внедрения EIP-4444.
图 6: Влияние EIP-4444 на нагрузку хранения узла EthereumИз этого рисунка можно сделать несколько ключевых выводов:
- EIP-4444 уменьшит текущую нагрузку хранения практически вдвое. Нагрузка хранения снизится с 1,2 ТБ до 633 ГБ.
- EIP-4444 стабилизирует историческую нагрузку хранения. При постоянной скорости исторического роста исторические данные будут удаляться по мере их генерации.
- После EIP-4444 потребуется много лет, чтобы нагрузка хранения узла достигла сегодняшних уровней. Это происходит потому, что рост состояния будет единственным фактором, увеличивающим нагрузку хранения, и темп роста состояния медленнее, чем исторический рост.
После внедрения EIP-4444 исторический рост все равно будет нести определенную нагрузку хранения, так как узлы будут хранить один год исторических записей. Однако даже при глобальном масштабировании Ethereum эта нагрузка не будет сложной для решения. Как только метод хранения исторических записей будет доказан надежным, срок истечения одного года EIP-4444 может быть сокращен до нескольких месяцев, недель или даже короче.
Как хранить исторические записи Ethereum?
EIP-4444 вызывает вопрос: если исторические записи не сохраняются самими узлами Ethereum, как их следует сохранять? Исторические записи играют ключевую роль в верификации, учете и анализе Ethereum, поэтому сохранение исторических записей необходимо. К счастью, сохранение исторических записей - это простая проблема, которая требует только 1/n честных поставщиков данных. Это сильно контрастирует с проблемой консенсуса состояния, требующей, чтобы 1/3 до 2/3 участников были честными. Операторы узлов могут проверить подлинность исторических наборов данных, 1) повторив все транзакции с момента блока генезиса и 2) проверив, воспроизводят ли эти транзакции тот же корневой состояние, что и текущая конечная точка блокчейна.
Существует много методов для сохранения исторических записей.
- Torrents/P2P: Торренты - самый простой и надежный метод. Узлы Ethereum могут периодически упаковывать части исторических записей и делиться ими в виде общедоступных торрент-файлов. Например, узел может создавать новый исторический торрент-файл каждые 100 000 блоков. Клиенты узлов, такие как erigon, уже реализовали этот процесс в некоторой степени нестандартизированным образом. Для стандартизации этого процесса все клиенты узлов должны использовать одинаковый формат данных, параметры и сеть P2P. Узлы смогут выбирать, участвовать ли в этой сети, основываясь на своих возможностях хранения и пропускной способности. Преимущество торрентов заключается в высоком стандарте Линди, поддерживаемом большим количеством инструментов для работы с данными.
- Сеть Portal: Сеть Portal - новая сеть, предназначенная для размещения данных Ethereum. Это метод, аналогичный торрентам, но также предоставляющий дополнительные функции для упрощения проверки данных. Преимущество сети Portal состоит в том, что она предоставляет возможность легкой верификации данных.
Суть сети заключается в том, что эти дополнительные слои верификации предоставляют утилиты для эффективной проверки и запроса общих наборов данных.
- Облачный хостинг: Облачные службы хранения, такие как S3 от AWS или R2 от Cloudflare, предоставляют дешевый и высокопроизводительный вариант для сохранения исторических записей. Однако этот метод приносит больше юридических и операционных рисков, потому что нельзя гарантировать, что эти облачные службы всегда будут готовы и способны хостить данные криптовалют.
Оставшиеся вызовы реализации являются скорее социальными вызовами, чем техническими. Сообщество Ethereum должно скоординировать конкретные детали реализации для интеграции их непосредственно в каждый узел клиента. В частности, выполнение полной синхронизации от поставщиков исторических записей, а не от узлов Ethereum, начиная с блока генезиса, потребует изменений, которые технически не требуют жесткого форка, поэтому их можно реализовать раньше, чем следующий жесткий форк Ethereum, Pectra.
Все эти методы исторического хранения также могут использоваться L2 для хранения данных блоба, которые они выпускают на главную сеть. По сравнению с историческим хранением, хранение блоба 1) более сложное, потому что общий объем данных намного больше; 2) менее критичное, потому что блобы необходимы не для воспроизведения истории главной сети. Однако хранение блоба все еще необходимо для каждого L2 для воспроизведения своей собственной истории. Поэтому некоторая форма хранения блоба важна для всей экосистемы Ethereum. Кроме того, если L2 разработают надежную инфраструктуру хранения блобов, они также смогут легко хранить исторические данные L1.
Прямое сравнение наборов данных, хранимых различными типами узлов Ethereum до и после реализации EIP-4444, было бы полезным. На рисунке 7 показана нагрузка хранения различных типов узлов Ethereum. Данные состояния состоят из счетов и контрактов, исторические данные состоят из блоков и транзакций, а архивные данные представляют собой набор необязательных индексов данных. Байтовые счетчики в этой таблице основаны на самом последнем снимке reth, но числа для других узловых клиентов должны быть примерно эквивалентными.
图 7: Нагрузка хранения различных типов узлов EthereumИными словами,
- Архивные узлы хранят данные состояния, исторические данные и архивные данные. Архивные узлы могут использоваться, когда кто-то хочет легко запрашивать исторические состояния цепочки.
- Полные узлы хранят только исторические данные и данные состояния. Большинство узлов сегодня являются полными узлами. Нагрузка хранения полных узлов примерно вдвое меньше, чем у архивных узлов.
- После EIP-4444 полные узлы будут хранить только данные состояния и самый последний год исторических данных. Это снизит нагрузку хранения узлов с 1,2 ТБ до 633 ГБ и стабилизирует пространство хранения для исторических данных.
- Бессостоятельные узлы, также известные как "легкие узлы", не хранят никакие наборы данных и могут немедленно проверяться в конце цепочки. После добавления попыток Verkle или других схем фиксации состояния в Ethereum, такой тип узла становится возможным.
Кроме того, есть некоторые дополнительные EIP, которые могут ограничить темп исторического роста, а не только адаптироваться к текущему темпу роста. Это полезно на короткой дистанции, чтобы оставаться в пределах сетевых ограничений ввода-вывода, и на долгой дистанции, чтобы оставаться в пределах ограничений хранения. В то время как EIP-4444 все еще необходим для долгосрочной устойчивости сети, эти другие EIP помогут Ethereum масштабироваться более эффективно в будущем:
- EIP-7623: Переоценка вызова данных для увеличения стоимости транзакций с избыточными данными вызова. Увеличение стоимости этих шаблонов использования заставит некоторые из них преобразоваться из данных вызова в блоб, снижая темп роста истории.
- EIP-4488: Введение ограничений на общее количество данных вызова, которые могут быть включены в каждый блок. Это наложит более строгие ограничения на темп роста исторических записей.
Эти EIP легче реализовать, чем EIP-4444, поэтому они могут служить краткосрочными мерами до того, как EIP-4444 будет внедрен в продукцию.
Заключение.
Заключительные замечания
Цель этой статьи - понять 1) как работает исторический рост и 2) методы решения этой проблемы с помощью данных. Многие данные в этой статье сложно получить традиционными способами, поэтому мы надеемся пролить свет на проблему исторического роста, сделав эти данные общедоступными.
Исторический рост как узкое место для масштабируемости Ethereum не получил достаточного внимания. Даже без увеличения лимита Gas, текущая практика хранения исторических записей Ethereum заставит многие узлы обновить аппаратное обеспечение в течение нескольких лет. К счастью, это не непреодолимая проблема. Уже существует четкое решение в EIP-4444. Мы считаем, что внедрение этого EIP должно быть ускорено, чтобы освободить место для будущего увеличения лимита Gas.
Дисклеймер: содержание этой статьи отражает исключительно мнение автора и не представляет платформу в каком-либо качестве. Данная статья не должна являться ориентиром при принятии инвестиционных решений.
Вам также может понравиться
Обзор анализа проекта SUI chain $HIPPO, сосредоточенного на трафике Web2 Hippo
Обязательное чтение сегодня | Избранные обзоры Twitter [14 ноября]