General
Токени на Solana

Токени на Solana

Mint та токен-рахунки

Як ми зазначали в попередньому розділі, основними будівельними блоками програми SPL Token є рахунки: mint-рахунки, які містять усю інформацію про токени, та токен-рахунки, які містять усю інформацію про володіння цими конкретними токенами.

Для кожного унікального mint існують тисячі різних токен-рахунків, які представляють кількість власників цього токена в реєстрі.

У цьому розділі ми детальніше розглянемо ці різні типи рахунків:

Mint-рахунок

Токени в Solana унікально ідентифікуються за адресою Mint-рахунку, яким володіє Token Program. Цей рахунок діє як глобальний лічильник для конкретного токена і зберігає такі дані:

  • Supply: Загальна пропозиція токена
  • Decimals: Десяткова точність токена
  • Mint authority: Рахунок, уповноважений створювати нові одиниці токена, збільшуючи пропозицію
  • Freeze authority: Рахунок, уповноважений заморожувати токени в токен-рахунку, запобігаючи їх передачі або спаленню

Ось як ці дані виглядають у блокчейні:

rust
pub struct Mint {
    /// Optional authority used to mint new tokens. The mint authority may only
    /// be provided during mint creation. If no mint authority is present
    /// then the mint has a fixed supply and no further tokens may be
    /// minted.
    pub mint_authority: COption<Pubkey>,
    /// Total supply of tokens.
    pub supply: u64,
    /// Number of base 10 digits to the right of the decimal place.
    pub decimals: u8,
    /// Is `true` if this structure has been initialized
    pub is_initialized: bool,
    /// Optional authority to freeze token accounts.
    pub freeze_authority: COption<Pubkey>,
}

Метадані

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

Ми називаємо цю назву, символ та зображення Metadata токена. Адже у своїй нативній формі рахунок Mint — це просто публічний ключ довжиною 32 байти без прикріпленої інформації, зрозумілої для людини.

У нативному вигляді, в оригінальній програмі SPL Token, неможливо встановити метадані безпосередньо на токені. З цієї причини протоколи, такі як Metaplex, розробили програму MPL-token-metadata, щоб запропонувати спосіб, за допомогою якого кожен токен може мати пов'язані метадані.

З Розширеннями Токенів та програмою Token2022 це повністю змінюється. Розширення Метаданих дозволяє вбудовувати метадані безпосередньо в рахунок монети, усуваючи потребу в зовнішніх програмах.

Невзаємозамінні токени

Хоча корисність токенів спеціально делегується творцю, який може вирішити зробити цей конкретний токен токеном управління, утилітарним токеном або токеном спільноти, існують певні характеристики, за якими ми можемо розрізняти взаємозамінні та невзаємозамінні токени:

Невзаємозамінні токени повинні мати:

  • Запас 1, оскільки вони унікальні
  • 0 десяткових знаків, оскільки вони неподільні
  • Відсутність повноважень на карбування, оскільки ми не хочемо додавати більше токенів з такою ж характеристикою, оскільки це "знищило" б унікальність токена

Нативно неможливо забезпечити ці характеристики в програмі Token. З цієї причини програми, такі як MPL-token-metadata не лише пропонують реалізацію для метаданих, але й пропонують реалізацію для забезпечення цих обмежень і легкого створення NFT.

Рахунок токена

Програма Token створює Рахунки Токенів для відстеження індивідуального володіння кожною одиницею токена. Рахунок Токена зберігає такі дані як:

  • Монета: Токен, одиниці якого зберігає Рахунок Токена
  • Власник: Рахунок, уповноважений переказувати токени з Рахунку Токена
  • Кількість: Кількість токенів, які Рахунок Токена наразі зберігає

Ось як ці дані виглядають в мережі:

rust
pub struct Account {
    /// The mint associated with this account
    pub mint: Pubkey,
    /// The owner of this account.
    pub owner: Pubkey,
    /// The amount of tokens this account holds.
    pub amount: u64,
    /// If `delegate` is `Some` then `delegated_amount` represents
    /// the amount authorized by the delegate
    pub delegate: COption<Pubkey>,
    /// The account's state
    pub state: AccountState,
    /// If is_native.is_some, this is a native token, and the value logs the
    /// rent-exempt reserve. An Account is required to be rent-exempt, so
    /// the value is used by the Processor to ensure that wrapped SOL
    /// accounts do not drop below this threshold.
    pub is_native: COption<u64>,
    /// The amount delegated
    pub delegated_amount: u64,
    /// Optional authority to close the account.
    pub close_authority: COption<Pubkey>,
}

Кожен гаманець повинен мати рахунок токена для кожного токена (монети), який він хоче зберігати, з адресою гаманця, встановленою як власник рахунку токена. Кожен гаманець може володіти кількома рахунками токенів для одного й того ж токена (монети), але рахунок токена може мати лише одного власника і зберігати одиниці лише одного токена (монети).

Асоційований токен-рахунок

Асоційовані токен-рахунки спрощують процес пошуку адреси токен-рахунку для конкретного мінту та власника. Розглядайте Асоційований токен-рахунок як "стандартний" токен-рахунок для певного мінту та власника.

Асоційований токен-рахунок створюється з адресою, яка походить від адреси власника та адреси мінт-рахунку. Важливо розуміти, що Асоційований токен-рахунок — це просто токен-рахунок з певною адресою.

Це вводить ключову концепцію в розробці на Solana: Адреса, похідна від програми (PDA). PDA детерміновано виводить адресу, використовуючи заздалегідь визначені вхідні дані, що полегшує пошук адреси рахунку.

Blueshift © 2025Commit: 6d01265