Create token account что это

Associated Token Account Program

This program defines the convention and provides the mechanism for mapping the user’s wallet address to the associated token accounts they hold.

Motivation​

• A user may own arbitrarily many token accounts belonging to the same mint which makes it difficult for other users to know which account they should send tokens to and introduces friction into many other aspects of token management. This program introduces a way to deterministically derive a token account key from a user’s main System account address and a token mint address, allowing the user to create a main token account for each token they own. We call these accounts Associated Token Accounts.
• In addition, it allows a user to send tokens to another user even if the beneficiary does not yet have a token account for that mint. Unlike a system transfer, for a token transfer to succeed the recipient must have a token account with the compatible mint already, and somebody needs to fund that token account. If the recipient must fund it first, it makes things like airdrop campaigns difficult and just generally increases the friction of token transfers. The Associated Token Account program allows the sender to create the associated token account for the receiver, so the token transfer just works.

See the SPL Token program for more information about tokens in general.

Background​

Solana’s programming model and the definitions of the Solana terms used in this document are available at:

• https://docs.solana.com/apps
• https://docs.solana.com/terminology

Source​

The Associated Token Account Program’s source is available on github.

Interface​

The Associated Token Account Program is written in Rust and available on crates.io and docs.rs.

Finding the Associated Token Account address​

The associated token account for a given wallet address is simply a program-derived account consisting of the wallet address itself and the token mint.

The get_associated_token_address Rust function may be used by clients to derive the wallet’s associated token address.

The associated account address can be derived in TypeScript with:

import  PublicKey > from '@solana/web3.js'; import  TOKEN_PROGRAM_ID > from '@solana/spl-token';  const SPL_ASSOCIATED_TOKEN_ACCOUNT_PROGRAM_ID: PublicKey = new PublicKey( 'ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL', );  function findAssociatedTokenAddress(  walletAddress: PublicKey,  tokenMintAddress: PublicKey ): PublicKey   return PublicKey.findProgramAddressSync( [  walletAddress.toBuffer(), TOKEN_PROGRAM_ID.toBuffer(),  tokenMintAddress.toBuffer(), ], SPL_ASSOCIATED_TOKEN_ACCOUNT_PROGRAM_ID )[0]; > 

Creating an Associated Token Account​

If the associated token account for a given wallet address does not yet exist, it may be created by anybody by issuing a transaction containing the instruction returned by create_associated_token_account.

Regardless of creator the new associated token account will be fully owned by the wallet, as if the wallet itself had created it.

• Motivation
• Background
• Source
• Interface
  • Finding the Associated Token Account address
  • Creating an Associated Token Account

  Токены Solan’ы

  Понимание токенов Solana может быть довольно сложным, если вы имеете опыт работы с Ethereum. В Ethereum обычные токены используют стандарт ERC20, а NFT токены используют стандарт ERC721. Каждый токен ERC20, ровно как и каждая NFT коллекция, имеет свой собственный смарт-контракт

  Модель аккаунтов Соланы

  Чтобы понять как работают токены на солане, вам сначала нужно понять модель учетных записей соланы. Я настоятельно рекомендую прочитать эту вики , особенно если вы имеете опыт работы с Ethereum. Вот краткая выжимка:

  • Учетная запись либо содержит данные (например, сколько у вас токенов), либо представляет собой исполняемую программу (например, смарт-контракт). Первые называются «data accounts», а вторые — «program accounts». Важно отметить, что в отличие от Ethereum, учетные записи программы не хранят состояние. Все состояние хранится в учетных записях данных
  • Каждый аккаунт содержит следующие поля:
  • Каждая учетная запись имеет уникальный адрес (похожий на Ethereum). Большинство адресов являются открытым ключом keypair
  • Каждая учетная запись принадлежит program. По умолчанию вновь созданная учетная запись принадлежит встроенной программе под названием «System Program». Только владелец учетной записи может изменить ее

  Для получения более подробной информации вы можете обратиться к вики , о которой я упоминал выше, или прочитать краткий учебник по учетным записям

  Учетная запись слева — это учетная запись программы, которая может увеличивать счетчик. Значение счетчика необходимо хранить в отдельной учетной записи с данными. Учетная запись с данными принадлежит учетной записи программы, что означает, что учетная запись программы может изменять состояние учетной записи с данными

  Что такое Solana’s Token Program?

  Solana Token Program позволяет следующее (для взаимозаменяемых и невзаимозаменяемых токенов):

  • Минт токенов
  • Трансфер токена
  • Сжигание токенов

  Вот hana рассказывал о том, как это работает:

  Одним из преимуществ модели программы/учетной записи является то, что у вас может быть одна общая программа, которая работает с различными данными. Лучшим примером этого является программа токена spl. Чтобы создать новый токен, вам не нужно развертывать код, как это делается в эфириуме. Вы создаете учетную запись, которая может минтить токены, и другие учетные записи, которые могут их получать. Адрес минтера однозначно определяет тип токена, и все они передаются в качестве аргументов одному статическому экземпляру программы

  По сути, вместо развертывания нового смарт-контракта ERC20 для каждого нового токена, все, что вам нужно сделать, это отправить инструкцию программе токена. В зависимости от того, какую инструкцию вы отправляете, программа токенов будет минтить/передавать/сжигать токены

  Если вы еще не совсем поняли, не волнуйтесь! Рассмотрение примера должно прояснить ситуацию!

  Примечание: иногда вы увидите токены Solana, называемые «SPL tokens». SPL означает Solana Program Library (библиотеку программ Solana), которая представляет собой набор программ Solana, которые команда Соланы развернула в сети. Токены SPL аналогичны токенам ERC20, поскольку каждый токен SPL имеет стандартный набор функций

  Как работает Solana Token Program?

  Самый простой способ понять это — рассмотреть несколько примеров. В наших примерах будут рассмотрены взаимозаменяемые токены, и мы будем использовать инструмент командной строки spl-token для взаимодействия с программой токена (вы можете установить его, запустив в командной строке cargo install spl-token-cli)

  Повторюсь, все, что делает spl-token — это отправляет инструкции в token program. Вы можете имитировать следующее поведение, используя клиент JavaScript или взаимодействуя с программой токена через CPI в Rust

  Подготовка

  Во-первых, убедитесь, что вы установили Solana CLI и spl-token

  Затем запустите solana-keygen new -o ~/my_solana_wallet1.json и создайте новую переменную окружения с именем $SOLADDR1, в которой будет храниться полученный открытый ключ. Повторите эти действия, но со второй переменной окружения с именем $SOLADDR2 (и назовите файл пары ключей my_solana_wallet2.json). Мы будем использовать эти адреса и файлы пар ключей позже, чтобы протестировать минт и трансфер токенов

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

  $ echo $SOLADDR1 3sdsSwWWjjGA7HpPBQfGaXRE2HqmdKicMXHRapqLAu4L $ echo $SOLADDR2 ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh

  Примечание: многие команды в этом руководстве можно сократить, запустив solana config set — keypair ~/my_solana_wallet1.json, который устанавливает пару ключей клиента по умолчанию. Например, это позволяет не указывать флаг —owner для многих из следующих команд. Я использую более длинные версии команд, чтобы обьяснение было более понятным

  Создание токена

  Теперь, когда мы все настроили, мы можем использовать spl-token. Во-первых, давайте создадим новый тип токена

  $ spl-token create-token --mint-authority ~/my_solana_wallet1.json Creating token 6ifRGEkJ6XmEjuqfTFNqAjjomUiDJTjRv4GHqBH6usWr

  При создании токена нового типа создается новая учетная запись с данными, которую в дальнейшем мы будем называть «mint account». Каждый тип токена связан ровно с одним mint account. Адрес mint account — 6ifRGEkJ6XmEjuqfTFNqAjjomUiDJTjRv4GHqBH6usWr, но вместо этого мы будем использовать $TOKEN1, чтобы упростить чтение. Мы можем запросить информацию об учетной записи следующим образом (в конце много непонятных символов, но не переживайте, они нам пока не нужны):

  $ solana account $TOKEN1 Public Key: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Balance: 0.0014616 SOL Owner: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA Executable: false Rent Epoch: 207 Length: 82 (0x52) bytes 0000: 01 00 00 00 2a b0 1a 64 bb c5 f0 df bf 57 d5 61 . *..d. W.a 0010: 56 a8 b8 85 8f a8 0b 09 f1 f1 a2 dc 4d 51 b3 63 V. MQ.c 0020: 8f 72 bd e9 00 00 00 00 00 00 00 00 09 01 00 00 .r. 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . 0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 . 0050: 00 00

  Мы можем проверить владельца (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) с помощью Solana Explorer . Владельцем является token program (учетная запись программы), которая отвечает за создание новых токенов, минт токенов и передачу токенов

  Теперь давайте посмотрим на данные mint account, которые идут после «Length: 82 (0x52) bytes», как показано выше. Человеку трудно читать шестнадцатеричные данные, поэтому вместо этого мы можем использовать Solana Explorer :

  Solana Explorer декодирует данные и отображает их в удобочитаемом формате. Вот что означает каждое из полей:

  • Address — это адрес mint account
  • Current Supply — количество сминченных токенов. Поскольку мы только что создали токен, он равен 0
  • Mint Authority — открытый ключ из keypair, которому разрешено минтить токены (мы указали это с помощью флага —mint-authority. Если кто-то еще попытается минтить токены, то он этого не сможет)
  • Decimals — определяет наименьший номинал токена. Для NFT он должен быть равен нулю. Девять по умолчанию

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

  • «Internal Solana relations» относятся к полю владельца, которое устанавливается для каждой учетной записи, например владелец, который отображается при запуске учетной записи solana $TOKEN1
  • «User-space relations» — это когда отношение между двумя учетными записями закодировано в данных учетной записи, например поле «mint authority», которое мы видели выше

  Владельцем Token Program является загрузчик BPF. Я не изображаю это здесь, потому что это не так важно и загромождает диаграмму

  Создание Token Account

  Прежде чем мы сможем создать токены, мы должны сначала создать учетную запись токена

  $ spl-token create-account $TOKEN1 --owner $SOLADDR1 Creating account 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak

  Отныне мы будем использовать $TOKENACCT1 вместо 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak, и мы будем называть эту учетную запись «token account». Вам может быть интересно, что такое токен-аккаунт? По сути, он просто хранит, сколько токенов есть у конкретного пользователя для определенного типа токена. Например, если у вас есть 10 токенов 1 и 5 токенов 2, то у вас будет две учетные записи токенов

  Вот как выглядит токен-аккаунт:

  $ solana account $TOKENACCT1 Public Key: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Balance: 0.00203928 SOL Owner: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA Executable: false Rent Epoch: 207

  Учетная запись токена связана с тремя другими учетными записями. Его внутренним владельцем является token program, поскольку token program должна иметь возможность изменять учетную запись (например, добавлять к ней больше токенов). Затем в пользовательском пространстве его владельцем является $SOLADDR1, а его «mint» или связанный с ним mint account — $TOKEN1

  Вот как теперь связаны все аккаунты:

  Token Minting

  Наконец-то мы можем сминтить токены! Эта часть проще — мы просто указываем mint account (которая определяет «type» токена для минта), количество токенов и учетную запись, которой их нужно передать

  $ spl-token balance $TOKEN1 --owner $SOLADDR1 0 $ spl-token mint $TOKEN1 10 $TOKENACCT1 --mint-authority ~/my_solana_wallet1.json Minting 10 tokens Token: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Recipient: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak $ spl-token balance $TOKEN1 --owner $SOLADDR1 10

  Помимо использования spl-token balance, вы также можете использовать spl-token accounts, чтобы просмотреть, сколько каждого токена принадлежит определенной учетной записи

  $ spl-token accounts --owner $SOLADDR1 Token Balance ------------------------------------------------------------- Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk 10

  Что произойдет, если вы попытаетесь создать токены с другим значением параметра —mint-authority?

  $ spl-token mint $TOKEN1 10 $TOKENACCT1 --mint-authority ~/my_solana_wallet2.json Minting 10 tokens Token: Aqf1rBKNQYgX1mjE64STwV3miEwXEe2ioZzD7n4vkpXk Recipient: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x4 [5 log messages]

  Ответ? Это не работает! Это связано с тем, что в поле «mint authority» token account’а указана другая учетная запись, и только этой учетной записи разрешено минтить новые токены

  Token Transferring

  Давайте попробуем перенести некоторые токены в $SOLADDR2 (которые должны были быть созданы в разделе « Подготовка »)

  $ spl-token transfer $TOKEN1 1 $SOLADDR2 --owner ~/my_solana_wallet1.json Transfer 5 tokens Sender: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Recipient: ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh Recipient associated token account: FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE Error: Recipient's associated token account does not exist. Add `--fund-recipient` to fund their account

  Неудача! Сообщение об ошибке говорит, что нам не разрешено передавать токены, если у получателя нет token account

  Есть два способа исправить это:

  1. Создайтеtoken account для получателя, а затем перенесите токены.
  2. Используйте флаг —fund-recipient. Это заставляет отправителя платить за создание token account получателя

  Мы пойдем с подходом № 1

  $ spl-token create-account $TOKEN1 --owner $SOLADDR2 Creating account FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE $ spl-token transfer $TOKEN1 1 $SOLADDR2 --owner ~/my_solana_wallet1.json Transfer 1 tokens Sender: 9EYnoqiBQmJPR55db44cF4wkN1PD5D6vjxEz61r2Ujak Recipient: ES2C1YPzNh5JjQu7DdxrveaPUHj9CnrRWSdrFo4ku5Zh Recipient associated token account: FFednTgQRKDbGYjXrXk8SWPfzSJW3Q8ApN5mGCpGdAtE $ spl-token balance $TOKEN1 --owner $SOLADDR2 1

  Красиво, сработало! Давайте посмотрим на все учетные записи в этом действии

  Wrapped SOL

  Точно так же, как ETH можно обернуть токеном ERC20, чтобы сформировать wETH, так и SOL можно обернуть токеном SPL

  $ spl-token wrap 1 ~/my_solana_wallet1.json Wrapping 1 SOL into DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD

  Конечно, вы можете обратно развернуть полученный токен SPL, чтобы вернуть свои SOL

  $ spl-token unwrap DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD ~/my_solana_wallet1.json Unwrapping DXWzvX3RtZbito65G8ZgqmEzJM6Z6Fqy7NHkbpEmCUZD Amount: 1 SOL Recipient: 3sdsSwWWjjGA7HpPBQfGaXRE2HqmdKicMXHRapqLAu4L

  Такая упаковка SOL позволяет легко обменивать SOL на другие токены SPL

  Подождите, а как там NFT?

  Теперь, когда мы рассмотрели, как работают взаимозаменяемые токены, понять, что такое невзаимозаменяемые токены, должно быть легко. Я просто позволю вам прочитать доки , так как в любом случае я бы не стал много добавлять. Основными важными моментами являются:

  • Используйте —decimals 0 при создании токена, так как он должен быть только один
  • После минта одного токена отключите минты в будущем. Это гарантирует, что будет только один токен

  На практике никто не создает NFT таким образом. Вместо этого большинство людей используют Candy Machine , инструмент для загрузки изображений и метаданных и создания NFT на их основе

  Вот и все! К этому моменту вы должны понимать, как работают токены SPL и чем они отличаются от токенов ERC20

  Заключение:

  • Одна программа, называемая Token Program, может создавать новые токены, минтить новые токены и передавать токены между учетными записями
  • В отличие от токенов ERC20, где каждый новый токен связан с новым смарт-контрактом ERC20, в солане существует только одна Token Program. Однако каждый новый тип токена связан с новым mint account
  • Если пользователь хочет владеть некоторыми токенами определенного типа, ему необходимо иметь учетную запись токена. Другими словами, если кто-то владеет пятью разными типами токенов, у него будет пять разных учетных записей токенов
  • Вы можете обернуть SOL в токен SPL, что позволяет легко обменять его на другие токены SPL
  • Не взаимозаменяемый токен SPL — это токен с нулевым Decimals, который создают одну копию и отключил минт в будущем

  Управление личными маркерами доступа

  You can use a personal access token in place of a password when authenticating to GitHub in the command line or with the API.

  Warning: Treat your access tokens like passwords. For more information, see «Keeping your personal access tokens secure.»

  About personal access tokens

  Personal access tokens are an alternative to using passwords for authentication to GitHub when using the GitHub API or the command line.

  Personal access tokens are intended to access GitHub resources on behalf of yourself. To access resources on behalf of an organization, or for long-lived integrations, you should use a GitHub App. For more information, see «About creating GitHub Apps.»

  Types of personal access tokens

  GitHub currently supports two types of personal access tokens: fine-grained personal access tokens and personal access tokens (classic). GitHub recommends that you use fine-grained personal access tokens instead of personal access tokens (classic) whenever possible.

  Both fine-grained personal access tokens and personal access tokens (classic) are tied to the user who generated them and will become inactive if the user loses access to the resource.

  Organization owners can set a policy to restrict the access of personal access tokens (classic) to their organization. For more information, see «Setting a personal access token policy for your organization.»

  Fine-grained personal access tokens

  Fine-grained personal access tokens have several security advantages over personal access tokens (classic):

  • Each token can only access resources owned by a single user or organization.
  • Each token can only access specific repositories.
  • Each token is granted specific permissions, which offer more control than the scopes granted to personal access tokens (classic).
  • Each token must have an expiration date.
  • Organization owners can require approval for any fine-grained personal access tokens that can access resources in the organization.

  Personal access tokens (classic)

  Personal access tokens (classic) are less secure. However, some features currently will only work with personal access tokens (classic):

  • Only personal access tokens (classic) have write access for public repositories that are not owned by you or an organization that you are not a member of.
  • Outside collaborators can only use personal access tokens (classic) to access organization repositories that they are a collaborator on.
  • Some REST API operations are not available to fine-grained personal access tokens. For a list of REST API operations that are supported for fine-grained personal access tokens, see «Endpoints available for fine-grained personal access tokens».

  If you choose to use a personal access token (classic), keep in mind that it will grant access to all repositories within the organizations that you have access to, as well as all personal repositories in your personal account.

  As a security precaution, GitHub automatically removes personal access tokens that haven’t been used in a year. To provide additional security, we highly recommend adding an expiration to your personal access tokens.

  Keeping your personal access tokens secure

  Personal access tokens are like passwords, and they share the same inherent security risks. Before creating a new personal access token, consider if there is a more secure method of authentication available to you:

  • To access GitHub from the command line, you can use GitHub CLI or Git Credential Manager instead of creating a personal access token.
  • When using a personal access token in a GitHub Actions workflow, consider whether you can use the built-in GITHUB_TOKEN instead. For more information, see «Automatic token authentication.»

  If these options are not possible, and you must create a personal access token, consider using another CLI service to store your token securely.

  When using a personal access token in a script, you can store your token as a secret and run your script through GitHub Actions. For more information, see «Using secrets in GitHub Actions.» You can also store your token as a Codespaces secret and run your script in Codespaces. For more information, see «Managing secrets for your codespaces.»

  For more information about best practices, see «Keeping your API credentials secure.»

  Creating a fine-grained personal access token

  Note: Fine-grained personal access token are currently in beta and subject to change. To leave feedback, see the feedback discussion.

  

  1. Verify your email address, if it hasn’t been verified yet.
  2. In the upper-right corner of any page, click your profile photo, then click Settings.

  If you selected an organization as the resource owner and the organization requires approval for fine-grained personal access tokens, then your token will be marked as pending until it is reviewed by an organization administrator. Your token will only be able to read public resources until it is approved. If you are an owner of the organization, your request is automatically approved. For more information, see «Reviewing and revoking personal access tokens in your organization.»

  Creating a personal access token (classic)

  Note: Organization owners can restrict the access of personal access token (classic) to their organization. If you try to use a personal access token (classic) to access resources in an organization that has disabled personal access token (classic) access, your request will fail with a 403 response. Instead, you must use a GitHub App, OAuth app, or fine-grained personal access token.

  Note: Your personal access token (classic) can access every repository that you can access. GitHub recommends that you use fine-grained personal access tokens instead, which you can restrict to specific repositories. Fine-grained personal access tokens also enable you to specify fine-grained permissions instead of broad scopes.

  

  1. Verify your email address, if it hasn’t been verified yet.
  2. In the upper-right corner of any page, click your profile photo, then click Settings.

  

  .

  Deleting a personal access token

  You should delete a personal access token if it is no longer needed. If you delete a personal access token that was used to create a deploy key, the deploy key will also be deleted.

  

  In the upper-right corner of any page, click your profile photo, then click Settings.

  Using a personal access token on the command line

  Once you have a personal access token, you can enter it instead of your password when performing Git operations over HTTPS.

  For example, to clone a repository on the command line you would enter the following git clone command. You would then be prompted to enter your username and password. When prompted for your password, enter your personal access token instead of a password.

  $ git clone https://github.com/USERNAME/REPO.git Username: YOUR_USERNAME Password: YOUR_PERSONAL_ACCESS_TOKEN 

  Personal access tokens can only be used for HTTPS Git operations. If your repository uses an SSH remote URL, you will need to switch the remote from SSH to HTTPS.

  If you are not prompted for your username and password, your credentials may be cached on your computer. You can update your credentials in the Keychain to replace your old password with the token.

  Instead of manually entering your personal access token for every HTTPS Git operation, you can cache your personal access token with a Git client. Git will temporarily store your credentials in memory until an expiry interval has passed. You can also store the token in a plain text file that Git can read before every request. For more information, see «Caching your GitHub credentials in Git.»

  Further reading

  • «About authentication to GitHub»
  • «Token expiration and revocation»

  Create Token

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

  iost также реализован в соответствии со стандартом Token20 на основе встроенного системного контракта token.iost . Интерфейсы token.iost описываются следующим образом:

  // create tokenSymbol create(tokenSymbol, issuer, totalSupply, configJson); // string, string, number, json issue(tokenSymbol, to, amountStr); // string, string, string transfer(tokenSymbol, from, to, amountStr, memo); // string, string, string, string, string transferFreeze(tokenSymbol, from, to, amountStr, unfreezeTime, memo); // string, string, string, string, number, string destroy(tokenSymbol, from, amountStr); // string, string, string // query interfaces balanceOf(tokenSymbol, from); // string, string supply(tokenSymbol); // string totalSupply(tokenSymbol); // string 

  create(tokenSymbol, issuer, totalSupply, configJson)

  Authority required: issuer

  TokenSymbol это уникальный идентификатор конкретного токена, то есть вы не можете создать токен в контракте token.iost с ранее использованным tokenSymbol. Это строка длинной от 2 до 16, состоящая только из символов a-z , 0-9 и _ .

  Issuer является эмитентом токена, только эмитент имеет разрешение на выдачу токенов на произвольный аккаунт. Обычно эмитент токена это аккаунт, но также может быть и контракт. Когда issuer(эмитентом) является ID контракта, это означает, что только у этого контракта есть разрешение на вызов метода issue для выдачи(выпуска) токенов другим. Допустим, эмитентом токена mytoken является контракт Contractabc , тогда Contractabc может вызвать issue для выпуска в обращение mytoken , Contractabc также может вызвать функцию в контракте Contractdef , и таким образом Contractdef будет иметь разрешение на выпуск в обращение mytoken . То есть, разрешение контракта может быть передано в вызываемый контракт, вам нужно использовать системную функцию blockchain.callWithAuthority вместо blockchain.call при вызове другого контракта для передачи разрешения.

  TotalSupply это число типа int64, эмитент не может выпустить в обращение больше токенов, чем totalSupply.

  ConfigJson это формат json, содержащий конфигурации для токена. Вот все поддерживаемые свойства конфигурации:

  issue(tokenSymbol, acc, amountStr)

  Authority required: issuer of tokenSymbol

  Выдача tokenSymbol для аккаунта acc , amountStr это строка содержащая сумму выпуска, сумма должна быть положительным десятичным числом с фиксированной запятой, такой как «100», «100.999»

  transfer(tokenSymbol, accFrom, accTo, amountStr, memo)

  Authority required: accFrom

  Перевод токенов tokenSymbol с аккаунта accFrom на аккаунт accTo с amountStr и memo, сумма должна быть положительным десятичным числом с фиксированной запятой, а memo — это дополнительное строковое сообщение этой операции перевода токенов длиной не более 512 байт.

  transferFreeze(tokenSymbol, accFrom, accTo, amountStr, unfreezeTime, memo)

  Authority required: accFrom

  Перевод токенов tokenSymbol с аккаунта accFrom на аккаунт accTo с amountStr и memo, и заморозка этой части токенов до unfreezeTime (времени разморозки). unfreezeTime это наносекунды времени unix по истечению которых, токены будут разморожены.

  destroy(tokenSymbol, accFrom, amountStr)

  Authority required: accFrom

  Уничтожение amountStr количества токенов в аккаунте accFrom . После уничтожения, запас токенов на этом аккаунте уменьшиться, что означает, вы можете выпустить больше токенов при наличии totalSupply путем уничтожения некоторого количества токенов.

  Authority required: null

  Запрос баланса аккаунта (количества определенного токена — tokenSymbol, которым владеет данный аккаунт — acc).

  Authority required: null

  Запрос запаса определенного токена.

  Authority required: null

  Запрос общего объема поставки определенного токена.

  Создать Token20 в блокчейне iost можно необыкновенно просто, вам достаточно только вызвать контракт token.iost , без реализации интерфейсов Token20 и развертывания смарт-контракта самостоятельно.

  Ниже приведен пошаговый пример того, как создать токен с помощью bank аккаунта и переводить токены между аккаунтами, вначале вам нужно создать аккаунты bank , user0 , user1 .

  iwallet call token.iost create '["mytoken", "bank", 21000000000, ]' --account bank iwallet call token.iost issue '["mytoken", "bank", "1000"]' --account bank iwallet call token.iost issue '["mytoken", "user0", "100.00000001"]' --account bank iwallet call token.iost transfer '["mytoken", "user0", "user1", "10", "user0 pay coffee"]' --account user0 iwallet call token.iost transferFreeze '["mytoken", "user1", "user0", "0.1", 1544880864601648640, "voucher"]' --account user1 iwallet call token.iost destroy '["mytoken", "bank", "1000"]' --account bank 

  Похожие публикации:

  1. 07 счет в балансе где отражается
  2. С чего начинается проверка подразделения
  3. Сторонник что это
  4. Что такое fbo и fbs на маркетплейсах