Содержание
Говоря про эволюцию блокчейн-технологий, нельзя не отметить явный тренд запуска новых сетей первого уровня, ориентированных на параллельное выполнение.
Идея сама по себе не новая и ее реализацию можно найти в среде исполнения Sealevel от Solana.
Но прошедший бычий рынок, где впечатляющий рост показывали DeFi и NFT, продемонстрировал, что налицо острая необходимость в совершенствовании.
Одни из известных проектов, внедряющих философию параллельного выполнения — Aptos, Sui, Linera и Fuel.
Эта статья посвящена сходствам и различиям между этими проектами, а также проблемам, с которыми они сталкиваются.
Проблема
Платформы смарт-контрактов позволяют создавать множество децентрализованных приложений. Для работы этих приложений необходим общий вычислительный механизм.
Вычислительный механизм запускается на каждой ноде в сети, что позволяет выполнять приложения и взаимодействие пользователей с приложением.
Как только ноды получают одинаковый результат, они достигают консенсуса и двигаются дальше в цепи.
Виртуальная машина Ethereum — наиболее распространенный механизм исполнения смарт-контрактов (СК), насчитывающий около 20 различных реализаций.
The EVM has won.
It's the dominant smart contract execution architecture, and Solidity is the dominant smart contracting language.
But how will Solidity devs choose between the 20+ major EVM implementations that are out there?
За то время, что прошло с момента ее изобретения, EVM достигла критической массы в плане поддержки разработчиками.
Помимо Ethereum и вторых слоев поверх него, другие сети, включая Polygon, BNB Chain и Avalanche C-chain, выбрали EVM в качестве механизма исполнения и сосредоточились на изменении механизма консенсуса для повышения пропускной способности сети.
Основная характеристика, ограничивающая возможности EVM, — это последовательное выполнение транзакций.
По сути, EVM выполняет одну транзакцию за раз, откладывая все остальные до завершения выполнения первой и обновления состояния блокчейна.
Даже если две транзакции независимы, например, платеж от Алисы Бобу и от Кэрол Дэйву, то EVM все равно не может выполнять эти транзакции параллельно.
У данной модели есть плюсы в плане интересных юз кейсов, таких, как флэш-кредитование, но так или иначе она неэффективна и не масштабируема.
Последовательное выполнение транзакций — одно из основных проблемных мест в области пропускной способности сети.
Во-первых, увеличивается время выполнения транзакций в блоке, что ограничивает время работы.
Более того, чтобы ноды справились и подтвердили блок, количество транзакций тоже ограничивается.
Средняя пропускная способность Ethereum составляет ~17 транзакций в секунду.
Столь низкая пропускная способность означает, что в периоды высокой активности, например, во время минта NFT, сетевые майнеры/валидаторы не успевают обрабатывать все транзакции, и начинается война за приоритетное выполнение транзакций, что далее ведет к повышению стоимости комиссий в сети.
Средняя комиссия Ethereum в определенные моменты превышала 0,2 ETH (~ $800), что было не по карману многим пользователям.
Вторая проблема последовательного выполнения заключается в неэффективности сетевых нод.
Использование нескольких ядер процессора не дает никаких преимуществ при последовательном выполнении, что означает низкий уровень использования оборудования и его неэффективность.
От этого страдает масштабируемость и происходит ненужное потребление энергии.
Параллельное выполнение в помощь?
Фундаментальное ограничение в структуре EVM положило начало новому царству L1, ориентированному на параллельное выполнение (ПВ).
Параллелизм позволяет разделить обработку транзакций между несколькими ядрами процессора, повышая эффективность использования оборудования, что обеспечивает лучшую масштабируемость.
В высокопроизводительных сетях увеличение ресурса оборудования напрямую связано с количеством транзакций, которые могут быть выполнены.
Во время высокой активности валидаторы могут задействовать больше ядер для обработки дополнительной транзакционной нагрузки.
За счет динамического масштабирования вычислительных ресурсов сеть достигает повышенной пропускной способности в периоды высокого спроса, что значительно улучшает качество обслуживания пользователей.
Еще одно преимущество такого подхода — уменьшение времени ожидания для подтверждения транзакций.
Динамическое масштабирование ресурсов нод позволяет подтверждать транзакции с низкой задержкой при любой возможной нагрузке на сеть.
Не нужно ждать десятки или сотни блоков, не нужно переплачивать за приоритетное подтверждение.
Уменьшение времени подтверждения улучшает финализацию транзакций и открывает двери для блокчейнов с низкой задержкой.
Гарантия низкой задержки при выполнении транзакций способствует появлению целого ряда вариантов использования, которые ранее были невозможны.
Идея изменить модель исполнения в сети, чтобы реализовать параллелизацию, не нова, и несколько проектов уже занимались ее изучением.
Один из вариантов заключается в смене модели учета, используемой EVM, с модели "Счета" на модель "Неизрасходованные выходы транзакций" (UTXO).
Модель исполнения UTXO применяется в сети Биткоин, и позволяет выполнять параллельную обработку транзакций, что делает ее идеальной для платежей.
Ввиду ограниченной функциональности UXTO требуются расширения для обеспечения сложных взаимодействий, характерных для смарт-контрактов.
В качестве примера, Cardano использует для этой цели расширенную модель UTXO, а Findora — гибридную модель UTXO, где реализуются обе модели учета и пользователи могут менять тип актива между двумя моделями.
Другой подход для ПВ не предполагает смену модели счетов и вместо этого фокусируется на улучшении архитектуры и модификации состояния сети.
Пример такого подхода — фреймворк Sealevel в Solana.
В статье рассматривается последний подход.
Как работает параллельное выполнение?
Параллельное выполнение работает путем выявления независимых транзакций и их одновременного выполнения.
Две транзакции будут зависимыми, если выполнение одной из них влияет на выполнение другой.
Например, транзакции AMM в одном пуле будут зависимыми и должны выполняться последовательно.
Концепция параллельного выполнения кажется простой, но дьявол как всегда в деталях.
Ключевая проблема в том, чтобы эффективно идентифицировать "независимые" транзакции.
Для классификации независимых транзакций необходимо понимать, как каждая транзакция изменяет память блокчейна или состояние цепи.
Транзакции, которые взаимодействуют с одним и тем же смарт-контрактом, например, AMM-пулом, могут одновременно изменить состояние контракта, следовательно, их нельзя выполнять одновременно.
С существующей степенью совместимости между приложениями выявление зависимости — сложная задача.
Скажем, транзакция в АММ, где происходит обмен UNI на USDC, и маршрутизатор АММ обнаруживает, что наиболее эффективным маршрутом для ее выполнения будет UNI -> ETH -> DAI -> AAVE -> USDC.
Все участвующие в этой транзакции пулы не могут обрабатывать другие, пока транзакция не будет полностью выполнена и состояние всех участвующих пулов не обновится.
Идентификация независимых транзакций
Этот раздел посвящен сравнению подходов, применяемых различными механизмами параллельного выполнения.
Обсуждение сосредоточено на подходах, контролирующих доступ к состоянию (памяти). Состояние блокчейна можно представить в виде оперативной памяти.
Каждый аккаунт сети, или смарт-контракт, занимает определенный диапазон областей памяти, которые он может изменять.
Зависимые транзакции — это те, которые направлены на изменение одних и тех же участков памяти в одном и том же блоке.
В разных сетях используются разные архитектуры памяти и разные механизмы распознавания зависимых транзакций.
Несколько сетей этой категории основаны на технологии, разработанной в рамках прекратившего свое существование блокчейн-проекта Diem компании Facebook.
Команда Diem создала язык смарт-контрактов Move ради улучшения их исполнения.
Aptos, Sui и Linera — три громких проекта из этой группы.
Не считая этой группы, Fuel — еще один известный проект, ориентированный на ПВ, где используется свой собственный язык.
Aptos
Aptos строится на базе языка Move и MoveVM от Diem для создания высокопроизводительной сети с параллельным выполнением.
Подход Aptos в том, чтобы обнаруживать зависимости, будучи прозрачным для пользователя/разработчика, т.е. не требуя от транзакций явного объявления того, какую часть состояния (места в памяти) они используют.
В Aptos используется модификация программной транзакционной памяти (STM) под названием Block-STM.
В Block-STM транзакции предварительно упорядочиваются внутри блока и во время выполнения разделяются между ветвями процессора для оптимистичного выполнения.
Оптимистичное выполнение предполагает, что транзакции выполняются без зависимостей. Участки памяти, которые были изменены транзакциями, записываются.
После выполнения все результаты транзакций проверяются.
Если во время проверки обнаруживается, что транзакция обратилась к участкам памяти, которые были изменены предыдущими транзакциями, эта транзакция аннулируется.
Результат стирается, и транзакция выполняется заново. Процесс повторяется до тех пор, пока не будут выполнены все транзакции в блоке.
При использовании нескольких процессорных ядер Block-STM приводит к увеличению скорости выполнения.
Увеличение скорости зависит от уровня взаимосвязи между транзакциями.
Результаты команды Aptos показывают, что использование 32 ядер приводит к 8-кратному улучшению в случае высокой взаимосвязи и 16-кратному улучшению в случае низкой взаимосвязи.
Если все транзакции в блоке взаимосвязаны, то Block-STM приводит к незначительному снижению производительности по сравнению с последовательным выполнением.
Aptos утверждает, что с помощью этого подхода можно добиться пропускной способности в 160 000 транзакций в секунду.
Sui
Другой подход ПВ — требование к транзакциям явно указывать на участки состояния сети, которые они изменяют.
Такой подход работает в настоящее время в Solana и Sui.
В Solana единицы памяти называются аккаунтами, и транзакция должна указать, какие аккаунты она изменяет. Sui использует аналогичный подход.
Sui также опирается на технологию Diem, используя MoveVM, с тем отличием, что в Sui используется другая версия языка Move.
Sui Move был реализован с целью изменения модели хранения и разрешений активов по сравнению с базовым Diem Move.
Это представляет собой существенное отличие от Aptos, где используется базовый Diem Move.
Sui Move задает модель хранения состояния, благодаря которой легче идентифицировать независимые транзакции.
В Sui модель хранения состояния обозначается как Объекты. Чаще всего Объекты представляют собой активы и могут быть совместными, что означает, что несколько пользователей могут изменять объект.
У каждого объекта свой уникальный идентификатор в среде выполнения Sui и внутренние указатели на адреса владельцев. С помощью этих двух концепций легко выявлять зависимости, проверяя, используют ли транзакции один и тот же объект.
Перекладывая на разработчиков работу по объявлению зависимостей, упрощается реализация механизма исполнения, что в теории означает, что производительность и масштабируемость могут быть выше.
Но за это приходится платить не самым высоким уровнем удобства для разработчиков.
Sui еще не запущен. Работает пока только тестовая сеть, которая была запущена совсем недавно.
Основатели Sui утверждают, что реализация параллельного выполнения наряду с использованием механизма консенсуса Narwhal & Tusk может привести к пропускной способности, превышающей 100 000 транзакций в секунду.
Если это окажется правдой, то такая пропускная способность может стать огромным шагом вперед в сравнении с текущей пропускной способностью Solana, составляющей ~2400 транзакций в секунду, и превысит пропускную способность Visa и Mastercard.
Linera
Linera — новенький в классе параллельных вычислений, который может похвастаться первым раундом финансирования под руководством a16z.
Подробностей о работе проекта не так много.
Но из заявления о финансировании известно, что он основан на протоколе FastPay, который также был разработан в Facebook.
Fastpay базируется на технологии под названием Byzantine Consistent Broadcast.
Данная технология направлена на ускорение независимых платежей, схожих с теми, что происходят в сетях точек продаж. Она позволяет группе валидаторов гарантировать добросовестность платежей при условии, что более двух третей из них честны.
Fastpay — это разновидность систем валовых расчетов в режиме реального времени (RTGS), которые применяются в сетях среди банков и финансовых учреждений.
На основе FastPay компания Linera планирует создать блокчейн, в котором основное внимание будет уделено быстрому расчету и низкой задержке за счет параллельного выполнения платежных транзакций.
Важно отметить, что в Sui также используется подход Byzantine Consistent Broadcast для простых платежей.
Для других же транзакций используется собственный механизм консенсуса Sui, Narwhal и Tusk, позволяющий эффективно обрабатывать более сложные и зависимые транзакции, как, например, транзакции в DeFi.
Fuel
Fuel ориентирован на то, чтобы стать уровнем исполнения в модульном блокчейн-стеке.
То есть Fuel не поддерживает наличие консенсуса и не хранит данные блокчейна в сети Fuel.
Что касается функционального блокчейна, Fuel взаимодействует с другими сетями для обеспечения консенсуса и доступности данных, такими как Ethereum или Celestia.
Настоящая статья содержит хороший обзор концепции модульного блокчейна.
В модели Fuel используется UTXO для создания строгих списков доступа, т.е. списков для контроля доступа к одному и тому же фрагменту состояния.
Модель основана на концепции Канонического упорядочения транзакций.
Такая схема позволяет значительно упростить обнаружение зависимостей между транзакциями.
И для реализации этой системы была создана новая виртуальная машина FuelVM и новый язык Sway.
FuelVM — это совместимая и упрощенная реализация EVM, которая может оказаться эффективной с точки зрения привлечения разработчиков в экосистему Fuel.
Кроме того, поскольку Fuel фокусируется на модульном блокчейн-стеке, исполнение смарт-контрактов в Fuel может производиться в основной сети Ethereum.
Этот подход соответствует видению Ethereum после слияния, то есть как основного слоя для расчетов и доступности данных, ориентированного на роллапы.
С такой архитектурой Fuel может обеспечить высоко пропускную работу, где транзакции будут группироваться и рассчитываться на Ethereum.
Для демонстрации улучшенной производительности FuelVM по сравнению с EVM команда Fuel создала AMM в стиле Uniswap под названием SwaySwap, который работает в тестовой сети.
Проблемы, связанные с подходом параллельного выполнения
Метода параллельного выполнения кажется логичным и простым. Но есть много проблем, которые нужно обсуждать и решать.
- Первая — это точно определить процент транзакций, которые могут быть ускорены с помощью параллельного выполнения;
- Вторая проблема связана с децентрализацией сети.
Т.е. если валидаторы могут легко масштабировать вычислительную мощность для увеличения пропускной способности, то как полным нодам, которые зачастую используют простое оборудование, успевать и поддерживать корректность цепочки?
Процент параллелируемых транзакций
Оценить процент транзакций в сети, которые могут выполняться параллельно, довольно сложно в любой сети.
Кроме того, этот процент может значительно меняться от блока к блоку в зависимости от типа сетевой активности.
Например, событие минта NFT может привести к всплеску активности с высоким процентом зависимых транзакций.
Однако, мы можем использовать некоторые допущения, чтобы получить приблизительную оценку среднего процента параллелируемых транзакций.
Например, мы можем предположить, что большинство переводов ETH и ERC20 - это независимые переводы, т.е. исходящие и получаемые на разные адреса.
Следовательно, мы можем предположить, что ~25% простых переводов ETH и ERC20 являются зависимыми, т.е. депозитами в смарт-контракты и переводом биржами с горячих кошельков на холодные.
С другой стороны, все операции с AMM в одном пуле зависимые.
С учетом того, что в большинстве АММ зачастую доминирует небольшое количество пулов и что сделки АММ имеют высокую степень сложности и взаимодействуют с несколькими пулами, то можно с высокой степенью уверенности предположить, что по крайней мере 50% транзакций АММ зависимы.
Анализирую ежедневные транзакции в Ethereum, мы увидим, что из ~1,2 млн. транзакций в Ethereum:
- 20-30% составляют переводы ETH
- 10-20% — переводы стейблкоинов
- 10-15% — переводы в DEX
- 4-6% — сделки NFT
- 8-10% — одобрения ERC20
- 12-15% — другие переводы ERC20
Основываясь на этих цифрах и предположениях, можно предположить, что ПВ может ускорить примерно 70-80% транзакций на платформе смарт-контрактов.
Это также означает, что самый длинный путь выполнения, т.е. последовательное выполнение зависимых транзакций, может составлять 20-30% всех транзакций.
Другими словами, при использовании того же лимита газа можно было бы добиться 3-5-кратного увеличения пропускной способности с помощью ПВ.
Некоторые эксперименты по созданию EVM с параллельным выполнением показали аналогичные оценки, где 3-5-кратное улучшение пропускной способности может быть достигнуто.
solana claims to be able to handle more transactions thanks to their parallel execution
how big of a speed up could the evm get if it did something similar?
i built a parallel evm execution engine to find out
/thread
На практике же высокоэффективные сети используют гораздо более высокий лимит газа на блок и более короткое время подтверждения блока для достижения, по крайней мере, 100-кратного улучшения пропускной способности относительно Ethereum.
Рост пропускной способности требует мощных нод валидаторов для обработки этих блоков.
И это подводит нас ко второй проблеме — централизации сети.
Централизация сети
Еще одна распространенная критика параллельного вычисления заключается в том, что этот метод сильно подталкивает сеть к централизации.
Сети с высокой пропускной способностью могут обрабатывать десятки тысяч транзакций в секунду. Стимулирование нод валидаторов к обработке этих транзакций осуществляется за счет комиссий и сетевых вознаграждений.
Средства инвестируются в специальные серверы или масштабируемые облачные архитектуры для обработки этих транзакций.
Но этого нельзя сказать про компании или простых пользователей, которые пользуются сетью и нуждаются в полноценных нодах для взаимодействия с сетью.
Эти организации не могут позволить себе сложные серверы для обработки такой большой нагрузки транзакций.
В результате пользователи сети сильно зависят от специализированных провайдеров RPC нод, например, Infura, что ведет к еще большей централизации.
В отсутствие возможности использовать аппаратное обеспечение бытового класса для работы полноценных нод, высокопроизводительные сети могут превратиться в закрытую систему, где небольшая группа субъектов обладает абсолютной властью над сетью.
В этом сценарии эти организации могут координировать свои действия для цензуры транзакций, организаций или даже приложений, например, Tornado Cash, что превратит эти сети в разрешенные системы, ничем не отличающиеся от Web 2.
🌪 Пару слов о Tornado.cash от ТТ. #toptraders
1) санкции OFAC (управление по контролю за фин активами США) к миксеру и его адресам.
2) все адреса расследуют через Chainanalysis, а эти ребятки весьма дотошные.
3) первыми из миксеров попали в мае Blender.io
4) OFAC это конечная инс...
🌪 Пару слов о Tornado.cash от ТТ. #toptraders
1) санкции OFAC (управление по контролю за фин активами США) к миксеру и его адресам.
2) все адреса расследуют через Chainanalysis, а эти ребятки весьма дотошные.
3) первыми из миксеров попали в мае Blender.io
4) OFAC это конечная инстанция по отмыву денег, с ней судиться бесполезно, кейсов положительных единицы.
5) первый звоночек по Tornado cash был 15 апреля.
🔥 6) Расследование все ещё продолжается, скорее всего будут заблокированы все средства миксера и кошельки тех, кто напрямую гонял активы через них.
7) в прошлом году под пресс OFAC попал Binance, Kraken и Chatex/Suex/Garantex обменники.
8) скоро основателей Tornado cash объявят в розыск для суда в США и внесут в список Интерпола.
9) Binance после огромных проблем с OFAC скорее делистнит TORN токен, как и другие CEX биржи.
🔜 Крайне не рекомендуем гонять крипту через миксеры, так как ваш кошелёк может попасть в списки SDN и тогда можно про них забыть.
Сейчас требования к работе полноценной ноды в тестовой сети Sui ниже, чем к нодам тестовой сети Aptos.
Но мы ждем, что эти требования значительно изменятся, когда будут запущены основные сети и начнут появляться приложения в сети.
Сторонники децентрализации предлагают решения для устранения этих ожидаемых проблем.
Решения могут включать использование легких нод, которые проверяют правильность блоков с помощью zk-доказательств или доказательств мошенничества.
Команда Fuel активно работает в этом направлении и находится в постоянным диалоге с сообществом Ethereum по поводу важности децентрализации.
У команд Aptos и Sui нет ясности относительно приоритетности внедрения этих подходов или альтернативных подходов для продвижения децентрализации.
Команда Linera кратко затронула эти вопросы в своем информационном сообщении, но нужно дождаться подтверждения этой приверженности в реализации протокола.
Заключение
Механизмы параллельного выполнения — это перспективное решение для повышения пропускной способности платформ смарт-контрактов.
В сочетании с инновациями в области механизмов консенсуса параллельное выполнение транзакций может привести к появлению сетей с пропускной способностью, приближающейся или превышающей 100 тыс. транзакций в секунду.
Такая производительность, не уступающая Visa и Mastercard, позволит реализовать несколько сложных на сегодняшний день сценариев использования, таких как ончейн-игры и децентрализованные микроплатежи.
Подобно впечатляющее повышение пропускной способности не обходится без проблем, связанных с обеспечением децентрализации.
Оригинал статьи на ENG:
Мы с командой анализируем, рассказываем о крипте и развиваем сообщество с 2017 года. Создали десяток реальных юзкейсов и готовы делиться всем опытом с тобой. Заходи в наши Telegram-каналы и читай полезную аналитику каждый день...
Молодцы, растёте по охвату тем!