Сети параллельного выполнения I Aptos, Sui, Linera и Fuel

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

Идея сама по себе не новая и ее реализацию можно найти в среде исполнения Sealevel от Solana.

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

Одни из известных проектов, внедряющих философию параллельного выполнения — Aptos, Sui, Linera и Fuel.

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

Платформы смарт-контрактов позволяют создавать множество децентрализованных приложений. Для работы этих приложений необходим общий вычислительный механизм.

Виртуальная машина Ethereum — наиболее распространенный механизм исполнения смарт-контрактов (СК), насчитывающий около 20 различных реализаций.

За то время, что прошло с момента ее изобретения, EVM достигла критической массы в плане поддержки разработчиками.

Помимо Ethereum и вторых слоев поверх него, другие сети, включая Polygon, BNB Chain и Avalanche C-chain, выбрали EVM в качестве механизма исполнения и сосредоточились на изменении механизма консенсуса для повышения пропускной способности сети.

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

Даже если две транзакции независимы, например, платеж от Алисы Бобу и от Кэрол Дэйву, то EVM все равно не может выполнять эти транзакции параллельно.

У данной модели есть плюсы в плане интересных юз кейсов, таких, как флэш-кредитование, но так или иначе она неэффективна и не масштабируема.

Во-первых, увеличивается время выполнения транзакций в блоке, что ограничивает время работы.

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

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

Вторая проблема последовательного выполнения заключается в неэффективности сетевых нод.

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

От этого страдает масштабируемость и происходит ненужное потребление энергии.

Фундаментальное ограничение в структуре EVM положило начало новому царству L1, ориентированному на параллельное выполнение (ПВ).

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

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

Во время высокой активности валидаторы могут задействовать больше ядер для обработки дополнительной транзакционной нагрузки.

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

Еще одно преимущество такого подхода — уменьшение времени ожидания для подтверждения транзакций.

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

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

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

Один из вариантов заключается в смене модели учета, используемой EVM, с модели "Счета" на модель "Неизрасходованные выходы транзакций" (UTXO).

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

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

В качестве примера, Cardano использует для этой цели расширенную модель UTXO, а Findora — гибридную модель UTXO, где реализуются обе модели учета и пользователи могут менять тип актива между двумя моделями.

Другой подход для ПВ не предполагает смену модели счетов и вместо этого фокусируется на улучшении архитектуры и модификации состояния сети.

Пример такого подхода — фреймворк Sealevel в Solana.

В статье рассматривается последний подход.

Параллельное выполнение работает путем выявления независимых транзакций и их одновременного выполнения.

Две транзакции будут зависимыми, если выполнение одной из них влияет на выполнение другой.

Концепция параллельного выполнения кажется простой, но дьявол как всегда в деталях.

Ключевая проблема в том, чтобы эффективно идентифицировать "независимые" транзакции.

Для классификации независимых транзакций необходимо понимать, как каждая транзакция изменяет память блокчейна или состояние цепи.

Транзакции, которые взаимодействуют с одним и тем же смарт-контрактом, например, AMM-пулом, могут одновременно изменить состояние контракта, следовательно, их нельзя выполнять одновременно.

С существующей степенью совместимости между приложениями выявление зависимости — сложная задача.

Скажем, транзакция в АММ, где происходит обмен UNI на USDC, и маршрутизатор АММ обнаруживает, что наиболее эффективным маршрутом для ее выполнения будет UNI -> ETH -> DAI -> AAVE -> USDC.

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

Этот раздел посвящен сравнению подходов, применяемых различными механизмами параллельного выполнения.

Обсуждение сосредоточено на подходах, контролирующих доступ к состоянию (памяти). Состояние блокчейна можно представить в виде оперативной памяти.

Каждый аккаунт сети, или смарт-контракт, занимает определенный диапазон областей памяти, которые он может изменять.

Зависимые транзакции — это те, которые направлены на изменение одних и тех же участков памяти в одном и том же блоке.

Несколько сетей этой категории основаны на технологии, разработанной в рамках прекратившего свое существование блокчейн-проекта Diem компании Facebook.

Команда Diem создала язык смарт-контрактов Move ради улучшения их исполнения.

Aptos, Sui и Linera — три громких проекта из этой группы.

Не считая этой группы, Fuel — еще один известный проект, ориентированный на ПВ, где используется свой собственный язык.

Подход Aptos в том, чтобы обнаруживать зависимости, будучи прозрачным для пользователя/разработчика, т.е. не требуя от транзакций явного объявления того, какую часть состояния (места в памяти) они используют.

В Aptos используется модификация программной транзакционной памяти (STM) под названием Block-STM.

В Block-STM транзакции предварительно упорядочиваются внутри блока и во время выполнения разделяются между ветвями процессора для оптимистичного выполнения.

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

После выполнения все результаты транзакций проверяются.

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

Результат стирается, и транзакция выполняется заново. Процесс повторяется до тех пор, пока не будут выполнены все транзакции в блоке.

При использовании нескольких процессорных ядер Block-STM приводит к увеличению скорости выполнения.

Увеличение скорости зависит от уровня взаимосвязи между транзакциями.

Результаты команды Aptos показывают, что использование 32 ядер приводит к 8-кратному улучшению в случае высокой взаимосвязи и 16-кратному улучшению в случае низкой взаимосвязи.

Если все транзакции в блоке взаимосвязаны, то Block-STM приводит к незначительному снижению производительности по сравнению с последовательным выполнением.

Aptos утверждает, что с помощью этого подхода можно добиться пропускной способности в 160 000 транзакций в секунду.

Другой подход ПВ — требование к транзакциям явно указывать на участки состояния сети, которые они изменяют.

Такой подход работает в настоящее время в Solana и Sui.

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

Sui Move был реализован с целью изменения модели хранения и разрешений активов по сравнению с базовым Diem Move.

Это представляет собой существенное отличие от Aptos, где используется базовый Diem Move.

Sui Move задает модель хранения состояния, благодаря которой легче идентифицировать независимые транзакции.

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

У каждого объекта свой уникальный идентификатор в среде выполнения Sui и внутренние указатели на адреса владельцев. С помощью этих двух концепций легко выявлять зависимости, проверяя, используют ли транзакции один и тот же объект.

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

Но за это приходится платить не самым высоким уровнем удобства для разработчиков.

Sui еще не запущен. Работает пока только тестовая сеть, которая была запущена совсем недавно.

Основатели Sui утверждают, что реализация параллельного выполнения наряду с использованием механизма консенсуса Narwhal & Tusk может привести к пропускной способности, превышающей 100 000 транзакций в секунду.

Если это окажется правдой, то такая пропускная способность может стать огромным шагом вперед в сравнении с текущей пропускной способностью Solana, составляющей ~2400 транзакций в секунду, и превысит пропускную способность Visa и Mastercard.

Подробностей о работе проекта не так много.

Но из заявления о финансировании известно, что он основан на протоколе FastPay, который также был разработан в Facebook.

Fastpay базируется на технологии под названием Byzantine Consistent Broadcast.

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

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

Важно отметить, что в Sui также используется подход Byzantine Consistent Broadcast для простых платежей.

Для других же транзакций используется собственный механизм консенсуса Sui, Narwhal и Tusk, позволяющий эффективно обрабатывать более сложные и зависимые транзакции, как, например, транзакции в DeFi.

То есть Fuel не поддерживает наличие консенсуса и не хранит данные блокчейна в сети Fuel.

Что касается функционального блокчейна, Fuel взаимодействует с другими сетями для обеспечения консенсуса и доступности данных, такими как Ethereum или Celestia.

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

В модели Fuel используется UTXO для создания строгих списков доступа, т.е. списков для контроля доступа к одному и тому же фрагменту состояния.

Модель основана на концепции Канонического упорядочения транзакций.

Такая схема позволяет значительно упростить обнаружение зависимостей между транзакциями.

И для реализации этой системы была создана новая виртуальная машина FuelVM и новый язык Sway.

FuelVM — это совместимая и упрощенная реализация EVM, которая может оказаться эффективной с точки зрения привлечения разработчиков в экосистему Fuel.

Кроме того, поскольку Fuel фокусируется на модульном блокчейн-стеке, исполнение смарт-контрактов в Fuel может производиться в основной сети Ethereum.

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

Для демонстрации улучшенной производительности FuelVM по сравнению с EVM команда Fuel создала AMM в стиле Uniswap под названием SwaySwap, который работает в тестовой сети.

Метода параллельного выполнения кажется логичным и простым. Но есть много проблем, которые нужно обсуждать и решать.

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

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

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

Например, событие минта NFT может привести к всплеску активности с высоким процентом зависимых транзакций.

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

Например, мы можем предположить, что большинство переводов ETH и ERC20 - это независимые переводы, т.е. исходящие и получаемые на разные адреса.

Следовательно, мы можем предположить, что ~25% простых переводов ETH и ERC20 являются зависимыми, т.е. депозитами в смарт-контракты и переводом биржами с горячих кошельков на холодные.

С другой стороны, все операции с AMM в одном пуле зависимые.

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

Анализирую ежедневные транзакции в Ethereum, мы увидим, что из ~1,2 млн. транзакций в Ethereum:

Это также означает, что самый длинный путь выполнения, т.е. последовательное выполнение зависимых транзакций, может составлять 20-30% всех транзакций.

Другими словами, при использовании того же лимита газа можно было бы добиться 3-5-кратного увеличения пропускной способности с помощью ПВ.

Некоторые эксперименты по созданию EVM с параллельным выполнением показали аналогичные оценки, где 3-5-кратное улучшение пропускной способности может быть достигнуто.

На практике же высокоэффективные сети используют гораздо более высокий лимит газа на блок и более короткое время подтверждения блока для достижения, по крайней мере, 100-кратного улучшения пропускной способности относительно Ethereum.

Рост пропускной способности требует мощных нод валидаторов для обработки этих блоков.

И это подводит нас ко второй проблеме — централизации сети.

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

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

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

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

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

В результате пользователи сети сильно зависят от специализированных провайдеров RPC нод, например, Infura, что ведет к еще большей централизации.

В этом сценарии эти организации могут координировать свои действия для цензуры транзакций, организаций или даже приложений, например, Tornado Cash, что превратит эти сети в разрешенные системы, ничем не отличающиеся от Web 2.

Сейчас требования к работе полноценной ноды в тестовой сети Sui ниже, чем к нодам тестовой сети Aptos.

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

Сторонники децентрализации предлагают решения для устранения этих ожидаемых проблем.

Решения могут включать использование легких нод, которые проверяют правильность блоков с помощью zk-доказательств или доказательств мошенничества.

Команда Fuel активно работает в этом направлении и находится в постоянным диалоге с сообществом Ethereum по поводу важности децентрализации.

У команд Aptos и Sui нет ясности относительно приоритетности внедрения этих подходов или альтернативных подходов для продвижения децентрализации.

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

Механизмы параллельного выполнения — это перспективное решение для повышения пропускной способности платформ смарт-контрактов.

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

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

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

Оригинал статьи на ENG:

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