Sui против Aptos: почему конкурируют блокчейны на Move

Но на уровне исполнения транзакций они пошли разными путями.

Sui строит сеть вокруг объектов и DAG-структуры. Aptos сохраняет аккаунт-ориентированную модель блокчейна и применяет Block-STM — движок параллельного исполнения на основе оптимистичной конкурентности. Поэтому вопрос «что лучше — Sui или Aptos» не имеет ответа без указания типа нагрузки. Игровая логика, NFT, обмен токенами и классический DeFi создают разные профили конфликтов, газа и задержек.

В доступных сравнительных данных Sui показывает около 0,5 секунды до финализации транзакции против примерно 0,9 секунды у Aptos. Теоретическая пропускная способность также заявлялась выше у Sui: до 297 000 TPS против примерно 160 000 TPS у Aptos. Эти значения нельзя интерпретировать как постоянный суточный TPS в мейннете.

Наследие Diem: общий исходный код не означает одинаковую сеть

Sui и Aptos создавались командами, в которых работали бывшие инженеры Meta, участвовавшие в разработке закрытого проекта Diem, ранее известного как Libra. Sui разрабатывает Mysten Labs. Среди сооснователей компании — Эван Ченг и Сэм Блэкшир. Aptos Labs основали Мо Шейх и Эйвери Чинг.

Общее происхождение объясняет несколько совпадений:

• обе сети ориентированы на высокую пропускную способность;
• обе используют язык Move;
• обе делают акцент на безопасной работе с цифровыми активами;
• обе отделяют логику смарт-контрактов от традиционных ограничений EVM-совместимых сетей;
• обе проектировались с расчетом на параллельное выполнение операций.

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

Aptos ближе к классическому представлению о блокчейне. Есть аккаунты, транзакции, последовательное состояние цепочки и исполнитель, который пытается обрабатывать независимые операции параллельно. Sui меняет саму модель состояния. Основной единицей становятся объекты. Это влияет на то, как сеть определяет зависимости между транзакциями и какие операции можно исполнять без общей последовательной фиксации.

Общий предок объясняет сходство Move. Архитектура исполнения объясняет различие между сетями.

Сравнивать Sui и Aptos только по происхождению от Diem некорректно. У них разная техническая гипотеза.

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

Move как фундамент безопасности

Move — ресурсно-ориентированный язык программирования. Его модель рассчитана на работу с цифровыми активами, которые нельзя произвольно копировать или уничтожать обычными операциями над данными.

В типичной объектной логике токен или другой актив представлен не просто числовым балансом в хранилище. Он имеет свойства и правила обращения, заданные кодом модуля. Это не устраняет ошибки в бизнес-логике. Но ограничивает класс технических ошибок, характерных для моделей, где активы представлены набором несвязанных переменных и функций.

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

1. Ресурс нельзя безусловно скопировать как обычное значение.

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

3. Логика передачи ресурса становится частью проверяемой структуры программы.

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

Здесь требуется точная формулировка. Move не делает смарт-контракт безопасным автоматически. Ошибка в расчетах, неверная проверка прав, некорректная обработка цены оракула или дефект в механизме ликвидации остаются возможными. Язык снижает поверхность атаки, но не заменяет аудит и анализ инвариантов протокола.

Атака повторного входа — только один из классов проблем. В EVM-контрактах она возникает, когда контракт передает управление внешнему вызову до завершения собственного изменения состояния, а вызываемая сторона повторно обращается к исходной функции. В Move архитектура ресурсов и модель вызовов устроены иначе. Это не означает отсутствия эксплойтов. Это означает, что определенная категория ошибок блокируется не постфактум мониторингом, а правилами языка.

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

Архитектурный раскол: объекты Sui против аккаунтов Aptos

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

Aptos использует Block-STM. Это механизм параллельного исполнения, основанный на оптимистичной конкурентности. Исполнитель не обязан заранее выстроить все транзакции в полностью последовательную очередь. Он запускает независимые операции параллельно, фиксирует результаты и затем проверяет, не возникли ли конфликты.

Логика процесса выглядит так:

1. Транзакции запускаются параллельно.

2. Для каждой операции фиксируются прочитанные и измененные участки состояния.

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

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

5. При высокой доле конфликтов преимущество параллельного исполнения уменьшается.

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

Sui использует объектно-ориентированную модель. Активы и элементы состояния представлены объектами с определенными свойствами. Для исполнения важна не только отправитель транзакции, но и то, какие объекты она читает или изменяет.

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

При этом объектная модель усложняет проектирование. Разработчик должен заранее определить:

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

Проблема не в том, что одна модель проще другой. Они по-разному распределяют сложность. В Aptos основной вопрос связан с обнаружением конфликтов при параллельном исполнении. В Sui — с корректным описанием отношений между объектами и операциями над ними.

Что означает DAG в Sui

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

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

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

Параллельное исполнение: Block-STM и Mysticeti решают разные задачи

Сравнение Block-STM и Mysticeti часто приводит к технической ошибке. Эти компоненты нельзя ставить в один ряд как прямые альтернативы.

Block-STM — движок параллельного исполнения транзакций в Aptos. Он отвечает за то, как виртуальная машина обрабатывает операции и как проверяет конфликты между ними.

Mysticeti — консенсусный механизм Sui, встроенный в DAG-архитектуру сети. Он отвечает за согласование порядка и подтверждение состояния между участниками протокола.

Упрощенно разделение выглядит следующим образом:

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

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

В Aptos оптимистичный подход Block-STM эффективен при значительном количестве независимых транзакций. Но если операции пересекаются по состоянию, исполнитель вынужден учитывать зависимости и переисполнять конфликтующие задачи.

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

Параллельность — свойство не только блокчейна. Она зависит от того, как разработчик разложил состояние приложения.

Для пользователя это имеет практическое следствие. Две сети могут показывать высокие результаты в тестах, но вести себя по-разному при одинаковом сценарии DeFi. В одном случае узким местом станет общий пул ликвидности. В другом — проверка зависимостей между аккаунтами. В третьем — объем вычислений внутри Move-модуля.

Производительность в цифрах: финализация против TPS

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

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

• Sui — около 0,5 секунды;
• Aptos — около 0,9 секунды.

Разница составляет примерно 0,4 секунды. Для приложений, где пользователь ожидает немедленного подтверждения, это существенный параметр. Особенно для игр, торговых интерфейсов и операций, в которых задержка влияет на последовательность действий.

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

Пропускная способность в доступном сравнении выглядит так:

• Sui — до 297 000 TPS в теоретических или тестовых условиях;
• Aptos — около 160 000 TPS в аналогичном контексте.

Здесь нельзя делать вывод, что Sui постоянно обрабатывает 297 000 транзакций в секунду в рабочей сети. Это заявленный теоретический предел, зафиксированный в тестах. Реальный показатель меняется в зависимости от нагрузки и характера dApp.

TPS также не описывает стоимость операции. Для пользователя важны минимум четыре связанные величины:

1. Газ. Сколько нативного токена требуется для выполнения транзакции.

2. Пропускная способность. Сколько операций сеть может обработать в единицу времени.

3. Финализация. Когда результат становится окончательным.

4. Конфликтность состояния. Как часто операции конкурируют за одни и те же данные.

Высокий TPS при частых конфликтах не гарантирует стабильного пользовательского опыта. Быстрая финализация при дорогом газе также не решает проблему масштабирования приложения. Поэтому сравнение Sui или Aptos должно начинаться не с максимальной цифры, а с профиля нагрузки.

Для каких приложений различия наиболее заметны

NFT и игровые активы

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

Aptos также может использоваться для таких приложений. Но модель аккаунтов и механизм параллельного исполнения требуют учитывать конфликты на уровне состояния. Итоговая эффективность зависит от конкретного Move-кода.

DeFi

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

Для DeFi приоритетны другие параметры:

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

Нельзя переносить безопасность сети на безопасность отдельного протокола. Move снижает вероятность некоторых классов ошибок. Он не предотвращает эксплойт в математике AMM, ошибку в расчете collateral ratio или неверную логику распределения комиссий.

Высокочастотные операции

Если приложению критична задержка, разница между примерно 0,5 и 0,9 секунды до финализации может иметь значение. Но она не отменяет требований к RPC-инфраструктуре и обработке конфликтов.

В приложении с большим количеством независимых операций Sui может использовать преимущества своей модели. В приложении с аккаунтами и хорошо разделяемыми транзакциями Aptos способен эффективно применять Block-STM. В обоих случаях итог определяется не рекламным TPS, а фактическим паттерном чтения и записи состояния.

Разница между Sui и Aptos для разработчика

При выборе сети нужно оценивать не только скорость консенсуса. Основная точка принятия решения — соответствие модели данных архитектуре приложения.

Порядок анализа можно формализовать:

1. Определить единицу состояния.

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

2. Построить карту конфликтов.

Нужно определить, какие функции читают одни и те же ресурсы и какие операции изменяют их. В Aptos это напрямую связано с поведением Block-STM. В Sui — с тем, какие объекты являются независимыми, а какие требуют общего доступа.

3. Отделить тестовый TPS от рабочего сценария.

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

4. Проверить стоимость газа.

Цена транзакции зависит не только от базового уровня комиссии. На нее влияет сложность Move-вызова, объем изменений состояния и используемая инфраструктура.

5. Проверить логику контракта.

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

6. Оценить инструменты и экосистему.

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

7. Разделить риск сети и риск токена.

Надежность консенсуса не равна устойчивости цены нативного актива. TVL протокола не равен безопасности его смарт-контракта. Ликвидность рынка не равна качеству исполнения транзакций.

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

Что выбрать: Sui или Aptos

Когда рационально смотреть на Sui

Sui логично рассматривать, если приложение:

• работает с большим числом независимых объектов;
• использует NFT или игровые активы;
• требует короткого времени до финализации;
• может извлечь пользу из объектно-ориентированной модели;
• не строит критическую логику вокруг одного общего состояния;
• рассчитано на параллельные операции с разными объектами.

Это не автоматическое преимущество. Если приложение постоянно обращается к общему объекту, часть архитектурного выигрыша может исчезнуть. Заявленные показатели до 297 000 TPS не должны использоваться как гарантия производительности.

Когда рационально смотреть на Aptos

Aptos подходит для сценариев, где:

• архитектура естественно описывается через аккаунты и состояния пользователей;
• транзакции можно разделить по независимым участкам состояния;
• разработчик готов учитывать механизм конфликтов Block-STM;
• приложению важна параллельная обработка без отказа от линейной структуры цепочки;
• используемый стек уже ориентирован на Aptos и Move.

Показатель около 160 000 TPS остается теоретической или тестовой характеристикой. Реальный результат зависит от нагрузки, размера транзакций и числа конфликтов.

Сводный вердикт

Ответ на запрос «что лучше — Sui или Aptos» зависит от конкретного dApp. По приведенным техническим метрикам Sui имеет преимущество по времени финализации и заявленной теоретической пропускной способности. Aptos предлагает другую модель масштабирования — линейную архитектуру с Block-STM и оптимистичным обнаружением конфликтов.

Бинарный вердикт:

• Sui — безопасный выбор, если приложение построено вокруг независимых объектов и использует преимущества объектной модели.
• Aptos — безопасный выбор, если приложение рассчитано на аккаунт-ориентированное состояние и корректно обрабатывает конфликты Block-STM.
• Оба варианта небезопасны, если выбор сделан только по TPS, без анализа Move-кода, газа, проскальзывания, общего состояния, оракулов и возможных путей эксплойта.

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