Руководство по Solana Anchor Framework

Solana Anchor Framework помогает разработчикам создавать программы со структурированной валидацией аккаунтов, определениями инструкций, сгенерированными интерфейсами и повторно используемыми проверками безопасности.

Примечание о версии: Версии Anchor, Rust, Solana CLI и клиентского JavaScript меняются независимо. Проверяйте текущую совместимость в официальной документации Anchor перед установкой или развертыванием.

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

📌 ПРИМЕЧАНИЕ: В данном руководстве используется Anchor v0.29.x и Solana CLI v1.18.x+, актуальные на 2024 год. Anchor Framework быстро развивается. Выполните anchor --version, чтобы проверить установленную версию, прежде чем следовать этим инструкциям.

Содержание

1. Что такое Solana Anchor Framework?
2. Модель аккаунтов Solana
3. Основные компоненты Solana Anchor Framework
4. Предварительные требования
5. Как установить Anchor Framework
6. Создание и развертывание вашей первой программы Anchor
7. Тестирование программ Anchor
8. Anchor против альтернатив
9. Безопасность Anchor Framework
10. Устранение распространенных ошибок Anchor
11. Anchor Framework и экосистема разработчиков Solana
12. Часто задаваемые вопросы
13. Заключение

Что такое Solana Anchor Framework?

Solana Anchor Framework — это фреймворк с открытым исходным кодом для разработки, который устраняет шаблонный код и сложность валидации аккаунтов при написании программ Solana (ончейн-аналог смарт-контрактов) на чистом Rust.

Solana — это высокопроизводительный блокчейн уровня 1, который обрабатывает примерно 65 000 транзакций в секунду в оптимальных условиях (по состоянию на 2024 год), с завершением транзакций менее чем за секунду и комиссиями обычно ниже $0.001. Solana достигает такой пропускной способности, отчасти благодаря уникальному механизму консенсуса, называемому Proof of History (PoH), который создает криптографические часы, упорядочивающие транзакции без накладных расходов на связь традиционных протоколов консенсуса.

Разработка на Solana без фреймворка означает написание многословного низкоуровневого кода на Rust для каждой программы. Разработчики должны вручную проверять владение аккаунтами, сериализовать данные, обрабатывать ошибки и управлять связями между аккаунтами для каждой транзакции. Для инженеров, пришедших из Web2-бэкендов или разработки на Ethereum, эта стена обучения достаточно высока, чтобы остановить большинство проектов до их начала.

Anchor меняет это. Представьте Anchor как Ruby on Rails для разработки Solana: предвзятый фреймворк, который берет на себя рутинную работу, чтобы вы могли сосредоточиться на логике своей программы, а не на инфраструктуре под ней. Anchor был создан Armani Ferrante и поддерживается Coral XYZ. Вы можете найти исходный код и релизы на репозитории Anchor на GitHub (coral-xyz/anchor).). Текущая стабильная версия — v0.29.x.

Anchor позволяет разработчикам создавать децентрализованные приложения (dApps). dApp — это приложение, логика бэкенда которого работает на блокчейне через программы Solana, а не на централизованном сервере. Программа — это бэкенд dApp; клиент TypeScript, который генерирует Anchor, — это способ, которым ваш фронтенд вызывает его. К категориям dApps, созданных с помощью Anchor, относятся протоколы децентрализованных финансов (DeFi), платформы невзаимозаменяемых токенов (NFT), децентрализованные автономные организации (DAO) и Web3-игры.

К концу этого руководства вы поймете основную архитектуру Anchor, настроите рабочую среду разработки, развернете программу в devnet Solana (тестовой сети с бесплатным, не имеющим ценности SOL) и получите достаточно контекста, чтобы оценить, подходит ли Anchor вашему проекту. Для прямого сравнения того, как Anchor выглядит на фоне инструментов Ethereum и нативной разработки на Rust, см. сравнение Anchor с Hardhat от Ethereum и нативной разработкой на Rust.

Что вы узнаете:

• Что такое Solana и почему ее архитектура делает Anchor необходимым
• Что делают IDL, макросы и PDA, и как программы вызывают друг друга
• Как установить полную среду разработки Anchor
• Как написать и развернуть вашу первую программу Anchor
• Уязвимости безопасности, которых следует избегать перед развертыванием в мейннет
• Как устранять наиболее распространенные ошибки Anchor

Модель аккаунтов Solana: Основа, которую вам нужно понять в первую очередь

Модель аккаунтов Solana — это архитектурная основа, которая делает Anchor необходимым. Она значительно отличается от всего, с чем вы сталкиваетесь при разработке на Ethereum или в Web2. Прежде чем абстракции Anchor станут понятными, вам нужно понять проблему, которую они решают.

Что такое Solana

Solana — это сетевой блокчейн уровня 1, разработанный для высокой пропускной способности и низких комиссий за транзакции. В отличие от Ethereum, который обрабатывает примерно от 15 до 30 транзакций в секунду в мейннете, Solana обрабатывает примерно 65 000 транзакций в секунду в оптимальных условиях (по состоянию на 2024 год). Комиссии за транзакции обычно составляют менее $0.001. Эта комбинация скорости и стоимости делает Solana хорошо подходящей для приложений, требующих множества мелких, частых транзакций: торговые системы (DeFi), платформы для минтинга (NFT) и ончейн-игры.

SOL — это нативный токен Solana. Он используется для оплаты комиссий за транзакции и за аренду, которую ончейн-аккаунты должны поддерживать, чтобы оставаться активными в сети. Каждая развернутая вами программа и каждый созданный вашей программой аккаунт требуют SOL для существования ончейн. В devnet (бесплатной тестовой сети Solana) вы получаете SOL-аирдропы бесплатно.

Преимущества в скорости достигаются за счет архитектурных решений, которые делают разработку на Solana на сыром уровне сложнее, чем на Ethereum. Anchor решает именно эти сложные аспекты.

Как Solana хранит программы и данные

В Solana «аккаунты» — это не пользовательские или кошельковые аккаунты в обычном понимании. Аккаунты — это единицы хранения в блокчейне: отдельные контейнеры, которые могут содержать данные, баланс SOL или исполняемый код программы.

Ключевое архитектурное отличие: в Solana программы (исполняемый код) и данные (состояние) находятся в отдельных аккаунтах. Программы без сохранения состояния. Аккаунт программы содержит только скомпилированный байт-код. Данные хранятся в отдельных аккаунтах данных, которые программы читают и записывают.

В Ethereum смарт-контракт подобен самодостаточной квартире: код и мебель находятся в одном пространстве. В Solana программа больше похожа на компанию с отдельными отделами: исполняемая логика находится в одном аккаунте, а данные, которые она читает и записывает, — в других аккаунтах.

Каждый аккаунт Solana имеет три свойства: владелец (программа, которая им управляет), адрес публичного ключа (его ончейн-идентификатор) и баланс лампортов (наименьшая единица SOL, где 1 SOL равен 1 миллиарду лампортов). Аккаунты данных также хранят сериализованные данные программы.

Практическое последствие: когда вы вызываете программу Solana, вы должны явно передать каждый аккаунт, который программа будет читать или в который будет записывать. Вы должны доказать владение. Вы должны объявить, какие аккаунты являются изменяемыми. Вы должны проверить, какие аккаунты являются подписантами. В чистом Rust такое управление аккаунтами требует сотен строк кода валидации на каждую программу.

Это явное управление аккаунтами — как раз та проблема, для решения которой разработана система ограничений Anchor.

Основные компоненты фреймворка Solana Anchor: IDL, макросы, PDA и CPI

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

IDL (Язык определения интерфейса): коммуникационный контракт Anchor

Anchor автоматически генерирует JSON-файл под названием Interface Definition Language (IDL) каждый раз, когда вы запускаете anchor build. Думайте об этом как о спецификации OpenAPI для вашей ончейн-программы: машиночитаемое описание каждой инструкции, которую принимает ваша программа, каждого аккаунта, который требуется для этих инструкций, и каждого задействованного типа данных.

IDL для Anchor — это то же самое, что ABI (Application Binary Interface) для контракта Solidity на Ethereum. Если вы строили на Ethereum, вы уже знаете, как ABI позволяют фронтенд-коду вызывать функции контракта с типобезопасностью. IDL в Anchor делает то же самое для программ Solana, и он генерируется автоматически из вашего кода на Rust. Вам никогда не придется писать его вручную.

Файл IDL попадает в target/idl/имя_вашей_программы.json после выполнения anchor build. Наряду с ним Anchor генерирует target/types/имя_вашей_программы.ts — файл типов TypeScript, который ваши скрипты фронтенда или тестов импортируют для получения полностью типизированного доступа к инструкциям вашей программы.

Сокращенный IDL выглядит следующим образом:

{
  "version": "0.1.0",
  "name": "balance_tracker",
  "instructions": [
    {
      "name": "initialize",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": true, "isSigner": true  },
        { "name": "systemProgram",  "isMut": false, "isSigner": false }
      ],
      "args": []
    },
    {
      "name": "deposit",
      "accounts": [
        { "name": "balanceAccount", "isMut": true, "isSigner": false },
        { "name": "user",           "isMut": false, "isSigner": true }
      ],
      "args": [{ "name": "amount", "type": "u64" }]
    }
  ]
}

Клиент TypeScript читает этот IDL и предоставляет вам полностью типизированные вызовы методов (program.methods.initialize() и program.methods.deposit(amount)) без необходимости ручного написания интерфейсов. Ваши навыки работы с TypeScript здесь применимы напрямую.

Макросы Anchor: как Anchor устраняет шаблонный код

Anchor предоставляет набор макросов Rust — генераторов кода, которые пишут повторяющуюся логику валидации за вас. Макрос в Rust — это аннотация, которая разворачивается в код во время компиляции. Макросы Anchor генерируют код валидации аккаунтов, сериализации и обработки ошибок, который в противном случае вы бы писали вручную.

Три макроса составляют ядро каждой программы Anchor:

#[program] помечает модуль, содержащий функции-обработчики ваших инструкций. Anchor рассматривает каждую публичную функцию в этом модуле как вызываемую инструкцию.

#[derive(Accounts)] генерирует код валидации аккаунтов на основе определения структуры Rust. Вы объявляете, какие аккаунты нужны инструкции, а Anchor автоматически генерирует код для проверки владения и изменяемости, а также типа каждого аккаунта.

#[account] помечает структуру как тип данных аккаунта, управляемого Anchor, и добавляет 8-байтовый дискриминатор, который позволяет Anchor отличать ваш тип аккаунта от других.

Вот как эти макросы выглядят в контексте:

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,           // Anchor создает этот аккаунт (проверяет, что он не существует)
        payer = user,   // Аккаунт 'user' финансирует депозит для освобождения от аренды (rent-exemption)
        space = 8 + 8   // 8-байтовый дискриминатор + 8 байт для поля u64 total
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]          // Объявляет, что баланс лампортов этого аккаунта изменится
    pub user: Signer<'info>, // Тип Signer: Anchor проверяет, что этот аккаунт подписал транзакцию

    pub system_program: Program<'info, System>,
}

Ограничения аккаунтов: как Anchor автоматически проверяет аккаунты

Каждый атрибут внутри #[account(...)] является ограничением Anchor. Ограничения — это правила валидации, которые выполняются автоматически перед выполнением логики вашей инструкции. Это основная причина, по которой программы Anchor требуют гораздо меньше кода ручной валидации, чем программы на чистом Rust.

Наиболее распространенные ограничения:

#[derive(Accounts)]
pub struct ExampleAccounts<'info> {
    #[account(init, payer = user, space = 8 + 8)]
    // init: создает аккаунт; возвращает ошибку, если он уже существует
    pub new_account: Account<'info, MyData>,

    #[account(mut)]
    // mut: объявляет, что данные этого аккаунта или его баланс лампортов изменятся
    pub existing_account: Account<'info, MyData>,

    #[account(seeds = [b"vault", user.key().as_ref()], bump)]
    // seeds + bump: вычисляет адрес PDA и проверяет канонический bump
    pub pda_account: Account<'info, VaultData>,

    #[account(constraint = user_account.authority == user.key())]
    // constraint: вычисляет логическое выражение; завершается ошибкой, если оно ложно
    pub user_account: Account<'info, UserData>,

    pub user: Signer<'info>,
    // Signer: проверяет, что аккаунт подписал транзакцию
}

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

Программно-производные адреса (PDA): детерминированное ончейн-хранилище

Программно-производный адрес (Program Derived Address, PDA) — одна из самых сложных концепций в разработке на Solana. Приготовьтесь прочитать этот раздел дважды. PDA открывают один из самых мощных паттернов Solana, и Anchor делает их гораздо более управляемыми, чем чистый Rust.

PDA — это адрес аккаунта, полученный детерминированным путем из набора «семян» (seeds) и идентификатора программы (program ID). В отличие от обычного адреса кошелька, у PDA нет соответствующего приватного ключа. Ни один отдельный пользователь не может подписаться за PDA. Только владеющая программа может авторизовать транзакции с его участием.

Думайте о PDA как о сейфе, который может открыть только банк (программа). Ни у одного клиента нет ключа; банк контролирует доступ программно. Это делает PDA идеальными для хранилищ, контролируемых программой, эскроу-аккаунтов и хранилищ, специфичных для пользователя, где полномочия должна иметь программа, а не пользователь.

В чистом Rust получение PDA требует вызова Pubkey::find_program_address(&seeds, &program_id) и ручной проверки результата. Anchor справляется с этим с помощью ограничения seeds:

#[derive(Accounts)]
pub struct CreateVault<'info> {
    #[account(
        init,
        payer = authority,
        space = 8 + 32,
        seeds = [b"vault", authority.key().as_ref()], // Семена определяют адрес PDA
        bump                 // Anchor находит и сохраняет канонический seed bump-а
    )]
    pub vault: Account<'info, Vault>,   // PDA аккаунт, нет приватного ключа

    #[account(mut)]
    pub authority: Signer<'info>,

    pub system_program: Program<'info, System>,
}

Ограничение seeds указывает Anchor, как вычислять адрес PDA. Поле bump хранит канонический bump seed — небольшое целое число, которое гарантирует, что производный адрес находится вне эллиптической кривой и не имеет приватного ключа. В Anchor v0.29.x канонический bump вычисляется и проверяется автоматически.

Адреса PDA детерминированы: при использовании одних и тех же сидов (seeds) и ID программы они всегда выдают один и тот же адрес. Это свойство позволяет клиентам вычислять адрес PDA офчейн для получения данных, в то время как программа контролирует права на запись.

Cross-Program Invocation (CPI): Как программы взаимодействуют друг с другом

Cross-Program Invocation (CPI) — это механизм Solana, позволяющий одной программе вызывать инструкции другой. Это ончейн-эквивалент вызова функции из общей библиотеки. CPI обеспечивает компонуемость: ваш протокол DeFi может вызывать программу SPL Token для перевода токенов, ваш контракт управления может вызывать программу стейкинга и так далее.

Solana Program Library (SPL) — это эквивалент стандартной библиотеки для ончейн-программ в Solana. SPL Token для Solana — это то же самое, что ERC-20 для Ethereum, но реализованный как общая ончейн-программа, а не как шаблон контракта, который каждый проект развертывает независимо. Когда вашей программе на Anchor нужно выпустить (минтить) или перевести токены, она вызывает SPL Token через CPI.

Anchor упрощает вызовы CPI с помощью крейта anchor-spl и CpiContext:

use anchor_spl::token::{self, Transfer, Token};

pub fn withdraw(ctx: Context<Withdraw>, amount: u64) -> Result<()> {
    let cpi_accounts = Transfer {
        from: ctx.accounts.vault_token_account.to_account_info(), // Аккаунт токена-источника
        to: ctx.accounts.user_token_account.to_account_info(),   // Аккаунт токена-получателя
        authority: ctx.accounts.vault.to_account_info(),         // PDA подписывает транзакцию для хранилища
    };
    let cpi_ctx = CpiContext::new(ctx.accounts.token_program.to_account_info(), cpi_accounts);
    token::transfer(cpi_ctx, amount)?;  // Вызывает инструкцию перевода SPL Token
    Ok(())
}

Без Anchor сборка информации об аккаунтах, создание инструкции и вызов invoke_signed занимают около 30 строк. Помощники CPI в Anchor сокращают это до типизированного, читаемого вызова функции.

Вы примените эти концепции на практике в пошаговом руководстве по программе.

Предварительные условия: Что нужно перед установкой Anchor Framework

Для разработки с использованием Anchor Framework на Solana требуются четыре инструмента.

Необходимые инструменты:

1. Rust и Cargo (через rustup), рекомендуется версия 1.70.0 или новее.
2. Solana CLI (v1.18.x или новее) — официальный инструмент командной строки для взаимодействия с сетью Solana; отвечает за управление кошельками, запросы эйрдропов и конфигурацию кластеров.
3. Node.js (v18 или новее) плюс Yarn или npm — необходимы для клиента на TypeScript и тестов Anchor.
4. Anchor Version Manager (avm) — устанавливает и управляет версиями Anchor CLI; всегда устанавливайте Anchor через avm, а не напрямую через Cargo.

О Rust: Программы на Anchor пишутся на Rust. Rust обязателен, обойти это невозможно. Тем не менее, макросы Anchor абстрагируют самые сложные паттерны Rust: валидацию и сериализацию аккаунтов, а также распространение ошибок. Вам не нужно глубокое владение Rust, чтобы создать свою первую программу.

Что нужно для начала: понимание структур, функций, основ владения (ownership) и ограничений типажей (trait bounds) на поверхностном уровне. Что можно отложить на потом: время жизни (lifetimes), асинхронный Rust и тонкости проверки заимствований (borrow checker). Ваши навыки TypeScript или JavaScript пригодятся для написания клиентского кода. Тесты, взаимодействие с фронтендом и вызовы клиента на основе IDL — всё это использует TypeScript. Вам не нужно быть экспертом в Rust, чтобы строить на Anchor, так же как не нужно быть экспертом в Ruby для разработки на Ruby on Rails. Но вы будете сталкиваться с Rust, и базовое знакомство с ним поможет.

Если вас интересует, как Anchor абстрагирует паттерны Rust, подробно об этом читайте в разделе основных компонентов.

О Solana CLI и Anchor CLI: Это два отдельных инструмента с разными задачами. solana CLI отвечает за взаимодействие с сетью: проверку балансов, запрос эйрдропов и переключение между devnet и мейннетом. anchor CLI управляет жизненным циклом вашей программы: инициализацией проектов, сборкой программ, запуском тестов и развертыванием. Необходимы оба инструмента.

Как установить Anchor Framework: Пошаговая настройка

📌 ПРИМЕЧАНИЕ: Все команды ниже проверены для Anchor v0.29.x и Solana CLI v1.18.x по состоянию на 2024 год. После установки выполните anchor --version, чтобы подтвердить версию. Если вы читаете это позже, проверьте текущую версию в GitHub-репозитории Anchor (coral-xyz/anchor).

Шаг 1: Установка Rust через rustup

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
# Следуйте подсказкам на экране и выберите установку по умолчанию
source "$HOME/.cargo/env"
rustc --version
# Должно вывести: rustc 1.70.0 или новее

Шаг 2: Установка Solana CLI

sh -c "$(curl -sSfL https://release.solana.com/stable/install)"
# Следуйте инструкциям по настройке PATH из вывода установщика
solana --version
# Должно вывести: solana-cli 1.18.x или новее

Когда вы развертываете программу Anchor в Solana, она сохраняется ончейн и выполняется узлами-валидаторами сети при каждом вызове транзакции. Solana CLI — это способ взаимодействия с этими валидаторами из вашего терминала.

Шаг 3: Настройка Solana CLI на devnet и создание кошелька

solana config set --url devnet
solana-keygen new
# Создает локальный файл ключевой пары (ваш кошелек для разработки)
# Сохраните путь к файлу. Anchor использует эту пару ключей для подписи деплоев

💡 СОВЕТ: Сохраните путь к файлу вашей ключевой пары. Anchor считывает этот приватный ключ из конфигурации Anchor.toml для подписи транзакций развертывания в devnet.

Шаг 4: Запрос эйрдропа SOL в devnet

solana airdrop 2
solana balance
# Подтвердите, что баланс показывает 2 SOL

Шаг 5: Установка avm (Anchor Version Manager) и Anchor

cargo install --git https://github.com/coral-xyz/avm avm --locked --force
avm install latest
avm use latest
anchor --version
# Должно вывести: anchor-cli 0.29.x

📌 ПРИМЕЧАНИЕ: Всегда устанавливайте Anchor через avm, а не напрямую через cargo install anchor-cli. avm позволяет переключаться между версиями Anchor без переустановки. Это важно, когда проекты привязаны к конкретной версии или когда вы обновляете существующий проект.

Шаг 6: Инициализация вашего первого проекта

anchor init my-first-program
cd my-first-program

Структура вашего проекта после anchor init:

my-first-program/
├── Anchor.toml
├── programs/
│   └── my-first-program/
│       └── src/
│           └── lib.rs
├── tests/
│   └── my-first-program.ts
└── app/

💡 СОВЕТ: Команда anchor init создает шаблон примера программы в lib.rs. Запустите anchor test сразу, чтобы подтвердить работоспособность среды перед написанием собственного кода.

Сборка и развертывание вашей первой программы на Anchor: Полное руководство

В этом разделе мы пройдем путь от пустого проекта до развернутой программы в devnet сети Solana. В качестве примера мы создадим трекер баланса (balance tracker) — программу, которая инициализирует сохраненный баланс в ноль, а затем принимает инструкции по внесению средств (deposit) для его увеличения. Это демонстрирует полный жизненный цикл аккаунта и функционально идентично программе-счетчику, но использует оригинальные имена переменных.

Написание программы трекера баланса

Ваш файл programs/my-first-program/src/lib.rs уже содержит шаблон после anchor init. Замените его содержимое на следующее:

// Программа трекера баланса для Anchor v0.29.x
use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkgHH5WfZCnQ");

#[program]
pub mod balance_tracker {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        ctx.accounts.balance_account.total = 0;  // Начальный баланс равен нулю
        Ok(())
    }

    pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
        ctx.accounts.balance_account.total += amount;  // Увеличение сохраненного баланса
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(
        init,
        payer = user,
        space = 8 + 8   // 8-байтовый дискриминатор Anchor + 8 байт для u64
    )]
    pub balance_account: Account<'info, BalanceAccount>,

    #[account(mut)]
    pub user: Signer<'info>,

    pub system_program: Program<'info, System>,
}

#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,
}

#[account]
pub struct BalanceAccount {
    pub total: u64,
}

Прежде чем двигаться дальше, важно разобрать три паттерна в этом коде. Во-первых, #[derive(Accounts)] полностью генерирует логику валидации аккаунта. Anchor считывает определение вашей структуры и прописывает проверки владения, проверки мутабельности и верификацию подписанта. Вы объявляете намерение — Anchor обеспечивает его соблюдение. Во-вторых, space = 8 + 8 выделяет ровно столько байтов, сколько нужно аккаунту: 8 байт для дискриминатора Anchor (уникальный тег, который идентифицирует тип аккаунта и предотвращает атаки с подменой типов) плюс 8 байт для общей суммы типа u64. В-третьих, Signer<'info> — это встроенный тип Anchor, который проверяет, что аккаунт подписал транзакцию. Без него любой аккаунт мог бы вызвать вашу инструкцию депозита.

Тестирование вашей программы с Mocha и TypeScript

Mocha — это среда выполнения тестов JavaScript; Chai предоставляет синтаксис утверждений. Оба инструмента предустановлены при выполнении команды anchor init. Откройте файл tests/my-first-program.ts и замените его содержимое:

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { MyFirstProgram } from "../target/types/my_first_program";
import { assert } from "chai";

describe("balance-tracker", () => {
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  const program = anchor.workspace.MyFirstProgram as Program<MyFirstProgram>;
  const balanceAccount = anchor.web3.Keypair.generate();

  it("Initializes a balance account with total = 0", async () => {
    await program.methods
      .initialize()
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
        systemProgram: anchor.web3.SystemProgram.programId,
      })
      .signers([balanceAccount])
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 0, "Initial balance should be 0");
  });

  it("Deposits 500 and updates the stored balance", async () => {
    await program.methods
      .deposit(new anchor.BN(500))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: provider.wallet.publicKey,
      })
      .rpc();

    const account = await program.account.balanceAccount.fetch(
      balanceAccount.publicKey
    );
    assert.equal(account.total.toNumber(), 500, "Balance should be 500 after deposit");
  });
});

npm-пакет @coral-xyz/anchor — это клиентская библиотека TypeScript для Anchor. Тип Program<MyFirstProgram> был сгенерирован автоматически из IDL во время запуска anchor build. В этом заключается практическая ценность IDL: ваш код на TypeScript получает полную типобезопасность интерфейса программы на Rust без необходимости писать интерфейс вручную.

Эта программа также является бэкендом для dApp. Клиент на TypeScript, показанный выше, — это то, как его будет вызывать фронтенд-приложение. Добавьте интерфейс React или Next.js поверх этих вызовов методов, и вы получите полноценное децентрализованное приложение, работающее на Solana.

Сборка и развертывание в Devnet

Выполните эти три команды последовательно из корневой директории вашего проекта:

anchor build
# Результат: target/deploy/my_first_program.so, target/idl/my_first_program.json, target/types/my_first_program.ts

anchor test
# Запускает локальный валидатор, развертывает программу, выполняет тесты Mocha, завершает работу

anchor deploy --provider.cluster devnet
# Вывод включает ваш Program Id: ABC123...xyz789

💡 СОВЕТ: Скопируйте ваш Program ID из вывода команды deploy. Обновите значение declare_id!("...") в lib.rs этим идентификатором, затем снова запустите anchor build, чтобы встроить правильный адрес в скомпилированную программу. Также обновите раздел [programs.devnet] в файле Anchor.toml.

📌 ПРИМЕЧАНИЕ: Вы развертываете программу в devnet, тестовой сети Solana. Это не стоит реальных SOL. Ваш эйрдроп в devnet из раздела настройки покроет комиссию за развертывание.

Теперь вы написали и протестировали программу Solana, а затем развернули ее с помощью фреймворка Anchor. Программа находится в devnet по вашему Program ID и выполняется каждый раз, когда транзакция вызывает ее.

Тестирование программ Anchor: рабочий процесс anchor test

anchor test — это одна команда, которая запускает локальный валидатор Solana, развертывает на нем вашу программу, запускает полный набор тестов Mocha и выключает валидатор по завершении. Вам не нужно управлять валидатором вручную.

Последовательность рабочего процесса тестирования:

1. anchor test считывает конфигурацию из вашего Anchor.toml.
2. В фоновом режиме запускается процесс локального валидатора.
3. Программа собирается и развертывается на этом валидаторе.
4. Выполняются все тестовые файлы TypeScript в директории tests/ с помощью Mocha.
5. Выводятся результаты прохождения тестов, и валидатор выключается.

Структура тестового файла: каждый тестовый файл импортирует данные из @coral-xyz/anchor, настраивает провайдера (который подключается к локальному валидатору) и ссылается на вашу программу через объект рабочего пространства, сгенерированный IDL. Блоки describe и it — это стандартный синтаксис Mocha.

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

const account = await program.account.balanceAccount.fetch(
  balanceAccount.publicKey
);
assert.equal(account.total.toNumber(), 0);

Тестирование случаев ошибок: проверьте, что недопустимые входные данные приводят к ошибке. Хорошо протестированная программа включает негативные тесты:

it("Rejects deposit from an unsigned account", async () => {
  const badActor = anchor.web3.Keypair.generate();
  try {
    await program.methods
      .deposit(new anchor.BN(100))
      .accounts({
        balanceAccount: balanceAccount.publicKey,
        user: badActor.publicKey,
      })
      .rpc();
    assert.fail("Transaction should have been rejected");
  } catch (err) {
    assert.ok(err, "Anchor rejected the unsigned transaction");
  }
});

Localnet против devnet: используйте anchor test (localnet) для всей активной разработки. Localnet работает мгновенно, бесплатно и сбрасывается между запусками. Развертывайте в devnet только тогда, когда хотите поделиться постоянным URL-адресом или протестировать работу в реальных сетевых условиях.

Mocha — это среда для запуска тестов (структура блоков describe и it). Chai предоставляет синтаксис утверждений (assert.equal, assert.ok, expect). Оба инструмента предварительно настроены в каждом проекте anchor init и не требуют отдельной установки.

Anchor против альтернатив: выбор пути разработки на Solana

Существует три пути разработки на Solana: фреймворк Anchor, нативный Rust без фреймворка и Seahorse. Сама Solana — это один из нескольких блокчейнов, которые стоит рассмотреть для вашего проекта. В таблицах ниже представлены основные различия без какой-либо агитации.

Таблица 1: Подходы к разработке на Solana

Таблица 2: Инструментарий Solana vs. Ethereum

Когда выбирать Anchor вместо нативного Rust: Для многих сценариев разработки приложений на Solana, включая DeFi протоколы, NFT платформы, системы токен-гейтинга, DAO и ончейн-игры, Anchor является стандартной отправной точкой. Сокращение объема шаблонного кода существенно: программа, требующая 300 строк на «чистом» Rust, может занять 80 строк с Anchor. Разработка на нативном Rust оправдана, когда программе требуется точный контроль над потреблением вычислительных единиц (CU), когда абстракции Anchor конфликтуют с необычной архитектурой или когда команда обладает глубокой экспертизой в Rust и нуждается в максимальной гибкости.

Фреймворк Seahorse: Seahorse позволяет разработчикам писать программы для Solana на Python, который затем под капотом компилируется в Anchor-совместимый Rust. Это снижает языковой барьер для Python-разработчиков, которые хотят поэкспериментировать с Solana без изучения Rust. Обратной стороной является зрелость: Seahorse — это проект сообщества с гораздо меньшей базой пользователей, чем у Anchor, и по состоянию на 2024 год он не рекомендуется для продакшен-приложений. Для прототипирования это разумный вариант; для продакшена Anchor остается стандартом де-факто.

Ethereum против Solana: Ethereum предлагает крупнейшую экосистему разработчиков смарт-контрактов, самую глубокую историю аудитов безопасности и широчайшую поддержку инструментов. Solana предлагает существенно более высокую пропускную способность и более низкие комиссии, что делает ее более подходящей для приложений, где частота транзакций и стоимость являются основными ограничениями. Эти платформы подходят для разных профилей приложений. Разработчики, создающие инфраструктуру для высокочастотной торговли или игры с микротранзакциями, могут предпочесть Solana; разработчики систем управления или стандартов токенов, нуждающиеся в максимальной совместимости с экосистемой, могут выбрать Ethereum. Для большинства продакшен-приложений на Solana Anchor является обычной отправной точкой, что подтверждается выбором таких крупных протоколов, как Raydium, Marinade Finance и Metaplex, выбравших Anchor в качестве своей основы.

Безопасность фреймворка Anchor: Пять уязвимостей, которые должен знать каждый разработчик Solana

⚠️ ВНИМАНИЕ: Уязвимости в безопасности программ Solana могут привести к безвозвратной, необратимой потере средств пользователей. Перед развертыванием любой программы в мейннет пропустите ее через инструмент статического анализа, такой как Soteria, и рассмотрите возможность проведения профессионального аудита безопасности. В экосистеме Solana случались серьезные эксплойты именно из-за описанных ниже уязвимостей. Проверка безопасности не является опциональной для рабочих программ. Для более глубокого изучения обратитесь к официальной документации Anchor.

Система ограничений Anchor (атрибуты #[account(...)] в ваших структурах аккаунтов) — это ваша первая линия обороны. Она автоматически применяет проверки владения, права на изменение и верификацию типов, которые в противном случае вам пришлось бы писать вручную на нативном Rust. Но ограничения защищают только то, что вы декларируете. Приведенные ниже уязвимости возникают из-за того, что разработчики забывают декларировать.

Отсутствие проверки подписи (Signer Check)

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

// УЯЗВИМО: AccountInfo не проверяет, подписал ли вызывающий транзакцию
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: AccountInfo<'info>,  // Нет верификации подписи
}

// БЕЗОПАСНО: Signer<'info> прерывает транзакцию, если аккаунт не подписал ее
#[derive(Accounts)]
pub struct Deposit<'info> {
    #[account(mut)]
    pub balance_account: Account<'info, BalanceAccount>,
    pub user: Signer<'info>,  // Транзакция откатывается, если пользователь не подписал
}

Используйте Signer<'info> для любого аккаунта, который должен авторизовать инструкцию.

Отсутствие проверки владения (подмена аккаунта)

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

// УЯЗВИМО: AccountInfo не проверяет программу-владельца аккаунта
pub balance_account: AccountInfo<'info>,  // Принимает любой аккаунт

// БЕЗОПАСНО: Account<'info, T> проверяет, что аккаунт принадлежит вашей программе
pub balance_account: Account<'info, BalanceAccount>,  // Проверка владения автоматическая

Всегда используйте типизированную обертку Anchor Account<'info, T> вместо чистого AccountInfo<'info> для аккаунтов, содержащих данные, контролируемые программой.

Атака через повторную инициализацию (Reinitialization Attack)

Если инструкция initialize может быть запущена более одного раза для одного и того же аккаунта, злоумышленник может сбросить состояние, которое должно быть постоянным.

// УЯЗВИМО: init_if_needed молча принимает уже инициализированные аккаунты
#[account(init_if_needed, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

// БЕЗОПАСНО: init откатывается, если аккаунт уже существует
#[account(init, payer = user, space = 8 + 8)]
pub balance_account: Account<'info, BalanceAccount>,

Используйте init (а не init_if_needed) для аккаунтов, которые должны создаваться только один раз. Если init_if_needed действительно необходим, добавьте явный флаг инициализации и проверяйте его в логике инструкции.

Переполнение и антипереполнение целых чисел

Арифметика Rust вызывает панику при переполнении в отладочных (debug) сборках, но в релизных сборках происходит циклическое переполнение без уведомления, что может повредить финансовый баланс без вызова ошибки.

// УЯЗВИМО: прямая арифметика циклически переполняется в релизном режиме
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
    ctx.accounts.balance_account.total += amount;
    Ok(())
}

// БЕЗОПАСНО: checked_add возвращает Err вместо переполнения
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
    ctx.accounts.balance_account.total = ctx.accounts.balance_account.total
        .checked_add(amount)
        .ok_or(error!(ErrorCode::Overflow))?;
    Ok(())
}

Используйте checked_add, checked_sub и checked_mul для всех арифметических операций с финансовыми значениями. Определите пользовательское перечисление ErrorCode с вариантом Overflow для понятных сообщений об ошибках.

Канонизация бампа PDA (PDA Bump Canonicalization)

Использование неканонического семени (seed) бампа может привести к созданию валидного, но неожиданного адреса PDA, что делает возможными атаки с подменой адреса.

// УЯЗВИМО: ручной расчет bump не гарантирует каноничность
#[account(seeds = [b"vault", user.key().as_ref()], bump = ctx.accounts.vault.bump)]
pub vault: Account<'info, Vault>,

// БЕЗОПАСНО: опустите явное значение bump. Anchor v0.29.x вычисляет и проверяет
// канонический bump автоматически
#[account(
    seeds = [b"vault", user.key().as_ref()],
    bump,
)]
pub vault: Account<'info, Vault>,

В Anchor v0.29.x опускайте явное значение bump и позволяйте Anchor самостоятельно вычислять канонический bump. Если вы сохраняете bump в данных аккаунта, заполняйте его во время init, используя ctx.bumps.vault.

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

Устранение распространенных ошибок Anchor

Ниже приведены наиболее распространенные проблемы, с которыми сталкиваются разработчики при создании программ на базе Anchor Framework. Каждая запись включает точное сообщение об ошибке, причину и способ исправления.

📌 ПРИМЕЧАНИЕ: Несоответствие версий является причиной большинства сбоев anchor build. Сначала проверьте эту таблицу, прежде чем искать другие причины.

Ошибка 1: AccountNotInitialized

AnchorError caused by account: balance_account.
Error Code: AccountNotInitialized.
Error Number: 3012.

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

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

Ошибка 2: Несоответствие типов при anchor build

error[E0308]: mismatched types
expected struct `anchor_lang::prelude::AccountInfo`
found struct `anchor_lang::accounts::signer::Signer`

Причина: Ваш код использует синтаксис ограничений аккаунта из Anchor v0.26.x или более ранних версий, который изменился в v0.29.x.

Исправление: Ознакомьтесь с официальной документацией Anchor по синтаксису ограничений для v0.29.x. Выполните команду avm use 0.29.0, чтобы подтвердить, что версия вашего CLI соответствует зависимости в Cargo.toml.

Ошибка 3: Несовместимость версий CLI Anchor/Solana

Error: RPC response error -32002: Transaction simulation failed

Причина: Ваша версия CLI Anchor и версия CLI Solana несовместимы.

Исправление:

avm use 0.29.0
solana --version     # Убедитесь, что Solana CLI версии 1.18.x или новее

Ошибка 4: Несоответствие declare_id! после повторного развертывания

Error: Program Id mismatch

Причина: Вы выполнили повторное развертывание по новому адресу, но declare_id!() в lib.rs все еще содержит старый ID программы.

Исправление:

anchor keys sync
anchor build

Ошибка 5: Недостаточно средств в Devnet

Error: Transaction simulation failed: insufficient funds

Причина: В вашем кошельке devnet недостаточно SOL для оплаты комиссии за развертывание или транзакцию.

Исправление:

solana airdrop 2
solana balance

Ошибка 6: Размер бинарного файла программы превышает лимит

Error: account data too small for instruction

Причина: Скомпилированный бинарный файл вашей программы превышает лимит размера программ Solana для обновляемых программ.

Исправление: Добавьте оптимизации сборки в ваш Cargo.toml:

[profile.release]
opt-level = "z"
lto = true

Удалите неиспользуемые зависимости и флаги функций из ваших файлов Cargo.toml и Anchor.toml.

Если вы столкнулись с ошибками версий, вернитесь к руководству по установке и убедитесь, что версии ваших инструментов соответствуют таблице совместимости выше.

Anchor Framework и экосистема разработчиков Solana

Anchor Framework обеспечивает работу большинства продакшн-программ, развернутых в мейннете Solana, включая протоколы децентрализованных финансов (DeFi), инфраструктуру NFT и ончейн управление.

Продакшн-протоколы, построенные на Anchor:

• Raydium: автоматизированный маркет-мейкер (AMM) и протокол ликвидности
• Marinade Finance: Протокол ликвидного стейкинга для SOL
• Metaplex: Стандарт NFT, метаданные токенов и набор инструментов
• Drift Protocol: Децентрализованная биржа бессрочных контрактов
• Kamino Finance: Протокол ликвидности и кредитования
• Jito: Стейкинг с учетом MEV и инфраструктура валидаторов

Протоколы DeFi представляют собой доминирующую категорию программ, развернутых с помощью Anchor. Децентрализованные биржи, кредитные платформы и агрегаторы доходности полагаются на пропускную способность Solana (примерно 65 000 транзакций в секунду в оптимальных условиях по состоянию на 2024 год) и низкие комиссии (обычно менее 0,001 доллара США за транзакцию) для своих основных операций. Рост ончейн финансовых инструментов и токенизация активы реального мира на Solana отражает зрелость этой инфраструктуры.

Согласно отчету Electric Capital Developer Report (актуальные цифры доступны на сайте electriccapital.com), активная база разработчиков Solana росла в годовом исчислении в течение 2023 и 2024 годов. Рост популярности среди разработчиков обычно способствует здоровью экосистемы блокчейн, хотя это не следует истолковывать как инвестиционный совет.

SOL служит валютой для оплаты комиссий в сети Solana. Каждая транзакция, вызывающая ончейн программу, стоит небольшое количество SOL (торгуется на крупных биржах криптовалюты, включая Coinbase и Binance). Актуальные рыночные данные по SOL см. на странице текущая цена SOL и рыночные данные на CoinGecko.

Больше разработчиков, использующих Anchor, означает больше развернутых программ, что, в свою очередь, означает более активное использование сети Solana. Эта связь является наблюдением за динамикой экосистемы, а не инвестиционным сигналом.

Часто задаваемые вопросы о Solana Anchor Framework

Какой язык программирования использует Solana?

Программы Solana пишутся на Rust. Среда выполнения также поддерживает C и C++, но Rust является стандартом для промышленной разработки. Для клиентского кода, включая тесты, взаимодействия с фронтендом и скрипты, вызывающие ваши программы, используются TypeScript и JavaScript через npm-пакет @coral-xyz/anchor. Anchor Framework охватывает оба уровня: Rust для логики программ и TypeScript для всего, что с ней взаимодействует.

Обязателен ли Rust для использования Anchor Framework?

Да. Программы Anchor пишутся на Rust, и обойти это невозможно. Тем не менее, макросы Anchor абстрагируют наиболее трудоемкие части разработки на Solana: валидацию аккаунтов и распространение ошибок. Разработчик с базовыми знаниями Rust (структуры, функции, типажи, базовое владение данными) может создать и развернуть рабочую программу на Anchor. Глубокие знания Rust в области времени жизни (lifetimes), паттернов async и продвинутых дженериков не требуются для начала работы. Ваши навыки TypeScript или JavaScript применимы непосредственно на клиентской стороне любого проекта Anchor.

Что такое программно-производный адрес (PDA) простыми словами?

Программно-производный адрес (PDA) — это адрес аккаунта, который контролируется программой, а не пользователем с приватный ключ. Поскольку у PDA нет приватного ключа, только владеющая им программа может авторизовать транзакции с его участием. При одних и тех же семенах (seeds) и ID программы PDA всегда разрешается в один и тот же адрес, что позволяет клиентам находить контролируемые программой аккаунты без необходимости хранить их адреса отдельно. Anchor обрабатывает генерацию PDA автоматически через ограничение seeds в структурах ваших аккаунтов. PDA обычно используются для хранилищ под управлением программ, эскроу-аккаунтов и хранения данных по каждому пользователю.

Можно ли создавать NFT с помощью Anchor Framework?

Да. Большая часть инфраструктуры NFT на Solana построена на Anchor. Стандарт Metaplex, который определяет метаданные токенов, структуру коллекций и роялти для NFT на Solana, сам по себе является программой на базе Anchor. Любая платформа NFT на Solana взаимодействует с программами Metaplex через Cross-Program Invocation (CPI), используя крейт anchor-spl, который предоставляет типобезопасные обертки для инструкций SPL Token.

Активно ли поддерживается Anchor Framework?

Да. Anchor поддерживается Coral XYZ и является стандартом де-факто для разработки программ на Solana по состоянию на 2024 год. Текущая стабильная версия — v0.29.x. Репозиторий Anchor на GitHub (coral-xyz/anchor) получает регулярные обновления, соответствующие обновлениям среды выполнения Solana. Крупные рабочие протоколы, включая Raydium, Marinade Finance и Metaplex, продолжают строиться на Anchor, подтверждая его готовность к эксплуатации.

Как Anchor соотносится с Hardhat от Ethereum?

Anchor и Hardhat выполняют аналогичные роли в своих блокчейнах: оба обеспечивают структуру проекта, среду тестирования и инструменты развертывания. Различия начинаются с базовой архитектуры. Hardhat ориентирован на модель контрактов Ethereum с состоянием, где смарт-контракт содержит как свою логику, так и свое состояние. Anchor ориентирован на безгосударственную модель программ Solana, где программы и данные живут в разных аккаунтах. Языки также различаются: проекты Hardhat используют Solidity для контрактов и JavaScript или TypeScript для тестов; проекты Anchor используют Rust для программ и TypeScript для тестов. Стоимость транзакций также существенно различается: транзакции в Solana обычно стоят менее 0,001 $, в то время как комиссии за газ в Ethereum варьируются и могут достигать от 1 $ до 50 $ и более за транзакцию. Полное сравнение представлено в таблицах сравнения Anchor с альтернативами.

Сколько времени занимает изучение Anchor Framework?

Разработчик с опытом работы в TypeScript или JavaScript и без предварительных знаний Rust обычно может создать и развернуть базовую программу Anchor в devnet в течение одного-двух дней, используя структурированное руководство. Переход от базовой программы к рабочему DeFi протоколу занимает от нескольких недель до нескольких месяцев, в зависимости от сложности программы и глубины знаний Rust. Кривая обучения Rust является основной переменной. Разработчики, инвестирующие время в основы Rust параллельно с Anchor, видят более быстрый прогресс в нетривиальных программах.

Что такое Библиотека программ Solana (SPL)?

Библиотека программ Solana (SPL) — это коллекция предварительно развернутых, проверенных программ на Solana для общих операций. Программа SPL Token является эквивалентом стандарта ERC-20 в Solana, реализованная как общая ончейн программа, а не как шаблон контракта, который каждый проект развертывает независимо. Anchor интегрируется с SPL через крейт anchor-spl, который предоставляет типобезопасные оболочки для инструкций SPL Token, включая transfer, mint_to и burn. SPL также является основой для метаданных токенов NFT через программу Metaplex.

Что такое Proof of History (PoH) в Solana?

Proof of History (PoH) — это криптографический механизм учета времени, который Solana использует для упорядочивания транзакций перед тем, как они попадут к валидаторам для консенсуса. Вместо того чтобы требовать от валидаторов взаимодействия для согласования порядка транзакций, PoH встраивает проверяемую последовательность временных меток непосредственно в блокчейн. Это снижает накладные расходы на координацию традиционных протоколов консенсуса и является одной из причин, по которой Solana достигает примерно 65 000 транзакций в секунду в оптимальных условиях по состоянию на 2024 год.

Хороша ли Solana для разработки смарт-контрактов?

Solana хорошо подходит для приложений, где пропускная способность транзакций и стоимость являются основными ограничениями: высокочастотные DeFi протоколы, NFT маркетплейсы с большим количеством мелких транзакций и ончейн игры. Ее модель аккаунтов требует больше предварительного обучения, чем Ethereum, но Anchor Framework значительно снижает это трение. Является ли Solana правильным выбором, зависит от профиля вашего приложения. Ethereum предлагает более крупную экосистему и более устоявшуюся историю аудитов безопасности, в то время как Solana предлагает более низкие комиссии и более высокую пропускную способность для сценариев использования, которым выгодно и то, и другое.

Заключение: подходит ли Anchor Framework для вашего проекта на Solana?

Для многих рабочих процессов разработки приложений на Solana Anchor Framework является обычной отправной точкой, в то время как нативный Rust остается актуальным, когда требуется контроль более низкого уровня.

Anchor существенно сокращает объем шаблонного кода при разработке на чистом Rust. Программы, которые на нативном коде Solana требуют сотен строк, занимают лишь малую часть этого объема благодаря системе макросов Anchor. Он обеспечивает безопасность аккаунтов через систему ограничений, отлавливая ошибки владения и авторизации на этапе компиляции или выполнения, а не в рабочей среде. И он автоматически генерирует клиент TypeScript из IDL, предоставляя разработчикам JavaScript типизированный, знакомый интерфейс для их программ без написания кода на Rust на стороне клиента.

Разработку на нативном Rust стоит рассматривать только тогда, когда вашей программе требуется точный контроль над потреблением вычислительных единиц (CU) или когда абстракции Anchor действительно вступают в конфликт с необычной архитектурой. Для подавляющего большинства программ, включая DeFi протоколы, NFT платформы, DAO и системы токен-гейтинга, Anchor — это то, с чего следует начать.

Следующие шаги:

1. Разверните программу отслеживания баланса из этого руководства в devnet с помощью anchor deploy --provider.cluster devnet.
2. Изучите официальную документацию Anchor на anchor-lang.com для получения полной справочной информации по API и расширенным функциям.
3. Просмотрите репозиторий примеров Anchor на GitHub для ознакомления с программами по производственным шаблонам.
4. Присоединяйтесь к Anchor Discord или Solana Stack Exchange для поддержки сообщества при возникновении проблем.

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

Связанные технические руководства по Solana

• Адреса контрактов Solana и Program ID
• Стандарты токенов Solana
• Токены Solana SPL

Разработчики, отслеживающие SOL наряду с инструментами экосистемы, могут обращаться к странице цены SOL) в качестве отдельного рыночного ориентира; она не подтверждает безопасность программы или готовность к развертыванию.