Парадигма: Подробное объяснение исторических проблем и решений Ethereum

Оригинальное название: Как увеличить лимит газа, Часть 2: Рост истории

Оригинальные авторы: Сторм Сливкофф, Георгиос Константопулос

Оригинальный перевод: Луффи, Новости Предвидения

 

Рост истории в настоящее время является самым большим узким местом для масштабируемости 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 (https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/). Контракты, которые не могут быть легко идентифицированы, классифицируются как "неизвестные". Категория "другие" включает ряд маленьких категорий, таких как инфраструктура и игры.

Рисунок 2: Рост истории Ethereum

Исторический темп роста со временем

Несколько ключевых моментов из вышеуказанной диаграммы:

• Темп роста истории в 6-8 раз быстрее, чем темп роста государства: Темп роста истории недавно достиг пика в 36,0 ГиБ/месяц, в настоящее время составляет 19,3 ГиБ/месяц. Темп роста государства достиг пика примерно в 6,0 ГиБ/месяц, в настоящее время составляет 2,5 ГиБ/месяц. Сравнение исторического и государственного роста в терминах роста и накопительного объема будет обсуждаться позже в этой статье.
• До Dencun темп роста истории ускорялся: В то время как рост государства был примерно линейным на протяжении многих лет (см. Часть 1), история проявляла суперлинейный рост. Учитывая, что темп роста линейного роста приводит к квадратичному росту общего объема, суперлинейный темп роста приводит к превышению квадратичного роста. Это ускорение внезапно прекратилось после Dencun. Это означало значительное снижение исторического темпа роста Ethereum впервые.
• Самый последний рост истории в значительной степени обусловлен Rollup: Каждый L2 публикует копии своих транзакций обратно на главную сеть. Это генерирует значительное количество исторических записей и делает Rollup самым значительным вкладчиком в исторический рост за последний год. Однако благодаря Dencun L2 могут использовать блобы вместо исторических записей для публикации своих данных о транзакциях, что снижает генерацию большинства исторических записей Ethereum Rollup. Мы подробнее рассмотрим 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 и DEX занимали более 50% исторического роста в некоторых частях 2021 и 2022 годов.
• Эра Rollup (Серый): В начале 2023 года L2 Rollups начали выполнять больше транзакций, чем главная сеть. В месяцы, предшествующие Dencun, они генерировали около 2/3 исторических записей Ethereum.

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

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

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

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

Рисунок 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) проверив, воспроизводят ли эти транзакции тот же корневой состояние, что и текущая конечная точка блокчейна.

Существует много методов для сохранения исторических записей.

• Торренты/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.

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

Рисунок 7: Нагрузка хранения различных типов узлов Ethereum

Иными словами,

• Архивные узлы хранят как данные состояния, так и исторические данные, а также архивные данные. Когда кому-то нужно легко запросить историческое состояние цепочки, он может использовать архивный узел.
• Полные узлы хранят только исторические данные и данные состояния. Большинство узлов сегодня являются полными узлами. Нагрузка хранения полного узла примерно вдвое меньше, чем у архивного узла.
• После EIP-4444 полные узлы хранят только данные состояния и самый последний год исторических данных. Это снижает нагрузку хранения узла с 1,2 ТБ до 633 ГБ и стабилизирует пространство хранения для исторических данных.
• Бессостоятельные узлы, также известные как "легкие узлы", не хранят никаких наборов данных и могут немедленно проверить в конце цепочки. После добавления в Ethereum попыток Verkle или других схем фиксации состояния, этот тип узла становится возможным.

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

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

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

  Вывод

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

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