Деплой смарт-контрактів у Aptos

Розгортування смарт-контрактів в Aptos

Aptos — L1 блокчейн на базі Move VM, спочатку розроблений командою Diem (Meta). Головна відмінність від EVM: мова Move з її моделлю, орієнтованою на ресурси і лінійною системою типів. Ресурс (resource type) не можна скопіювати чи знищити довільно — лише явно передати. Це усуває цілий клас уразливостей, які переслідують Solidity: double-spend через reentrancy, токени, створені з повітря. Якщо ви звикли до EVM, перші дні з Move будуть дискомфортними — потім зрозумієте, чому це правильно.

Структура модуля на Move

В Aptos немає поняття "контракт" — є modules (код) і resources (дані, що зберігаються в акаунтах). Модуль опубліковується під адресою акаунту, resources живуть в акаунтах користувачів, а не в акаунті модуля:

module my_addr::token {
    use std::signer;

    struct CoinStore has key {
        balance: u64,
    }

    public fun initialize(account: &signer) {
        move_to(account, CoinStore { balance: 0 });
    }

    public fun deposit(account: &signer, amount: u64) acquires CoinStore {
        let store = borrow_global_mut<CoinStore>(signer::address_of(account));
        store.balance = store.balance + amount;
    }
}

has key — здатність, що дозволяє зберігати ресурс в глобальному сховищі. acquires — явне оголошення, що функція звертається до глобального ресурсу конкретного типу. Компілятор перевіряє це статично — немає неявних побічних ефектів.

Інструментарій: Aptos CLI

Основний інструмент — aptos CLI. Управління акаунтами, компіляція, розгортування, виклик функцій:

# Ініціалізація акаунту (генерує keypair, фондує devnet)
aptos init --network devnet

# Компіляція
aptos move compile --package-dir . --named-addresses my_addr=0xCAFE

# Публікація модуля
aptos move publish \
  --package-dir . \
  --named-addresses my_addr=<YOUR_ADDRESS> \
  --profile mainnet

Named addresses — механізм Aptos: в Move.toml ви використовуєте символічні імена, при розгортуванні підставляєте конкретні адреси. Це дозволяє розгортувати один і той же код з різних акаунтів без змін вихідного коду.

Move.toml та управління залежностями

[package]
name = "MyProtocol"
version = "1.0.0"

[addresses]
my_addr = "_"  # підставляється при розгортуванні

[dependencies.AptosFramework]
git = "https://github.com/aptos-labs/aptos-core.git"
rev = "mainnet"
subdir = "aptos-move/framework/aptos-framework"

Залежності витягуються з Git — це означає необхідність фіксувати rev конкретним коммітом для відтворюваних збірок. _ в адресі — заповнювач, обов'язково замінити при публікації.

Upgradeability: політика при розгортуванні

На відміну від Ethereum proxy-паттернів, апгрейдованість в Aptos керується на рівні VM через upgrade policy, задана в Move.toml:

[package]
upgrade_policy = "compatible"  # або "immutable"

• compatible — дозволені сумісні оновлення: додавання функцій і ресурсів, але не можна змінити існуючі сигнатури чи видалити поля
• immutable — модуль заморожений назавжди, ніяких оновлень

compatible — правильний вибір для production з живою логікою. Після публікації з immutable контракт не можна змінити — це потрібно усвідомлено. Немає паттернів "проксі + імплементація" як в EVM; апгрейд працює через повторну публікацію під тією ж адресою з перевіркою сумісності.

Тестування

Move має вбудований тест-фреймворк — тесты пишуться прямо в модулях з атрибутом #[test]:

#[test_only]
module my_addr::token_tests {
    use my_addr::token;
    use aptos_framework::account;

    #[test(alice = @0x1)]
    fun test_deposit(alice: signer) acquires token::CoinStore {
        token::initialize(&alice);
        token::deposit(&alice, 100);
        // assert state
    }
}

aptos move test --package-dir . --named-addresses my_addr=0x1

Для більш складних сценаріїв — Aptos Move Prover: формальна верифікація інваріантів через SMT-solver (Z3). Це рівень вище звичайного тестування:

spec deposit {
    ensures global<CoinStore>(signer::address_of(account)).balance ==
        old(global<CoinStore>(signer::address_of(account))).balance + amount;
}

Чеклист перед mainnet-розгортуванням

• Тесты покривають усі public функції, включаючи граничні значення (u64::MAX)
• Prover специфікації для критичної фінансової логіки
• upgrade_policy свідомо вибрана — immutable лише якщо впевнені
• Named addresses зафіксовані в deployment скрипті, не хардкодані вручну
• Акаунт розгортувача — multisig через Aptos native multisig (on-chain, не EOA)
• Версія Aptos Framework в залежностях відповідає цільовій мережі (mainnet / testnet)
• Після розгортування — верифікація через Aptos Explorer (вихідний код опубліковується on-chain)