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

На перекрестке эволюции блокчейна, синхронная композиционность стала модным словом, потому что она кажется решением для объединения фрагментированных слоев 2-го уровня на сети Ethereum. Этот подход решает проблему ужасного пользовательского опыта и разработки, где даже простой перевод между слоями 2-го уровня может стоить доллар и занимать до 7 дней.Участие Виталикав этих дебатах подчеркивается, что универсальная синхронность не является необходимым условием для решения этих проблем. Мы согласны с тем, что эффективное выполнение перевода не обязательно должно включать в себя синхронность, и существуют реальные затраты на создание и поддержание синхронной инфраструктуры. Мы считаем, что это не двоичный выбор между всем, что синхронно или асинхронно. Оба подхода могут сосуществовать по мере необходимости, с вероятным переходом к последнему.

1. Асинхронное декомпозируемое

В стремлении к повышению производительности в технологии блокчейн параллельное выполнение отдельных умных контрактов привлекло значительное внимание. Традиционно производительность каждого умного контракта ограничивалась возможностями одной виртуальной машины (EVM), даже с появлением мультичейн или систем Layer-2. Параллельные виртуальные машины предлагают многообещающее решение, позволяя одновременно выполнять транзакции одного умного контракта, таким образом, используя больше ядер CPU для улучшения производительности.

Parallel Relay-Execution Distributed Architecture (PREDA) — это распределенная, функциональная, ориентированная на область действия и высокоуровневая модель программирования, предназначенная для по своей сути распараллеленных общих смарт-контрактов в распределенных блокчейн-системах с несколькими EVM. С системной точки зрения PREDA делает параллельные EVM декомпонуемыми и асинхронными, обеспечивая полную распараллеливаемость контрактной функции и максимизируя параллелизм набора транзакций. Это гарантирует, что все экземпляры EVM могут быть максимально использованы, достигая оптимальной производительности и масштабируемости.

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

Tx1= Транзакция 1

Tx2= Транзакция 2

Мы предполагаем,

Исполнение Tx1 требует изменения состояния A, состояния B, состояния C

Выполнение Tx2 требует изменения состояния А, состояния D, состояния E

Современные методы параллелизации для EVMs¹, такие как те, которые реализованы Sei, Aptos и Sui, пытаются выполнять все шаги в каждой транзакции синхронно. Представьте себе увеличение одной сцены транзакции, в этих системах транзакция выполняется в пределах одной высоты блока, независимо от характера разбросанных зависимостей данных (т.е. доступа к различным частям состояния контракта). В результате, если любой шаг доступных состояний контракта совместно используется или обновляется между двумя транзакциями, они идентифицируются как конфликты чтения-записи или записи-записи и не могут выполняться параллельно, что затрудняет общую пропускную способность и масштабируемость системы. Эта ситуация значительно ухудшается, когда активность внутри блокчейна внезапно возрастает.

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

2. Оценка производительности

Исторические транзакции передачи токенов ETH воспроизводятся для оценки Sei (V2), Aptos, Sui и PREDA по пропускной способности и масштабируемости. Обратите внимание, что наша оценка использует реальные исторические транзакции передачи токенов ETH вместо создания набора транзакций между случайными парами адресов. Случайные транзакции приведут к экспериментальному результату, слишком сильно превышающему производительность в реальных случаях, поскольку реальные транзакции включают адреса, которые каким-то образом связаны друг с другом, что вносит множество зависимостей данных.

Экспериментальные настройки следующие:

Сравнение на рисунке 1 подчеркивает необходимость принятия программной модели PREDA для достижения значительного увеличения пропускной способности. PREDA демонстрирует 3,3-28,2 раза более высокий TPS, чем Aptos для реальных исторических транзакций на сети Ethereum.

Поскольку эти системы реализованы на разных языках (включая Go, Rust и C ++) и разных виртуальных машинах, мы оцениваем масштабируемость разных систем на основе относительного ускорения по сравнению с базовым использованием одного EVM, чтобы исключить влияние различных реализаций системы.

Рисунок 1. Абсолютные значения пропускной способности в ТПС эквивалентного токен-трансферного смарт-контракта, выполненного на Sei, Aptos, Sui и PREDA

Рисунок 2. Относительное увеличение скорости для Aptos, Sui, Sei и PREDA по сравнению с их собственными базовыми значениями

3. Модель программирования

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

• Оптимистическая параллелизация, включая Aptos, Sei (V2) и Monad, игнорирует зависимости состояния между транзакциями, одновременно выполняет и проверяет транзакции и откатывает транзакцию для повторного выполнения в случае конфликта.
• Пессимистичное распараллеливание, включая Solana (Sealevel), Sui и Sei (V1), предварительно проверяет зависимости состояния для каждой транзакции перед выполнением, анализирует их зависимости состояния и одновременно выполняет только эти транзакции без конфликтов.

Оба метода следуют архитектуре Shared-everything и рассматривают транзакцию как целое в контроле параллелизма; все шаги (например, доступ к различным состояниям контракта) недекомпозируемы и должны выполняться синхронно. Модель PREDA предлагает @devteam_48518/crystality-the-parallel-evm-model-implementing-shared-nothing-architecture-8d82fc0a836a">Архитектура Shared-nothing для разрыва зависимостей состояния и гарантии того, что разные экземпляры EVM никогда не будут обращаться к одной и той же части состояния контракта, полностью избегая конфликтов записи.

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

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

На каждом EVM пользовательские и ретрансляционные транзакции упорядочиваются и выполняются последовательно, в то время как транзакции на различных EVM выполняются параллельно, поскольку между EVM нет зависимостей данных. Этот механизм избегает повторного выполнения, связанного с конфликтами, в методах оптимистичной параллелизации, и необходимости анализа зависимостей состояния во время выполнения и накладных расходов на блокировку/разблокировку в методах пессимистичной параллелизации. Таким образом, PREDA обеспечивает параллельную и shared-nothing архитектуру для блокчейн-систем, отличающуюся от последовательной и shared-everything архитектуры как в Solidity, так и в Move, что может вызвать значительные накладные расходы на управление параллельностью.

4. Язык

Мы реализовали модель программирования PREDA как язык, аналогичный C/C++ и Javascript. Ниже приведена упрощенная функция передачи токенов как на языке Solidity, так и на языке PREDA.

Код на Solidity на рис. (а) содержит состояние контракта (balances), представляющее балансы адресов, и функцию transfer для перевода указанного количества токенов от отправителя транзакции (msg.sender) к получателю (payee).

В реализации PREDA, показанной на рисунке (б), ключевое слово @addressопределяет программируемые области контрактов, где состояния контрактов, принадлежащие переменной контракта (баланс), разделены по адресу и рассеяны и управляются EVM. Ключевое слово relay идентифицирует асинхронный функциональный ретранслятор.

В реализации PREDA есть три части. В части (1) ключевое слово @addressопределяет балансы пользователей, предоставляя детальное, раздельное описание состояния. Переменная области адреса баланса имеет уникальный экземпляр для каждого адреса пользователя. Экземпляры разных пользовательских адресов доступны и поддерживаются разными неперекрывающимися EVM. Функция перевода определена в той же области адреса в части (2), вызывается путем предоставления адреса плательщика в качестве целевой области при инициализации перевода транзакции пользователем. В части (3) для продолжения депозита получателю после успешного вывода инициируется реле с адресом получателя в качестве целевой области, добавляются средства на баланс получателя и выполняются EVM, которые хранят экземпляр баланса адреса получателя.

Порядок выполнения транзакции передачи токена в PREDA

На приведенной выше схеме показана последовательность выполнения транзакции передачи токенов в параллельной системе EVM PREDA. Боб инициирует транзакцию для вызова функции передачи, которая будет направлена в EVM, который удерживает баланс Боба, и вывод выполняется там. После этого выполняется ретрансляционная транзакция и направляется в EVM, который удерживает баланс Алисы, и депозит выполняется. Параллелизация происходит двумя способами:

1. Между транзакциями, инициированными пользователем: поскольку состояния, разделенные по адресу, не пересекаются, транзакции, инициированные пользователем, могут выполняться параллельно, без конфликтов. Например, в контракте на передачу токенов, который обновляет состояние плательщика для каждого адреса, различные транзакции, инициированные пользователем, могут параллельно выполняться на разных виртуальных машинах Ethereum.
2. С ретрансляционными операциями: в сценарии, когда Боб переводит токены Алисе и Кэрол, ретрансляционная транзакция для депозита на счет Алисы (от перевода от Боба к Алисе) может быть выполнена параллельно с пользовательской транзакцией для вывода средств от Боба (в переводе от Боба к Кэрол) и депозита на счет Кэрол. Только с разложимостью модели PREDA может быть выявлена встроенная параллелизация в смарт-контракте для базовой системы блокчейн, что позволяет обрабатывать пользовательские и ретрансляционные транзакции в конвейерном режиме, облегчая параллельное выполнение.

Следующее и за пределами

PREDA marks a major advancement in blockchain performance and, more importantly, scalability. By implementing asynchronous decomposability, it enables efficient transaction processing without the bottlenecks of conventional synchronous parallelization models. This approach decomposes transactions into micro-transactions according to data dependencies, allowing concurrent state changes and avoiding write conflicts completely.

Обобщенность PREDA выходит за рамки использования@addressразделить состояния контракта по адресу. Это позволяет настраивать типы разделения с помощью ключевых слов, таких как@type, где тип может быть любым элементарным именем типа Solidity, таким как @uint. Кроме того, PREDA поддерживает неподеленные состояния контрактов с @global, обеспечивая, чтобы каждый EVM поддерживал согласованные значения для таких состояний. Эта гибкость в разделении состояний улучшает адаптивность и эффективность модели в разнообразных умных контрактах.

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

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

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