Перейти к основному контенту

Безопасность памяти Move VM против Reentrancy в EVM: почему ресурсная модель Aptos и Sui устраняет целые классы уязвимостей смарт-контрактов

· 10 мин чтения
Dora Noda
Dora Noda
Software Engineer

Хакерская атака на The DAO в 2016 году вывела $60 миллионов из Ethereum всего за один день. Девять лет спустя reentrancy-атаки по-прежнему обходятся DeFi-протоколам в $35,7 миллиона — только за 2024 год было зафиксировано 22 отдельных инцидента. Тот же класс уязвимости — когда злоумышленник совершает повторный вызов контракта до обновления его состояния — продолжает преследовать EVM-экосистему, несмотря на годы обучения разработчиков, инструменты аудита и проверенные временем паттерны.

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

Первопричина: как происходит EVM Reentrancy​

Чтобы понять, чем отличается Move, полезно разобраться, почему reentrancy вообще возможна в Ethereum.

Контракты Solidity могут вызывать внешние контракты в середине процесса выполнения. Когда контракт A вызывает контракт B, управление полностью переходит к B. Затем B может вызвать контракт A снова — совершить «повторный вход» (re-entering) — до того, как A закончит обновление своего внутреннего состояния. Если логика вывода средств в A выглядит так:

// Уязвимый паттерн
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}(""); // сначала внешний вызов
    balances[msg.sender] -= amount;                         // затем обновление состояния
}

Контракт злоумышленника может получить ETH в обратном вызове (callback), немедленно снова вызвать withdraw и вывести средства до того, как значение balances[msg.sender] будет уменьшено. Именно это произошло с The DAO — контракт атакующего рекурсивно вызывал функцию вывода 3,6 миллиона раз в цикле.

Решение кажется простым: обновляйте состояние перед выполнением внешних вызовов (паттерн «Checks-Effects-Interactions»). Но разработчики забывают об этом. Аудиторы пропускают это. Этот паттерн — лишь соглашение, соблюдение которого зависит от внимательности человека, а не от самого языка.

Подход Move: ресурсы нельзя дублировать или уничтожать​

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

В Move ресурс — это особый вид значения, который:

  • Не может быть скопирован — его можно только перемещать между местами хранения.
  • Не может быть удален — он должен быть явно использован или сохранен где-либо.
  • Имеет только одного владельца в любой момент времени — это отслеживается виртуальной машиной (VM), а не простым сопоставлением (mapping).

Это звучит абстрактно, но последствия вполне конкретны. Рассмотрим, как работает перевод токенов:

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

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

Почему Reentrancy структурно невозможна в Move​

Для reentrancy необходимы два условия: возможность вызова внешнего кода в середине выполнения и изменяемое общее состояние, которым можно манипулировать во время этого обратного вызова. Move нарушает оба этих условия.

Move не допускает динамической диспетчеризации так, как это делает Solidity. Здесь нет произвольных внешних вызовов, передающих управление неизвестному коду. Функции должны вызываться статически — вызываемый объект известен во время компиляции. Это означает, что злоумышленник не может развернуть контракт, который повторно войдет в ваш модуль во время обратного вызова, потому что ваш модуль никогда не передает управление неизвестному внешнему контракту.

Кроме того, объектная модель Move в Sui и Aptos использует систему владения, при которой объекты явно передаются в функции и выводятся из них. Объект, который был «перемещен» в функцию, недоступен больше нигде до тех пор, пока функция его не вернет. Параллельный доступ к одному и тому же ресурсу в рамках одной транзакции просто невозможен.

Исследование, опубликованное в 2025 году, подтверждает: «В Move reentrancy невозможна, так как невозможны динамические обратные вызовы — фундаментальное отличие от Solidity, где reentrancy остается серьезной угрозой».

Предотвращение двойной траты без мьютексов​

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

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

Это также относится к объектам полномочий (capability objects) в Sui. Ресурс Capability, однажды использованный, не может быть применен снова. Сравните это с паттернами управления доступом в EVM, где полномочия обычно представляют собой роль, закодированную в логическом значении или маппинге адресов, которую можно проверять многократно.

Один реальный инцидент на Sui подчеркивает нюанс: в одном DEX была обнаружена ошибка, при которой логика вывода не обеспечивала соблюдение ограничений на однократное использование изменяемой ссылки (mutable reference) на полномочие — не самого полномочия. Это демонстрирует, что хотя ресурсная модель Move устраняет целые классы багов, разработчики все же могут допускать логические ошибки при работе со ссылками, а не с объектами во владении. Поверхность атаки значительно сужается, но не до нуля.

Целочисленное переполнение: еще одна проблема, которую Move решает по умолчанию​

В ранних версиях Solidity (до 0.8.0) арифметические операции с целыми числами при переполнении молча возвращались к началу диапазона (зацикливались). Это позволяло злоумышленникам манипулировать балансами токенов, вызывая условия переполнения — уязвимость, которая способствовала нескольким громким эксплойтам в сфере DeFi.

В Solidity 0.8.0 была введена автоматическая проверка переполнения, но это произошло только после многих лет нанесенного ущерба. В Move эта защита встроена с самого начала: любая транзакция, вызывающая целочисленное переполнение, автоматически прерывается. Здесь нет возможности отказа, нет эквивалента unchecked по умолчанию и нет устаревших контрактов со старым поведением, о которых стоит беспокоиться.

Формальная верификация: Move Prover против аудита EVM​

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

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

Это принципиально отличается от того, как работает большинство аудитов Solidity:

АспектMove ProverИнструменты аудита Solidity
Тип верификацииМатематическое доказательствоСопоставление шаблонов / фаззинг
ПокрытиеПолное (в рамках спецификации)По мере возможности (Best-effort)
ИнтеграцияЧасть инструментария языкаСторонние инструменты (Slither, Certora)
Время примененияВо время разработкиАудит перед развертыванием
СтоимостьБесплатно, в репозиторииДорогие ручные аудиты

Инструменты вроде Slither для Solidity выполняют статический анализ и обнаруживают известные паттерны уязвимостей. Certora Prover для Solidity поддерживает формальную верификацию и может описывать более широкий набор свойств, включая межтранзакционные инварианты. Однако Certora требует написания спецификаций на отдельном языке и запуска отдельного конвейера, что делает ее специализированным этапом аудита, а не повседневным инструментом разработки.

Более тесная интеграция Move Prover означает, что формальная верификация — это то, что разработчики Aptos и Sui могут запускать локально во время разработки, а не только в качестве дорогостоящего этапа аудита. Сам фреймворк Aptos поставляется со спецификациями Move Prover для своей стандартной библиотеки, обеспечивая базовый уровень безопасности, который наследуют разработчики приложений.

Остаточный риск: что Move не устраняет​

Дизайн Move не является универсальной гарантией безопасности. Реальные аудиты контрактов Move показывают, что разработчики все еще могут допускать:

  • Логические ошибки в бизнес-правилах (самая распространенная категория)
  • Ошибки контроля доступа при использовании мутабельных ссылок вместо владеемых ресурсов
  • Недостатки экономического дизайна в протоколах DeFi (манипуляции с ценовыми оракулами, атаки с использованием мгновенных займов — flash loans)
  • Ошибки взаимодействия модулей, когда несколько модулей взаимодействуют непредвиденным образом

В исследовании 2024 года было вручную проверено 652 контракта Move и выявлено восемь типов дефектов, половина из которых ранее не регистрировалась. Поверхность атаки меньше, чем в Solidity, но она все еще существует.

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

Почему это важно для создателей DeFi в 2025 году​

Цифры говорят сами за себя. В 2024 году уязвимости смарт-контрактов обошлись сектору DeFi более чем в 1,4млрд.Реентерабельность(reentrancy)принеслаубыткивразмере1,4 млрд. Реентерабельность (reentrancy) принесла убытки в размере 35,7 млн — категория, которая была бы структурно равна нулю в сети на базе Move с эквивалентным TVL.

Для разработчиков, создающих финансовые приложения, выбор виртуальной машины (VM) — это, по сути, выбор модели угроз по умолчанию. Разработка на EVM означает принятие паттерна Checks-Effects-Interactions как обязательной дисциплины. Разработка на Move означает, что реентерабельность просто не входит в вашу модель угроз — ваша команда может сосредоточить свое внимание на логических ошибках и экономическом дизайне.

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

Инфраструктурный слой​

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

BlockEden.xyz предоставляет API-доступ корпоративного уровня для Aptos и Sui, позволяя разработчикам использовать гарантии безопасности Move без управления инфраструктурой узлов. Изучите наши услуги, чтобы создавать более безопасные Web3-приложения.

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

Использованные источники:

Share on Twitter