Посібник з 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. Ви можете знайти вихідний код та релізи на GitHub-репозиторії Anchor (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 Framework: 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/your_program_name.json після anchor build. Разом із ним Anchor генерує target/types/your_program_name.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' фінансує депозит для звільнення від оренди
        space = 8 + 8   // 8-байтовий дискримінатор + 8 байтів для поля total типу u64
    )]
    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: обчислює логічний вираз; завершується помилкою, якщо false
    pub user_account: Account<'info, UserData>,

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

Без обмежень вам довелося б писати кожну з цих перевірок вручну в тілі вашої інструкції. З обмеженнями Anchor забезпечує їх виконання до запуску логіки вашої інструкції. Це як підвищення продуктивності, так і функція безпеки, оскільки обмеження важче забути, ніж ручні перевірки, сховані в коді інструкції.

Програмно виведені адреси (PDA): детерміноване ончейн-зберігання

Програмно виведена адреса (PDA) — одна з найскладніших концепцій у розробці на Solana. Плануйте прочитати цей розділ двічі. PDA відкривають доступ до одного з найпотужніших паттернів Solana, а Anchor робить роботу з ними набагато простішою, ніж чистий Rust.

PDA — це адреса акаунта, детерміновано виведена з набору зерен (seeds) та 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 знаходить і зберігає зерно канонічного бампа
    )]
    pub vault: Account<'info, Vault>,   // Акаунт PDA, приватний ключ відсутній

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

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

Обмеження seeds вказує Anchor, як отримати адресу PDA. Поле bump зберігає канонічне значення "bump" — невелике ціле число, яке гарантує, що виведена адреса випадає з еліптичної кривої та не має приватного ключа. У Anchor v0.29.x канонічне значення "bump" виводиться та перевіряється автоматично.

PDA є детермінованими: за однакових seeds та ID програми вони завжди генерують однакову адресу. Ця властивість дозволяє клієнтам обчислювати адресу PDA офчейн для отримання даних, тоді як програма контролює доступ на запис.

Виклик між програмами (CPI): Як програми спілкуються одна з одною

Виклик між програмами (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 скорочують це до типізованого, читабельного виклику функції.

Ви застосуєте ці концепції на практиці в [покроковому посібнику з програмування](#building-and-deploying-your-first-anchor-program-a-complete-walkthrough).

---

## Передумови: Що вам потрібно перед встановленням фреймворку Anchor

Чотири інструменти потрібні перед тим, як ви зможете створювати програми за допомогою фреймворку Anchor на 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, щоб створити свою першу програму.

Що вам потрібно для початку: структури, функції, базове володіння та обмеження трейтів на поверхневому рівні. Що ви можете відкласти на потім: час життя, асинхронний Rust та тонкощі перевірки запозичень. Ваші навички TypeScript або JavaScript застосовуються безпосередньо до клієнтського коду Anchor. Тести, взаємодії з фронтендом та виклики клієнта, згенеровані IDL, — все це використовує TypeScript. Вам не потрібно бути експертом з Rust, щоб створювати за допомогою Anchor, так само як вам не потрібно бути експертом з Ruby, щоб створювати за допомогою Ruby on Rails. Але ви зіткнетеся з Rust, і базова знайомість допоможе.

Якщо абстрагування Rust-шаблонів від Anchor вас зацікавило, [розділ основних компонентів детально пояснює, що Anchor абстрагує від Rust](#core-components-of-the-solana-anchor-framework-idl-macros-pdas-and-cpi).

**Про Solana CLI проти Anchor CLI:** Це два окремі інструменти з різними обов'язками. `solana` CLI відповідає за взаємодію з мережею: перевірку балансів, запити на ейрдропи та перемикання між devnet та mainnet. `anchor` CLI відповідає за життєвий цикл вашої програми: ініціалізацію проєктів, компіляцію програм, запуск тестів та розгортання. Обидва є обов'язковими.

---

## Як встановити фреймворк Anchor: Покрокове налаштування

📌 **ПРИМІТКА:** Усі наведені нижче команди перевірені для Anchor v0.29.x та Solana CLI v1.18.x станом на 2024 рік. Запустіть `anchor --version` після встановлення, щоб підтвердити свою версію. Якщо ви читаєте це після публікації, перевірте поточну версію на [репозиторії Anchor на GitHub (coral-xyz/anchor)](https://github.com/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 -sSf 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. Приклад — це трекер балансу: програма, яка ініціалізує збережений Баланс до нуля, а потім приймає інструкції Депозиту для його збільшення. Це демонструє повний життєвий цикл акаунта і є функціонально ідентичним до програми-лічильника, але використовує оригінальні назви змінних.

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

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

// Anchor v0.29.x Balance Tracker Program
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 total. По-третє, 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, "Початковий баланс має бути 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, "Баланс має бути 500 після депозиту");
  });
});

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

Ця програма також є бекендом dApp. Клієнт TypeScript, показаний вище, — це те, як фронтенд-додаток може її викликати. Додайте UI на 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
# Вивід міститиме ваш ідентифікатор програми: ABC123...xyz789

💡 ПОРАДА: Скопіюйте ваш ідентифікатор програми з виводу розгортання. Оновіть значення declare_id!("...") у lib.rs ним, а потім знову запустіть anchor build, щоб вбудувати правильну адресу у скомпільовану програму. Також оновіть розділ [programs.devnet] у Anchor.toml.

📌 ПРИМІТКА: Ви розгортаєте на devnet, тестовій мережі Solana. Це не коштує справжніх SOL. Ваш ейрдроп для devnet з розділу налаштування покриє плату за розгортання.

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

Тестування програм 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 Framework, нативний Rust без фреймворку та Seahorse. Сам Solana є одним із кількох блокчейнів, які варто оцінити для вашого проекту. Таблиці нижче представляють ключові відмінності без упередженості.

Таблиця 1: Підходи до розробки Solana

Таблиця 2: Інструментарій Solana проти Ethereum

Коли вибирати Anchor замість нативного Rust: Для багатьох випадків розробки додатків Solana, включаючи DeFi протоколи, NFT платформи, системи обмеження доступу за токенами, DAO та ончейн-ігри, Anchor є типовою відправною точкою. Скорочення шаблонного коду є суттєвим: програма, яка вимагає 300 рядків у чистому Rust, може зайняти 80 рядків з Anchor. Розробка на нативному Rust має сенс, коли програма вимагає точного контролю над споживанням одиниць обчислень, коли абстракції Anchor конфліктують з незвичною архітектурою, або коли команда має глибокі знання Rust і потребує максимальної гнучкості.

Фреймворк Seahorse: Seahorse дозволяє розробникам писати програми Solana на Python, які Seahorse потім компілює до сумісного з 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. Але обмеження захищають лише те, що ви оголошуєте. Вразливості нижче виникають через те, що розробники забувають оголосити.

Відсутність перевірки підписувача

Будь-який обліковий запис може ініціювати вашу інструкцію, якщо від нього не вимагається підписати транзакцію. Це дозволяє будь-якому гаманцю викликати інструкції, які повинні бути обмежені.

// ВРАЗЛИВО: 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> для облікових записів, що містять дані, керовані програмою.

Атака повторної ініціалізації

Якщо інструкція 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 викликають паніку при переповненні в режимі налагодження, але мовчки циклічно переносяться в режимі релізу, що може пошкодити фінансові баланси без виникнення помилки.

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

// БЕЗПЕЧНО: checked_add повертає Err замість циклічного перенесення при переповненні
pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<() liittyvien> {
    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, що дозволяє атаки підробки адрес.

// ВРАЗЛИВО: ручний бамп не гарантовано є канонічним
#[account(seeds = [b"vault", user.key().as_ref()], bump = ctx.accounts.vault.bump)]
pub vault: Account<'info, Vault>,

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

В Anchor v0.29.x пропустіть явне значення бампа і дозвольте Anchor вивести канонічний бамп самостійно. Якщо ви зберігаєте бамп у даних акаунта, заповнюйте його під час 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: Type Mismatch під час 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: Несумісність версій Anchor/Solana CLI

Error: RPC response error -32002: Transaction simulation failed

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

Виправлення:

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

Видаліть невикористовувані залежності та прапорці функцій (feature flags) зі своїх 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 абстрагують найбільш інтенсивні для Rust частини розробки на Solana: валідацію акаунтів та поширення помилок. Розробник з базовим знанням Rust (структури, функції, трейти, основи володіння) може побудувати та розгорнути робочу програму Anchor. Глибокі знання Rust у питаннях життєвих циклів (lifetimes), асинхронних патернів та просунутих узагальнень (generics) не є обов'язковими для старту. Ваші навички TypeScript або JavaScript будуть застосовані безпосередньо на клієнтській стороні кожного проєкту Anchor.

Що таке Program Derived Address (PDA) простими словами?

Program Derived Address (PDA) — це адреса акаунта, якою керує програма, а не користувач із приватним ключем. Оскільки PDA не мають приватного ключа, лише програма-власник може авторизувати транзакції за їх участю. За однакових сідів (seeds) та ID програми, PDA завжди приводить до тієї самої адреси, що дозволяє клієнтам знаходити підконтрольні програмі акаунти без окремого зберігання їхніх адрес. Anchor автоматично обробляє виведення PDA через обмеження seeds у ваших структурах акаунтів. PDA зазвичай використовуються для підконтрольних програмі сховищ (vaults), ескроу-акаунтів та зберігання даних окремих користувачів.

Чи можна створювати NFT за допомогою Anchor Framework?

Так. Більша частина інфраструктури NFT на Solana побудована на Anchor. Стандарт Metaplex, який визначає метадані токенів, структуру колекцій та роялті для Solana NFTs, сам по собі є програмою на базі 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 Program Library (SPL)?

Solana Program Library (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 варто розглядати лише тоді, коли ваша програма вимагає точного контролю над споживанням одиниць обчислень або коли абстракції Anchor дійсно конфліктують з незвичною архітектурою. Для переважної більшості програм, включаючи протоколи DeFi, платформи NFT, DAO та системи обмеженого доступу за токенами, Anchor — це те, з чого варто почати.

Наступні кроки:

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

Програма, яку ви розгорнули в цьому посібнику, справжня: вона існує на devnet Solana, приймає транзакції та зберігає стан ончейн. Це основа, на якій будуються всі продакшн-додатки Solana.

Пов'язані технічні посібники Solana

• Адреси контрактів Solana та ідентифікатори програм (Program IDs)
• Стандарти токенів Solana
• Токени Solana SPL

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