Move: Sui, Aptos и ресурсная модель

В июне 2023 года Sui обработала транзакцию за 390 миллисекунд. Не подтвердила - финализировала. Для сравнения: Ethereum в тот же момент требовал 12-15 минут для финальности. Разница в 2000 раз - это не разгон на лучшем железе. За этим стоит язык программирования, в котором монету нельзя скопировать, токен нельзя потерять, а компилятор математически доказывает корректность контракта. Этот язык - Move, и он переосмысливает саму идею того, что значит «владеть» цифровым активом.

• **DeFi на Sui (Cetus, Turbos)** - AMM-пулы реализованы как shared objects, а позиции ликвидности - как owned objects. Благодаря этому добавление/удаление ликвидности обходится без консенсуса (~400ms), а свопы проходят через быстрый Narwhal+Bullshark
• **Aptos Labs + Microsoft** - Aptos использует Move и Block-STM для корпоративных решений: цифровые активы с формальной верификацией (Move Prover доказывает, что баланс не может стать отрицательным для всех возможных входных данных)
• **Reentrancy-атака на The DAO (60M, 2016)** - была бы невозможна в Move: нет dynamic dispatch, ресурс нельзя использовать дважды, а Move Prover обнаружил бы нарушение инварианта баланса до деплоя

Предварительные знания

• EVM: Ethereum Virtual Machine

Язык Move: от Diem к Sui и Aptos

В 2019 году Facebook (ныне Meta) разрабатывал блокчейн **Libra** (позже переименованный в **Diem**) для глобальных платежей. Инженеры изучили все известные уязвимости Solidity - reentrancy, integer overflow, неявное копирование токенов - и пришли к радикальному выводу: **проблема не в программистах, а в языке**. Так родился **Move** - язык, в котором целые классы багов невозможны по определению.

Проект Diem закрылся в 2022 году под давлением регуляторов, но Move выжил. Две команды из бывших инженеров Facebook основали отдельные блокчейны: **Aptos** (Avery Ching, Mo Shaikh) и **Sui** (Evan Cheng, Sam Blackshear - создатель Move). Оба блокчейна запущены в mainnet в 2023 году.

Move - это **статически типизированный язык с системой модулей**. Код организован в пакеты (packages), каждый пакет содержит модули, а модули определяют struct-типы и функции. В отличие от Solidity, где контракт - это и код, и данные, в Move **код (модуль) и данные (ресурсы) разделены**.

Сравним подходы Move и Solidity к базовой безопасности:

**Move Prover** - встроенный инструмент формальной верификации. Разработчик описывает *спецификацию* (invariants, pre/post-conditions), а Prover математически доказывает, что код им соответствует. Это не тестирование - это **доказательство корректности** для всех возможных входных данных.

Ресурсы: активы как типы

В Solidity токен - это **запись в mapping**: `mapping(address => uint256) balances`. Чтобы «отправить» токен, вы вычитаете число из одной ячейки и прибавляете к другой. Но что если баг позволит прибавить, не вычитая? Или вычесть дважды? Контракт ERC-20 - это просто бухгалтерская книга, и вся безопасность держится на корректности арифметики.

Move подходит к проблеме радикально иначе. **Ресурс (resource)** - это тип данных, который **нельзя скопировать и нельзя неявно уничтожить**. Монета в Move - не число в таблице, а объект, который можно только переместить из одного владельца к другому. Как физическая купюра: если я отдал её вам, у меня её больше нет.

Для работы с ресурсами Move предоставляет специальные операции. Каждая из них контролирует **владение и доступ**:

Сравним, как ERC-20 и Move Coin решают проблему двойной траты:

В Move невозможно «забыть» ресурс. Если функция получила `Coin` и не переместила его куда-то (transfer, deposit, деструктуризация) - **код не скомпилируется**. Компилятор отслеживает каждый ресурс и требует явного обращения с ним. Это как если бы компилятор C++ не позволял забыть `free()` - но на уровне типов, а не рантайма.

Линейные типы и система abilities

Ресурсы в Move - это не магия, а следствие фундаментальной теории из computer science. **Линейные типы** (linear types) - концепция из линейной логики (Jean-Yves Girard, 1987), где каждое значение должно быть использовано **ровно один раз**. Ни больше (копирование), ни меньше (уничтожение без использования).

Строго говоря, Move использует не линейные, а **аффинные типы** (affine types). Разница: линейный тип должен быть использован ровно один раз, аффинный - *не более* одного раза. Это значит, что в Move ресурс можно уничтожить (через деструктуризацию), но нельзя скопировать. Аффинные типы также используются в Rust (ownership system).

Вместо единого понятия «ресурс» Move использует гибкую **систему abilities** - четырёх разрешений, определяющих поведение типа. Каждый struct получает только те abilities, которые явно указаны:

Система abilities позволяет ловить целые классы Solidity-багов на этапе компиляции:

Sui и Aptos реализуют Move по-разному. **Aptos** использует **global storage** - ресурсы привязаны к адресам аккаунтов (`move_to`, `move_from`, `borrow_global`). **Sui** использует **object-centric модель** - каждый объект имеет глобально уникальный ID и может быть owned (принадлежит адресу), shared (доступен всем) или immutable (только чтение).

Параллельное исполнение транзакций

Ethereum обрабатывает транзакции **строго последовательно**: каждая видит результат предыдущей. Это гарантирует корректность, но ставит жёсткий потолок производительности - ~15-30 TPS. Почему нельзя просто запустить транзакции параллельно? Потому что две транзакции могут читать и писать одни и те же данные (storage slots), и параллельное исполнение даст непредсказуемый результат.

Move-блокчейны решают эту проблему двумя разными путями. **Sui** использует объектную модель, где владение определяет параллелизм заранее. **Aptos** использует оптимистичное параллельное исполнение. Оба подхода дают на порядок больше пропускной способности, чем Ethereum.

**Block-STM** (Software Transactional Memory) - алгоритм, разработанный командой Aptos. Он вдохновлён концепцией STM из Haskell и базами данных (MVCC в PostgreSQL). Ключевая идея: исполнить транзакции параллельно оптимистично, а затем обнаружить и повторить конфликтующие.

**Sui** использует принципиально другой подход: **объектно-центрическую модель с DAG-исполнением**. Если транзакция работает только с объектами, принадлежащими одному владельцу (owned objects), Sui может обработать её **без консенсуса** - через Byzantine Consistent Broadcast. Это исключает задержку на упорядочивание.

Сравним подходы к параллелизму четырёх блокчейнов:

Тестовые TPS-цифры нужно читать с осторожностью. Aptos и Sui показывают сотни тысяч TPS в лабораторных условиях (простые переводы, идеальная сеть). В реальном mainnet с DeFi-транзакциями, которые работают с shared objects, цифры на порядок ниже. Тем не менее, даже реальные 5,000-12,000 TPS - это на два порядка выше Ethereum.

Связь между ресурсной моделью и параллелизмом - не случайна. Именно потому, что Move чётко определяет **владение** каждым объектом, Sui может статически определить, какие транзакции независимы. А abilities (отсутствие `copy`) гарантируют, что объект не появится в неожиданном месте. Система типов Move - это фундамент, на котором построен весь параллелизм.

Итоги

• **Move - язык с ресурсной моделью**, созданный для безопасных смарт-контрактов. Reentrancy, integer overflow и двойная трата невозможны по дизайну языка, а не благодаря аккуратности программиста
• **Ресурсы не копируются и не теряются** - компилятор отслеживает каждый ресурс и требует явного обращения. Монета в Move - не число в mapping, а перемещаемый объект с гарантиями на уровне типов
• **Система abilities (copy, drop, store, key)** даёт гибкий контроль: Coin без copy/drop защищён от дублирования и потери; Config с полным набором abilities ведёт себя как обычная структура данных
• **Параллельное исполнение** стало возможным именно благодаря ресурсной модели: Sui определяет конфликты по владению объектами (owned vs shared), Aptos использует оптимистичный Block-STM с повтором конфликтующих транзакций
• Вернёмся к скорости Sui: 390ms финальность - это не просто хорошая сеть, а прямое следствие того, что язык Move делает владение явным, и ~90% транзакций (работающих с owned objects) не требуют полного консенсуса

Связанные темы

Move-блокчейны стоят на пересечении теории языков программирования, виртуальных машин и алгоритмов консенсуса:

• EVM: виртуальная машина Ethereum — Move спроектирован как ответ на ограничения EVM: отсутствие ресурсных типов и последовательное исполнение - проблемы, которые Move решает на уровне языка
• Solana: Sealevel и параллельное исполнение — Solana решает задачу параллелизма через декларативные access lists (Sealevel), тогда как Sui использует объектную модель, а Aptos - оптимистичный Block-STM
• Solidity: основы языка — Move и Solidity - два полярных подхода: Solidity даёт свободу (dynamic dispatch, произвольные storage записи), Move ограничивает ради безопасности (статические вызовы, ресурсные типы)
• HotStuff: BFT-консенсус — Aptos использует DiemBFT (основан на HotStuff) для консенсуса, а Sui - Narwhal+Bullshark (DAG-based BFT), оба являются развитием идей HotStuff

Вопросы для размышления

• Move делает невозможными многие типы багов (reentrancy, double-spend), но за счёт большей строгости. Какие приложения легче писать на Solidity, и оправдывает ли это дополнительный риск?
• Sui разделяет транзакции на «быстрые» (owned objects, без консенсуса) и «медленные» (shared objects, с консенсусом). Как это влияет на проектирование DeFi-протоколов - стоит ли минимизировать использование shared objects?
• Система abilities в Move похожа на ownership в Rust. Если бы Solidity v2 добавил аффинные типы, решило бы это проблемы безопасности, или Ethereum нужно менять и виртуальную машину?

Связанные уроки

• comp-01-intro