Мы начали строить Рет в 2022 году, чтобы обеспечить устойчивость Ethereum L1 и решить масштабирование исполнения на уровне Layer 2.

Сегодня мы с удовольствием делимся путем Reth к 1 гигагазу в секунду в L2 в 2024 году и нашей долгосрочной стратегией по превышению этого показателя.

Мы приглашаем экосистему сотрудничать с нами, когда мы продвигаем границы производительности и строгую оценку в криптовалюте.

Мы уже масштабировались?

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

Как вы измеряете производительность? Что означает газ в секунду?

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

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

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

Где мы сегодня?

Газ в секунду определяется путем деления целевого использования газа на блок на время блока. Здесь мы демонстрируем текущую пропускную способность газа в секунду и задержку на различных цепях EVM L1s и L2s (не исчерпывающие):

Мы подчеркиваем газ в секунду для тщательной оценки производительности сети EVM, учитывая как вычислительные, так и хранилищеские затраты. Сети, такие как Solana, Sui или Aptos, не включены из-за их отличных моделей затрат. Мы призываем к усилиям по согласованию моделей затрат для всех блокчейн-сетей, чтобы обеспечить всестороннее и справедливое сравнение.

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

Как Рет достигнет 1 гигагаз в секунду? За этим?

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

Reth уже достигает 100-200mgas/s во время живой синхронизации (включая восстановление отправителей, выполнение транзакций и вычисление trie на каждом блоке); еще 10 раз отсюда приводит нас к нашей краткосрочной цели в 1 гигагаз/с.

По мере развития разработки Reth наш план масштабирования должен сбалансировать масштабируемость с эффективностью:

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

Оптимизации, которые мы изучаем здесь, не включают решениерост состояния, который мы исследуем отдельно.

Вот краткое изложение того, как мы намерены туда попасть:

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

Вертикальный план масштабирования Reth

Наша цель здесь - максимизировать производительность и эффективность одного сервера или ноутбука, работающего под управлением Reth.

EVM Just-In-Time & Ahead-of-Time

В блокчейн-средах, таких как Ethereum Virtual Machine (EVM), выполнение байткода происходит через интерпретатор, который последовательно обрабатывает инструкции. Этот метод вводит накладные расходы, поскольку он не выполняет нативные ассемблерные инструкции напрямую, вместо этого работает через уровень виртуальной машины (VM).

Компиляция Just-In-Time (JIT) решает эту проблему путем преобразования байт-кода в машинный код прямо перед выполнением, тем самым улучшая производительность за счет обхода интерпретационного процесса ВМ. Эта техника, которая компилирует контракты в оптимизированный машинный код заранее, хорошо зарекомендовала себя в других ВМ, таких как Java и WebAssembly.

Однако JIT может быть уязвим для зловредного кода, направленного на эксплуатацию процесса JIT, или может быть слишком медленным для запуска в реальном времени во время выполнения. Reth будет предварительной компиляции (AOT) компилировать наиболее востребованные контракты и хранить их на диске, чтобы избежать попыток злоумышленного байткода злоупотребить нашим шагом компиляции нативного кода во время выполнения в реальном времени.

Мы работали над компилятором JIT/AOT для Revm, который в настоящее время интегрируется в Reth. Мы опубликуем его в открытом доступе в ближайшие недели, как только закончим бенчмаркинг. Примерно 50% времени выполнения в среднем тратится на интерпретатор EVM, поэтому это должно обеспечить улучшение выполнения EVM примерно в 2 раза, хотя в некоторых более вычислительно интенсивных случаях это может быть еще более значительным. В ближайшие недели мы поделимся нашими бенчмарками и интеграцией нашего собственного JIT EVM в Reth.

Параллельный EVM

Концепция Параллельной Виртуальной Машины Ethereum (Parallel EVM) позволяет одновременную обработку транзакций, отличаясь от традиционной последовательной модели исполнения EVM. У нас здесь есть 2 пути вперед:

1. Историческая синхронизация: В исторической синхронизации мы можем рассчитать наилучший возможный график параллелизации, проанализировав прошлые транзакции и выявив все исторические конфликты состояний. См. наш первый опыт в этом в старой ветке на Github.
2. Синхронизация в реальном времени: для синхронизации в реальном времени мы можем использовать Блок STM-like техники для спекулятивного выполнения без какой-либо дополнительной информации, такой как списки доступа. Этот алгоритм плохо работает во время периодов интенсивной состояния, поэтому мы хотим исследовать переключение между последовательным и параллельным выполнением в зависимости от формы рабочей нагрузки, а также статическое предсказание, какие слоты хранения будут доступны для улучшения качества параллелизма. См. один PoC от команды 3-ей стороныздесь.

Исходя из нашего исторического анализа, ~80% слотов хранения Ethereum доступны независимо, что означает, что параллелизм может привести к улучшению выполнения EVM в 5 раз.

Улучшение государственного обязательства

Мы недавно писал овлияние корневого состояния на производительность и различия между моделью базы данных Reth и другими клиентами, а также почему это важно.

В модели Reth вычисление корневого состояния - это отдельный процесс от выполнения транзакцийвидеть наш код) позволяя использовать стандартные хранилища KV, которые не нужно знать ничего о трие. В настоящее время это занимает >75% времени на запечатывание блока от начала до конца, и это очень захватывающая область для оптимизации.

Мы определяем следующие 2 «легкие победы», которые могут дать нам 2-3 раза в производительности корневого состояния, без каких-либо изменений в протоколе:

1. Полностью параллельный корень состояния: Сейчас мы только повторно вычисляем дерево хранения для измененных учетных записей параллельно, но мы можем пойти дальше и также вычислить дерево учетных записей параллельно, пока задания корня хранения завершаются в фоновом режиме.
2. Корень состояния с конвейером: Предварительная выборка промежуточных узлов дерева с диска во время выполнения путем уведомления службы корня состояния о касаниях слотов хранения и учетных записях.

Преодолев это, мы видим несколько путей вперед, отклоняясь от поведения корневого состояния Ethereum L1:

1. Менее частый корень состояния: вместо вычисления корня состояния на каждом блоке вычисляйте его каждые T блоков. Это снижает общий процент времени, затраченного на корень состояния во всей системе, и может быть самым простым и эффективным решением.
2. Корень состояния в состоянии ожидания: вместо того чтобы вычислять корень состояния в том же блоке, позвольте ему отставать на несколько блоков. Это позволяет выполнению продвигаться вперед без блокировки на вычислении корня состояния.
3. Замените кодировщик RLP & Keccak256: Вместо кодирования с RLP может быть дешевле просто конкатенировать байты и использовать более быструю хэш-функцию, например, Blake3.
4. Широкое дерево: Увеличение N-арности дерева для уменьшения усиления ввода-вывода из-за логарифмической глубины дерева.

Здесь есть несколько вопросов:

1. Какие второстепенные эффекты приведут к изменениям в легких клиентах, L2s, мостах, копроцессорах и других протоколах, которые зависят от частых подтверждений учета и хранения?
2. Можем ли мы одновременно оптимизировать фиксацию состояния для доказательства SNARK и скорость нативного исполнения?
3. Какой самый широкий государственный обязательство, которое мы можем получить с использованием имеющихся у нас инструментов? Какие вторичные эффекты возникают вокруг размера свидетеля?

Горизонтальная дорожная карта масштабирования Reth

В течение 2024 года мы выполним несколько из вышеперечисленных пунктов и достигнем нашей цели в 1 гигага/сек.

Однако вертикальное масштабирование в конечном итоге сталкивается с физическими и практическими ограничениями. Ни одна отдельная машина не может справиться с вычислительными потребностями мира. Мы считаем, что здесь есть 2 пути вперед, которые позволяют нам масштабироваться, добавляя больше серверов по мере поступления большей нагрузки:

Мульти-Rоллап Рет

Сегодняшние L2 стеки требуют запуска нескольких служб для следования цепочке: L1 CL, L1 EL, функция происхождения L1 -> L2 (которая может быть объединена с L2 EL) и L2 EL. Хотя это отлично для модульности, это становится сложным, когда запускаются несколько узловых стеков. Представьте, что вам придется запустить 100 роллапов!

Мы хотим разрешить запуск rollups в том же процессе, что и Reth, и снизить операционные расходы на запуск тысяч rollups почти до нуля.

Мы уже занимаемся этим с нашим Проекты расширения выполнения ([1], [2]), больше в следующие недели здесь.

Облачный Reth

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

Мы хотим разрешить запуск облачных узлов Reth, развернутых как служба стека, которая может масштабироваться с учетом вычислительного спроса и использовать кажущееся бесконечным облачное объектное хранилище для сохранения данных. Это общая архитектура в проектах безсерверных баз данных, таких как NeonDB, CockroachDB или Amazon Aurora.

Смотриранние мыслиот нашей команды о том, какими способами мы могли бы решить эту проблему.

Перспектива

Мы намерены поэтапно внедрять этот план доработок для всех пользователей Reth. Наша миссия - дать всем доступ к 1 гигагазу/с и выше. Мы будем тестировать наши оптимизации на Reth AlphaNet, и надеемся, что люди будут создавать модифицированные высокопроизводительные узлы, используя Reth в качестве SDK.

Есть некоторые вопросы, на которые мы еще не получили ответов.

• Как Reth может помочь в улучшении производительности во всей экосистеме L2?
• Как мы должны правильно измерять худшие сценарии, когда некоторые из наших оптимизаций могут быть для среднего случая?
• Как мы управляем напряжением между L1 и L2, которые потенциально расходятся?

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

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

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