Оригинальный источник: Gravity

Введение

С момента запуска Gravity Alpha основной сети в августе 2024 года сеть обработала более 275 миллионов транзакций, с ежедневным объемом транзакций до 2.6 миллионов и успешно достигла 30 миллионов G в транзакционных расходах. С публикацией Litepaper мы полны ожиданий относительно будущего этой высокопроизводительной EVM цепи. Эта статья глубоко анализирует Litepaper, показывая, как Gravity строит выдающуюся архитектуру высокопроизводительного Layer-1 блокчейна для реальных приложений.

Gravity является высокопроизводительным блокчейном первого уровня, совместимым с EVM, созданным Galxe. Разработка Gravity была вызвана потребностями в развитии Galxe. Платформа Galxe, являющаяся крупнейшей платформой для распространения на блокчейне в мире, соединяет огромную многосетевую экосистему, привлекая более 25 миллионов пользователей. В процессе своего постоянного развития Galxe превратилась в децентрализованное суперприложение, интегрировав такие инновационные инструменты, как Quest, Passport, Score, Compass и Alva, а также предоставляя богатые услуги, такие как системы лояльности, события NFT, токеновые вознаграждения, zk-идентификация и кросс-цепочные умные сбережения. В процессе постоянного развития высокий объем транзакций Galxe стал важным фактором для продвижения строительства Gravity - ее система лояльности поддерживает 51.2 транзакций в секунду, а токеновые вознаграждения поддерживают 32.1 транзакций в секунду. Это побудило нас перейти на EVM блокчейн, сохраняя при этом лучший пользовательский опыт в процессе децентрализации бэкенда Galxe.

С развитием полной цепи Galxe ожидается дальнейший рост объема транзакций. Прогнозируется, что потребность в пропускной способности достигнет 50 миллионов gas в секунду, а для удовлетворения более широких экосистемных потребностей (таких как кросс-цепочные расчеты, транзакции лояльности и рынок NFT) может потребоваться мощность обработки в 500 миллионов gas в секунду. Для этого Gravity ставит цель поддерживать пропускную способность в 1 гигагаз в секунду, чтобы удовлетворить потребности в масштабировании ресурсоемких приложений.

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

В этом контексте Gravity возникла. Gravity, основанная на параллельном EVM, разработала Grevm, в настоящее время самую быструю открытую параллельную EVM систему исполнения, чтобы сократить разрыв в производительности между L2 и L1. Кроме того, Gravity модифицировала архитектуру Aptos, интегрировав проверенные компоненты, такие как Quorum Store и консенсусный движок AptosBFT. Используя зрелую архитектуру Aptos, Gravity избегает сложности и потенциальных рисков, связанных с разработкой с нуля. В конечном итоге Gravity не только построила высокопроизводительный L1 блокчейн, предлагающий полный опыт цепи, но и выпустила первый в мире SDK для конвейерного блокчейна, значительно упростив процесс взаимодействия разработчиков и пользователей.

Gravity предлагает беспрецедентную масштабируемость, децентрализованные возможности и практически мгновенную скорость транзакций. Его технологии объединяют преимущества L1 и L2, обеспечивая 10 000 транзакций в секунду и субсекундную окончательность. В то же время, интегрируя протоколы повторного стейкинга, такие как EigenLayer и Babylon, Gravity обеспечивает мощную безопасность на этапе запуска и снижает системные риски, связанные с долгосрочной зависимостью от одного актива.

В будущем Gravity будет продвигаться согласно следующему дорожной карте:

· Запуск Devnet этапа 1 для тестирования реальной производительности;

· Запуск Longevity Testnet для проверки долгосрочной стабильности сети;

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

Ниже приведен полный перевод Gravity Litepaper.

Резюме

Gravity является высокопроизводительным блокчейном первого уровня, совместимым с EVM, созданным Galxe, специально разработанным для масштабируемых приложений и многосетевой экосистемы. Его особенности включают пропускную способность в 1 гигагаз в секунду, субсекундное подтверждение транзакций и механизм консенсуса PoS, основанный на рестейкинге. Дизайн Gravity основан на двух основных открытых компонентах: (1) Gravity SDK, который является движком консенсуса PoS на основе рестейкинга с конвейерной архитектурой AptosBFT; (2) Gravity reth, уровень исполнения, управляемый параллельным EVM Grevm (Gravity EVM). Эти инструменты предоставляют возможность создавать альтернативные L1 и эффективные L2 для Web3 приложений, особенно в сценариях использования на EVM цепях. В этой статье подробно рассматриваются инженерные разработки и технологические инновации Gravity, демонстрируя, как с помощью конвейерной архитектуры, передовых алгоритмов консенсуса, технологий параллельного исполнения и оптимизированных механизмов хранения (через улучшение reth и доработку консенсусного движка Aptos) можно удовлетворить требования высокой производительности.

Введение

Разработка Gravity была вызвана вызовами, с которыми столкнулась Galxe в процессе своей деятельности. Galxe - это передовое Web3 приложение, предлагающее пользователям услуги, такие как системы лояльности, NFT мероприятий, токеновые вознаграждения, проверка идентичности с нулевым знанием и кросс-цепочные умные сбережения. С быстрым ростом Galxe ее система лояльности обрабатывает в среднем 51.2 транзакции в секунду, а акции токеновых вознаграждений - 32.1 транзакции в секунду. В процессе постепенной децентрализации Galxe, перенос этих кейсов на EVM блокчейн, при этом обеспечивая плавный пользовательский опыт, стал жизненно важной задачей. Поэтому создание высокопроизводительного EVM блокчейна, способного удовлетворить (1) высокую пропускную способность транзакций и (2) почти мгновенные подтверждения транзакций, стало критически важным.

В этом контексте выбор существующего решения второго уровня или разработка нового первого уровня является ключевым решением. Первый уровень достигает окончательности за счет алгоритма консенсуса, в то время как второй уровень решает эту проблему с помощью протоколов Rollup. Оба имеют свои компромиссы: первый уровень обычно жертвует частью пропускной способности из-за ограничений алгоритма консенсуса, но может обеспечить более быстрое окончательное подтверждение транзакций. Например, алгоритм консенсуса на основе AptosBFT может подтверждать транзакции за субсекунды, в то время как оптимистический Rollup может иметь срок ожидания до семи дней. Хотя доказательства с нулевым знанием могут ускорить этот процесс, окончательное подтверждение все равно требует нескольких часов. Учитывая потребность Gravity в субсекундном окончательном подтверждении (особенно для ее протокола полной цепи), мы выбрали построение первого уровня.

Хотя уровень 2 имеет родные преимущества в коммуникации с Ethereum, такие как Gravity, уровень 1 может достигать глубокої совместимости с Ethereum и другими блокчейнами через протокол намерений Gravity и кросс-цепочные мосты. Этот дизайн не только бесшовно сотрудничает с Ethereum, но и усиливает связность всей экосистемы Web3.

Кроме того, протоколы рестейкинга значительно снижают сложность создания PoS блокчейна первого уровня. Gravity интегрировала активы стейкинга Ethereum и Bitcoin через протоколы такие как EigenLayer и Babylon, объединяя их обширную сеть валидаторов. Это обеспечивает экономическую безопасность для консенсуса PoS, позволяя Gravity достичь уровня децентрализации и безопасности, сопоставимого с Ethereum.

В заключение, Gravity была построена как высокопроизводительный блокчейн первого уровня, совместимый с EVM, чтобы удовлетворить потребности в масштабируемости и производительности современных Web3 приложений. Хотя изначально она была разработана для обслуживания Galxe, гибкая структура, предлагаемая Gravity SDK и Grevm (Gravity EVM), подходит для создания любого первого уровня и эффективного второго уровня, аналогично Tendermint/Cosmos SDK.

Нам нужна пропускная способность в 1 гигагаз/с

Для блокчейна пропускная способность является наиболее критическим показателем производительности, обычно измеряемым в количестве транзакций в секунду (TPS) или количестве газа, используемого в секунду (gas/s). Например, система лояльности Galxe требует как минимум 4 миллиона gas/s для стабильной работы. Эта цифра основана на среднем расходе 80 000 газа на каждую транзакцию лояльности, при этом система может обрабатывать около 51.2 транзакций в секунду.

Этот прогноз подтверждается практическими данными Gravity Alpha Mainnet. В качестве нашей тестовой сети второго уровня транзакции лояльности Gravity Alpha Mainnet показывают, что ее пропускная способность может стабильно достигать 4 миллионов gas/s, что подтверждает точность вышеупомянутой оценки.

Хотя высокие затраты на операции в цепочке могут привести к небольшому снижению спроса, тенденция расширения Galxe показывает, что в пиковые часы спрос может вырасти в два-три раза по сравнению с текущим уровнем. Кроме того, с добавлением других сценариев использования, таких как NFT, токеновые вознаграждения и будущая поддержка доказательств с нулевым знанием для всех цепей, если Galxe полностью перейдет на цепь, прогнозируется, что потребность в пропускной способности достигнет 50 миллионов gas/s. Исходя из предположения, что использование газа приложениями на Gravity цепи следует распределению Парето (аналогично тому, как Uniswap постоянно использует 10% газа Ethereum), для удовлетворения более широких экосистемных потребностей, таких как кросс-цепочные расчеты, транзакции лояльности и рынок NFT, в идеале должна поддерживаться пропускная способность в 500 миллионов gas/s. Поэтому, чтобы удовлетворить эти потенциальные потребности, блокчейн должен обладать мощностью обработки в 1 гигагаз в секунду, чтобы гарантировать, что он сможет адаптироваться к потребностям масштабирования ресурсоемких приложений.

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

Субсекундное время подтверждения

Помимо пропускной способности, скорость подтверждения транзакций также имеет решающее значение для пользовательского опыта. Современные пользователи привыкли к почти мгновенному отклику, что по-прежнему является вызовом для блокчейна. Например, Galxe, который похож на полностью блокчейн-игры, имеет определенные требования к низкой задержке. В настоящее время время подтверждения транзакций на большинстве EVM блокчейнов варьируется от нескольких секунд до нескольких дней, что далеко не соответствует этому требованию. Мы выбрали алгоритм консенсуса AptosBFT для достижения субсекундного времени подтверждения.

Хотя L2 Rollup в теории может повысить пропускную способность, их период ожидания может привести к задержке транзакций, что крайне негативно сказывается на приложениях, которые требуют мгновенного подтверждения транзакций (таких как Galxe). Хотя некоторые DApp пытаются оптимизировать эту ситуацию через режим доверия или внешние мониторинги, это вводит дополнительные сложности и риски, что явно не идеально для критически важных приложений. Gravity SDK сокращает разрыв в производительности между L2 и L1 путем проектирования конвейера из пяти этапов, параллелизуя процессы консенсуса и исполнения (подробные дизайны будут рассмотрены позже).

Безопасность на основе повторного стейкинга (Restaking) PoS

Gravity SDK предлагает безопасный способ расширения Ethereum, не ограничиваясь L2 Rollup, а выбирая L1 архитектуру, защищенную повторным стейкингом, чтобы сбалансировать производительность, совместимость и безопасность. Основные модули интегрируют повторные стейкинговые протоколы, такие как EigenLayer и Babylon, обеспечивая экономическую уверенность и гарантии для построения надежного консенсусного механизма на основе доказательства доли.

С помощью стейкинговых активов в 45 миллиардов долларов и 850 000 валидаторов из Ethereum, а также 600 миллиардов долларов активов через Babylon, Gravity может с самого начала установить надежную основу безопасности, избегая распространенных проблем старта и рисков безопасности новых блокчейнов, одновременно снижая системные риски, связанные с долгосрочной зависимостью от одного актива.

Архитектура Gravity Chain

Gravity Chain состоит из двух основных компонентов: Gravity SDK и Gravity reth. Gravity SDK - это улучшенная версия блокчейн-рамки Aptos, Aptos является в настоящее время самым современным PoS блокчейном, основанным на семействе алгоритмов консенсуса HotStuff, чья конвейерная архитектура значительно повышает пропускную способность и эффективность ресурсов. Gravity reth - это уровень исполнения на основе reth, работающий в форме реактора потоков блоков (BSR), который получает предложенные блоки от уровня консенсуса. Оптимизировав reth, Gravity reth обеспечивает параллельное исполнение, пакетные асинхронные вычисления по подаче состояния и улучшение эффективности хранения. Эти два компонента тесно связаны через интерфейс консенсуса Gravity (GCEI) и адаптер reth, динамически управляемый контроллером конвейера в процессе выполнения каждого этапа.

Этот дизайн отделяет выполнение блоков от консенсуса блоков, позволяя уровню исполнения выступать в качестве потребителя предложений блоков. Мы оптимизировали reth, чтобы он идеально соответствовал процессу предложения блоков, управляемому реактором потоков блоков (BSR).

Процесс транзакций в Gravity Chain выглядит следующим образом:

1. Транзакция отправляется через интерфейс JSON RPC Gravity reth, который полностью совместим с Ethereum.

2. Затем транзакция попадает в пул памяти Gravity SDK и распространяется по сети, валидаторы обрабатывают транзакции пакетами и генерируют сертификаты Quorum Store (QS).

3. Каждый раунд лидер предлагает предложение блока, содержащее метаданные блока и отсортированные транзакции из пула памяти и QS.

4. После того, как предложение будет помечено как упорядоченное, оно поступит на уровень исполнения.

5. Уровень исполнения Grevm обрабатывает транзакции параллельно, генерируя результаты исполнения и передавая новое состояние в модуль управления состоянием.

6. Модуль состояния вычисляет корень состояния и передает его консенсусному движку для достижения консенсуса по корню состояния.

7. Как только корень состояния окончательно подтвержден, модуль хранения персистирует корень состояния и данные блока.

В следующих главах будут подробно описаны каждый компонент.

Gravity SDK: Инновационная практика открытого конвейерного блокчейна

Gravity SDK - это модульная открытая блокчейн-рамка, разработанная на основе готового к производству блокчейна Aptos. Его цель - модульная архитектура Aptos, заимствуя уже проверенные компоненты, такие как Quorum Store и консенсусный движок AptosBFT, для создания первого в мире SDK для конвейерного блокчейна.

Причины выбора Gravity SDK на базе Aptos включают:

· Топологическая техническая архитектура: Aptos является продвинутым PoS блокчейном, основанным на консенсусе HotStuff.

· Исключительное производительность: Aptos обеспечивает пропускную способность в 160 000 транзакций в секунду и время окончательного подтверждения менее 1 секунды.

· Надежность на практике: Aptos был проверен в производственной среде и показал выдающуюся стабильность и эффективность.

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

· Синергетический эффект: с постоянным развитием Aptos Gravity SDK может бесшовно интегрировать свои новые функции, такие как API случайных чисел, и одновременно поддерживать Aptos через модульную архитектуру и инновационные механизмы безопасности.

Блокчейн на базе Gravity SDK взаимодействует с конвейерным механизмом консенсуса через интерфейс консенсуса Gravity (GCEI). Хотя GCEI совместим с различными уровнями исполнения, Gravity SDK в настоящее время в основном поддерживает Gravity reth. Подробности о GCEI будут обсуждены в следующих главах.

Интерфейс консенсуса Gravity (GCEI)

Протокол GCEI (Gravity Consensus Execution Interface) является мостом связи между уровнем консенсуса и уровнем исполнения. Он регламентирует взаимодействие между двумя уровнями, обеспечивая синхронизацию процессов консенсуса и исполнения через контроллер конвейера.

Основное отличие традиционных блокчейн SDK от Gravity SDK заключается в его конвейерном механизме консенсуса. Уровень исполнения должен быть реализован в качестве реактора потоков блоков (Block Stream Reactor), что означает, что он должен иметь возможность непрерывно потреблять поток предложенных блоков, и подтверждение состояния должно осуществляться асинхронно от исполнения транзакций. Кроме того, уровень исполнения должен иметь возможность предоставлять сигнал обратной нагрузки на уровень консенсуса, чтобы динамически регулировать темп предложений блоков.

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

Протокол GCEI определяет две группы API:

· API уровня консенсуса: Эти API реализованы Gravity SDK для того, чтобы уровень исполнения мог реагировать на предложенные блоки консенсусного движка и отправлять подтверждения состояния.

· API уровня исполнения: Эти API должны быть реализованы на уровне исполнения. Консенсусный движок будет использовать эти API для проверки предложений транзакций перед тем, как представить блок.

С точки зрения жизненного цикла транзакций, протокол GCEI определяет следующее:

1. check_txn (API уровня исполнения)

· Входные данные: получение транзакции (GTxn) в качестве входных данных.

· Выходные данные: возвращает адрес отправителя транзакции, nonce и ограничение газа.

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

2. submit_txn (API уровня консенсуса)

Входные данные: получение транзакции (GTxn) с уровня исполнения.

Выходные данные: возвращает Result<(), указывая, была ли транзакция успешно добавлена в пул памяти.

Назначение: уровень исполнения может использовать этот метод для отправки транзакций в пул памяти. Консенсусный движок затем распространит эту транзакцию по сети и сформирует Quorum Store после получения группы транзакций.

3. recv_ordered_block (API уровня исполнения)

Входные данные: получение ordered_block (типа BlockBatch), содержащего отсортированные транзакции и метаданные блока.

Выходные данные: возвращает Result<(), указывая, успешно ли уровень исполнения принял и подтвердил этот блок.

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

4. update_state_commitment (API уровня консенсуса)

Входные данные: подтверждение состояния для определенного блока (StateCommitment).

Выходные данные: возвращает Result<(), указывая, было ли состояние подтверждено успешно принятым локальным консенсусным движком.

Назначение: после вычисления подтверждения состояния уровень исполнения отправляет его на уровень консенсуса для окончательной верификации, то есть для достижения легкого консенсуса 2f+1 с другими валидаторами. Если консенсус подтверждения состояния имеет слишком большой разрыв с прогрессом предложенного блока, контроллер конвейера отрегулирует темп предложения блока.

5. commit_block_hash (API уровня исполнения)

Входные данные: получение вектора block_ids, представляющего блоки, которые необходимо представить.

Выходные данные: возвращает Result<(), указывая, был ли операцией успешно выполнен.

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

Поток блокчейна

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

Каждый этап объясняется следующим образом:

· Этап 1: Распространение транзакций: на этом этапе транзакции эффективно распространяются между валидаторами, обеспечивая своевременное и надежное включение транзакций во время построения блока. Дизайн разъединяет распространение транзакций и механизм консенсуса, следуя концепции Narwhal & Tusk и Aptos, где валидаторы непрерывно делятся пакетами транзакций, используя все сетевые ресурсы для параллельной работы. Когда пакет транзакций получает 2f+1 подписей веса (формируя PoAv, то есть доказательство доступности), это гарантирует, что этот пакет транзакций хранится как минимум f+1 честными валидаторами, так что все честные валидаторы могут извлекать эти транзакции для выполнения.

· Этап 2: Сортировка метаданных блока: на этом этапе в сети устанавливается согласованный и принятый порядок транзакций и метаданных блоков. Механизм консенсуса (AptosBFT) следует двуцепочному правилу (2-chain rule) для обеспечения блоков с байесовской устойчивостью. Блоки затем будут поступать на этап исполнения, готовясь к параллельной обработке.

· Этап 3 (BSR): Параллельное исполнение транзакций: эта стадия является частью уровня исполнения, на которой транзакции выполняются параллельно. Результаты исполнения будут переданы на этап подтверждения состояния.

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

· Этап 5: Персистенция состояния: этот этап сохраняет обязательные изменения состояния в хранилище блокчейна. Окончательный корень состояния и связанные данные хранятся в Gravity Store, который использует высоко оптимизированный движок хранения, созданный для быстрого доступа и надежности. В то же время уведомляет пул памяти и Quorum Store о необходимости очистки будущих транзакций, которые больше не могут быть включены.

Модули стейкинга и рестейкинга

Создание безопасной блокчейн-системы с доказательством доли (PoS) на первом уровне является сложной задачей, особенно в условиях, когда стейкинг осуществляется только на основе определенных токенов. Этот подход может столкнуться с проблемами экономической безопасности на ранних этапах, такими как колебания цен токенов или ограниченное участие валидаторов. Для решения этой проблемы Gravity SDK предлагает гибкий модуль стейкинга и рестейкинга, предназначенный для повышения безопасности сети через местные и внешние механизмы стейкинга.

Ключевой стратегией Gravity SDK является внедрение протоколов рестейкинга, таких как EigenLayer и Babylon. Эти протоколы позволяют валидаторам повторно ставить активы из других зрелых сетей (таких как Ethereum и Bitcoin), чтобы использовать их существующую безопасность. Позволяя валидаторам закладывать активы из этих цепей, Gravity SDK может повысить экономическую безопасность сети, не полагаясь полностью на местные токены. Этот подход не только улучшает устойчивость цепи, но и способствует разнообразию экосистемы валидаторов. Дизайн модуля стейкинга сосредоточен на модульности, а его компоненты рестейкинга обладают высокой гибкостью, позволяя легко адаптироваться к новым протоколам рестейкинга по мере эволюции экосистемы блокчейна.

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

Менеджер эпох в консенсусном движке работает непосредственно с модулем стейкинга для вычисления веса следующего раунда валидаторов. Он получает значения стейкинга от уровня исполнения, гарантируя, что процесс консенсуса может точно отражать последние динамики стейкинга. В этой архитектуре кросс-цепочные активы (например, стейкинговые активы из Ethereum) должны сначала быть перенесены на уровень исполнения, прежде чем они могут использоваться для расчета общего значения стейкинга валидаторов. Реализация механизма моста осуществляется уровнем исполнения, чтобы обеспечить более гибкую обработку кросс-цепочной коммуникации. Возможные решения могут включать мосты PoS, доказательства с нулевым знанием состояния цепи и встроенную самозапускаемую кросс-цепочную передачу сообщений.

Более подробные технические детали, дизайн API и полное описание механизмов стейкинга и рестейкинга будут подробно рассмотрены в следующих документах.

Gravity Reth: уровень исполнения реактора потоков блоков EVM

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

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

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

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

Для решения этих проблем мы представили четыре ключевых оптимизации:

· Реактор потоков блоков (Block Stream Reactor, BSR): BSR предназначен для адаптации reth к процессу предложения блоков Gravity SDK. Он позволяет уровню исполнения непрерывно потреблять поток предложенных блоков, выступая в роли реактора для асинхронной обработки блоков. BSR устанавливает динамическую обратную связь с консенсусным движком, комбинируя соответствующие сигналы обратной нагрузки. Эти сигналы в реальном времени регулируют скорость предложений блоков и подачи состояния в зависимости от пропускной способности и задержки уровня исполнения. Если уровень исполнения отстает из-за сложных транзакций или ограничений ресурсов, механизм обратной нагрузки снижает скорость предложений блоков, чтобы обеспечить стабильность системы.

· Разделение подачи состояния и исполнения транзакций: вторая оптимизация включает разделение вычислений по подаче состояния и исполнения транзакций. Разделив эти процессы, мы осуществили асинхронизацию вычислений по подаче состояния, позволяя исполнению последующих блоков не ждать завершения подачи состояния текущего блока. Мы переопределили blockhash, устранив зависимость от поля stateRoot в заголовке блока, что гарантирует, что вычисление корня состояния не блокирует создание последующих блоков.

· Оптимизация уровня хранения: в конвейерной архитектуре эффективное кэширование и постоянное хранение многоверсионных значений состояния и их подачи имеют ключевое значение. Третья оптимизация сосредоточена на улучшении уровня хранения, чтобы удовлетворить эти потребности без создания узких мест. Оптимизировав механизм хранения, мы гарантируем, что данные состояния могут быть быстро записаны и извлечены с высокой конкурентоспособностью. Это включает создание многоверсионного движка хранения и поддержку асинхронного ввода-вывода от базы данных до API хранения.

· Параллельный EVM: последняя оптимизация касается параллелизации исполнения транзакций внутри EVM. Мы разработали Grevm, параллельный EVM рантайм, который значительно ускоряет обработку транзакций за счет параллельного исполнения. Grevm использует подсказки о зависимостях данных, полученные из симуляции транзакций, для оптимизации параллельного исполнения, снижая повторное исполнение транзакций и повышая пропускную способность.

Grevm (Gravity EVM) - параллельное исполнение EVM

Grevm - это открытый проект, размещенный на GitHub (если он еще не открыт, он будет открыт в будущем). Пожалуйста, смотрите его README для получения дополнительной информации.

Grevm (Gravity EVM) - это открытая параллельная EVM система исполнения, основанная на revm. Алгоритм Grevm вдохновлен BlockSTM и улучшен за счет введения графа зависимостей данных, полученных из симуляции транзакций. Этот механизм делает планирование параллельного исполнения более эффективным, минимизируя повторное исполнение транзакций.

В наших бенчмарках Grevm является самой быстрой открытой реализацией параллельного EVM на сегодняшний день. Для транзакций без конфликтов Grevm работает в 4.13 раз быстрее последовательного исполнения, достигая скорости 26.50 гигагаза в секунду. Если смоделировать I/O задержку в 100 мкс в реальном мире, его скорость составляет 50.84 раза быстрее последовательного исполнения, с пропускной способностью 6.80 гигагаза в секунду. Этот скачок в производительности обусловлен интеграцией параллельного исполнения и асинхронных операций ввода-вывода - параллелизация позволяет эффективно накладывать операции ввода-вывода, что еще больше ускоряет процесс.

Основная идея Grevm заключается в использовании зависимости данных между транзакциями, оптимизируя параллельное исполнение за счет предсказательных наборов чтения/записи транзакций. Хотя не все подсказки совершенно точны, эти предсказательные подсказки, основанные на симуляции, обычно достаточно полезны. Например, на основной сети Ethereum, согласно историческим данным о потреблении газа, около 30% транзакций являются простыми переводами эфира, еще 25%-30% - переводами токенов ERC20, которые обычно затрагивают лишь ограниченное количество аккаунтов и хранилищ. Для этих транзакций симуляционные результаты показывают последовательную точность.

Основываясь на этих инсайтах, мы разработали трехступенчатую параллельную систему исполнения для Grevm, которая является продолжением модели Block-STM, и совмещает данные о зависимостях, полученные из симуляций транзакций:

· Этап 1: Генерация подсказок и предварительная загрузка состояния - симуляция транзакций для сбора подсказок зависимостей и предварительного разогрева кэша памяти. Этот этап может быть выполнен в разные моменты времени в зависимости от конструкции блокчейна. Например, когда новая транзакция поступает в пул памяти, симуляция может сразу же запуститься, чтобы заранее подготовить подсказки зависимостей.

· Этап 2: Анализ зависимостей - преобразование собранных в симуляционной фазе подсказок зависимостей в ориентированный ациклический граф (DAG), представляющий зависимости между транзакциями. Этот DAG используется для планирования дальнейшего распорядка транзакций в параллельном исполнении.

· Этап 3: Параллельное исполнение с разрешением конфликтов - использование модифицированного алгоритма BlockSTM, основанного на зависимостях DAG для параллельного исполнения транзакций. Программа планирования больше не выбирает транзакции строго по порядковым номерам транзакций в блоке (например, 1, 2, 3, ..., n), а приоритизирует выбор транзакций на основе DAG, минимизируя конфликты и снижая необходимость повторного исполнения.

Асинхронная пакетная подача состояния

Генерация подтверждения состояния все еще остается ключевым узким местом в конвейере блокчейна, вызванным по своей природе последовательностью Меркле. Каждый подсчет поддерева должен быть завершен, прежде чем можно будет сгенерировать окончательное подтверждение состояния, что может привести к значительным задержкам. Хотя существующие решения (такие как параллелизация на уровне учетной записи reth) вводят некоторую степень параллелизма, все еще остается много места для оптимизации. В контексте реактора потоков блоков (BSR) уровня исполнения Gravity reth, консенсус по подаче состояния и исполнению транзакций разъединены, что позволяет асинхронно выполнять отложенные и пакетные вычисления по подаче состояния, не блокируя исполнение.

Чтобы решить эти проблемы, предложенная структура вводит следующие ключевые инновации:

Асинхронное пакетное вычисление хешей: используя разделение консенсуса состояния и исполнения транзакций, эта структура реализует асинхронные вычисления по обновлению состояния. Обновления корня состояния происходят пакетами (например, раз в 10 блоков), чтобы уменьшить частоту вычисления корня состояния. Этот метод пакетной обработки позволяет эффективно вычислять хеши с общими грязными узлами, минимизируя накладные расходы от частых обновлений и снижая общие затраты на вычисления. Для малых блоков пакетная обработка может значительно улучшить параллелизм; для больших блоков это может снизить общие затраты на вычисления.

Полная параллелизация: эта структура расширяет параллелизацию на все дерево состояния, а не только на отдельное дерево учетной записи. Для узлов, помеченных как «грязные», структура использует алгоритм параллельного вычисления состояния, разделяя дерево на независимые поддеревья и обрабатывая эти поддеревья параллельно. Результаты агрегируются на верхнем уровне для эффективного вычисления окончательного корня. Этот подход гарантирует, что большие блоки с множеством транзакций и изменений состояния могут в полной мере использовать многопоточность, максимизируя пропускную способность.

Альтернативный быстрый корень состояния: чтобы адаптироваться к заголовкам блоков Ethereum и инструкциям операционного кода BLOCKHASH (которые требуют доступа к состоянию корня последних 256 блоков), мы переопределили корень состояния. Вместо того, чтобы полагаться на окончательное состояние (которое недоступно во время исполнения транзакций), мы вычисляем корень состояния как хэш комбинации набора изменений блока и предыдущего корня состояния. Этот метод делает вычисление корня состояния быстрее, не дожидаясь завершения полного подтверждения состояния.

Gravity Store

Чтобы удовлетворить потребности высокопроизводительного блокчейна в управлении большими данными, Gravity Store возникла как оптимизированный многоверсионный уровень хранения. Он основан на дизайне reth, который уже снизил проблему увеличения состояния, отделив хранение состояния от хранения данных состояния, одновременно снижая затраты на чтение и запись данных. Однако уровень исполнения Gravity reth требует дальнейшей поддержки параллельной обработки и асинхронной подачи состояния, что создает дополнительные технические требования.

Чтобы преодолеть эти вызовы, Gravity Store предложила эффективную многоверсионную древовидную структуру, специально разработанную для нашего BSR (реактор потоков блоков). Эта структура позволяет управлять многоверсионными обновлениями состояния. В отличие от традиционного подхода, который немедленно обновляет хеш после изменения, Gravity Store помечает измененные узлы как «грязные», позволяя отложенно обрабатывать хеши и выполнять пакетные операции. Этот дизайн позволяет быстро создавать новые версии, эффективно запрашивать данные определенной версии и очищать старые версии ниже определенной высоты, значительно улучшая управление состоянием блокчейна.

Мы также исследуем независимую разработку хранилища данных Gravity DB, целью которого является предоставление оптимизированного уровня хранения для блокчейн-приложений и поддержка полностью асинхронных операций ввода-вывода. Дизайн этого движка вдохновлен LETUS, высокопроизводительным логически структурированным универсальным движком базы данных для блокчейнов. Наш главный разработчик Ричард является одним из основных авторов LETUS и подробно расскажет о его дизайне в предстоящей блоговой статье.

Заключение

Gravity Chain - это высокопроизводительный EVM-совместимый блокчейн первого уровня, специально разработанный для удовлетворения потребностей в масштабируемости и производительности современных web3 приложений. В сочетании с Gravity SDK, конвейерным движком консенсуса AptosBFT и уровнем исполнения Gravity reth, управляемым Grevm, Gravity обеспечивает пропускную способность в 1 гигагаз в секунду, субсекундное время подтверждения транзакций и безопасность PoS на основе механизма рестейкинга. Дизайн этих технологических компонентов создает прочную основу для создания пользовательских альтернативных L1 блокчейнов или более эффективных L2 решений для web3 приложений, особенно подходящих для оптимизации сценариев использования EVM цепей.

Эта статья является результатом подачи и не отражает мнения BlockBeats.