Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to understand the eosio.token contract of eos blockchain. Many people may not understand it very well. In order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

I must admit that learning eosio has never felt like walking around. I can see why many people say it has a steep learning curve. As the eosio software continues to experience a large number of rapid development, the number of documents is limited, there are few work examples for reference. I've been trapped several times, and I want to help improve the experience of the next developer.

What is an eosio.token contract?

Eosio.token contracts allow the creation of many different tokens. This allows anyone to create and send tokens. Each token must be issued by an issuer account. Because accounts can contain multiple parties, you can create and manage tokens using a normal account with owner and activity permissions or a custom configuration account. Each token is of type asset, as follows:

1000000000.0000 SYS1.0000 SYMBOL0.10 SYS

The asset type is a number (up to 18 decimal places if I remember correctly) and a symbol that can be between 1-7 uppercase letters. There are three operations available for this contract to interact with. They are: create, publish and transfer money.

Create a feature that defines a new token. This includes tokens asset symbols, maximum supply, and accounts that allow tokens to be issued. Creation also keeps the new token configuration on the blockchain. This means that the storage of the new token configuration must be placed by someone. As you will see later, the account that deployed this contract (in our case, 'eosio.token') will also pay for the token configuration store.

Issued to increase the effective supply of tokens. Tokens can be issued continuously until the maximum supply is reached. Issuer defined during token creation must approve this operation for it to succeed.

Transfer allows one account to transfer tokens to another account.

Deployment contract

The first thing you should know is that every eosio smart contract belongs to an eosio account. Contracts are basically objects with which other accounts can interact. The contract contains the operation actions that executes code on the blockchain. Contracts can directly access storage, delete and update data on the blockchain.

At least one account authorization is required to push an action to a contract. Depending on the complexity of the contract, further accounts and permissions may be required. An account can consist of single or multiple individuals set up in a permission-based configuration. Smart contracts can only be run by one account, and an account can only have one smart contract. It is a best practice to provide the same (lowercase) name for the account and the contract.

Before you can interact with an eosio.token contract, you need to create an account with the same name and deploy the contract to that account.

First create an account

$cleos create account eosio eosio.token

Then compile the contract

$cd eos/contract/eosio.token$eosiocpp-o eosio.token.wast eosio.token.cpp

Finally, deploy the contract to the account

$cleos set contract eosio.token.. / eosio.token

You can verify that the contract has been deployed

$cleos get code eosio.token contract framework

The contract is divided into two documents, eosio.token.cpp and eosio.token.hpp. The .hpp file defines the contract class, operation, and table, while the .cpp file implements the operation logic. Let's first look at the contract class that will be used to instantiate the contract object. (I removed some legacy code from eosio.token.hpp)

/ * @ file * @ copyright defined in eos/LICENSE.txt * / # pragma once#include # include # include namespace eosiosystem {class system_contract;} namespace eosio {using std::string; class token: public contract {public: token (account_name self): contract (self) {} void create (account_name issuer, asset maximum_supply); void issue (account_name to, asset quantity, string memo) Void transfer (account_name from, account_name to, asset quantity, string memo); private: friend eosiosystem::system_contract; inline asset get_supply (symbol_name sym) const; inline asset get_balance (account_name owner, symbol_name sym) const Struct account {asset balance; uint64_t primary_key () const {return balance.symbol.name ();}}; struct currency_stats {asset supply; asset max_supply; account_name issuer; uint64_t primary_key () const {return supply.symbol.name () }}; typedef eosio::multi_index accounts; typedef eosio::multi_index stats; void sub_balance (account_name owner, asset value); void add_balance (account_name owner, asset value, account_name ram_payer);}; asset token::get_supply (symbol_name sym) const {stats statstable (_ self, sym); const auto& st = statstable.get (sym) Return st.supply;} asset token::get_balance (account_name owner, symbol_name sym) const {accounts accountstable (_ self, owner); const auto& ac = accountstable.get (sym); return ac.balance;}} / namespace eosio

Constructors and operations are defined as public member functions. The constructor takes the account name (which will be the account for the deployment contract, that is, eosio.token) and sets it to the contract variable. Note that this class inherits from eosio::contract.

Tables and helper functions are provided as private members. Two inline functions are defined at the bottom but have never been used. This leaves us with the important functions sub_balance () and add_balance (). These will be called by the transfer operation.

Table

The two tables defined are accounts and stat. The accounts table consists of different account objects, each of which holds the balance of different tokens. The stat table consists of currency_stats objects (defined by struct currency_stats) that hold the supplier, max_supply, and publisher. Before proceeding, it is important to know that the contract saves the data to two different ranges. The scope of the accounts table is limited to the eosio account, and the scope of the stat table is limited to the token name.

According to the definition of eosio::multi_index, code is the name of the account with write permissions, and scope is the account in which the data is stored.

Scope is essentially a way to divide data in a contract so that it can only be accessed within a defined space. In a token contract, each eosio account is used as the scope of the accounts table. The accounts table is a multi-indexed container that contains multiple account objects. Each account object is indexed by its token symbol and contains the token balance. When querying a user's accounts table with its range, it returns a list of all tokens for which the user has an existing balance.

This is how I imagine it.

In the figure above, there is an eosio account called tom, which has its own scope. In his range is a watch called accounts. In this table is a separate account object for each token he holds, SYS and EOS.

There is also a second table called stat. This table will contain the status of existing tokens. The new tag is created within its own symbolic name range. Within the scope is an stat table that contains currency_stats objects. Unlike the accounts table, which contains many different account objects, the stat table contains only a single currency_stats object with a given tag symbol.

Operation

The operation is implemented in a .cpp file. To create a new token, you must send a create operation. Create has two parameters: the issuer, and the maximum supply of new tokens. Issuer is the only one allowed to increase the supply of new tokens. Issuer cannot be issued beyond the maximum supply.

The first line of code requires only the authorization of the contract account itself. This can be given using the command-line flag-p eosio.token when pushing the operation.

The next few lines extract the symbols of the incoming maximum_supply asset and perform some error handling. If any eosio_assert fails, all code will be rolled back and the transaction will not be pushed to the blockchain.

A stat table is constructed as statstable using a symbolic name (marker symbol) as its range. The code checks to see if the token already exists. If not, create a new token state and save it to the blockchain. The first argument in the emplace function, _ self, means that the contract account eosio.token will pay for the bet store.

Note that the symbol for supply is saved because it is used as the key to locate the table row, but the supply has not been issued.

You can now perform the next operation, publish. The release will be based on an account that will receive issued tokens, the number of tokens issued and memos. The publish operation performs two operations in one because it modifies the created token supply and invokes the transfer operation to send the published token. Similarly, the first few lines extract the token symbol and perform an error check.

The following code section constructs the stat table using the symbolic name as the range. This is used as a key to find tokens previously created using create action.

Note that the existing currency_stat returned from statstable.find () is an iterator that points to the object found. For brevity, a new variable named st is declared and set to the actual object pointed to by the existing iterator. This allows us to use it. Operator accesses member variables instead of pointer representations->.

The issuer who created the token needs to sign the transaction and perform more error handling.

Finally, modify the currency_stats st of the existing token and add the issued quantity to the supply. Issuer also adds this supply to their balance so that the initial supply can be traced back to their account.

Next, the transfer function is called through SEND_INLINE_ACTION (), which transfers the money. The arguments are as follows:

1.*this is the contract code to which the action belongs.

The name of the 2.transfer operation.

3. {st.issuer, N (active)} the permissions required for the operation.

4. {st.issuer, to, quantity, memo} parameters of the operation itself.

This brings us to the final transfer operation. The transfer operation will get four input parameters from from,to,quantity and memo. From is who will send tokens, so quantity will be subtracted from their balance. To is who will receive tokens, so quantity will be added to their balance. Quantity is the number of tokens to be sent, and memo is a string that can be sent with the transaction. Memo is not used or stored in this contract.

This first requires from accounts account permissions and performs publish processing on the from and to accounts. The symbol is extracted from the quantity and used to obtain the currency_stats of the token.

The require_recipient () function notifies the sender and receiver when the operation is complete.

Complete more release processing, and finally call two private functions, sub_balance () and add_balance (), to subtract the token balance from the sending add_balance () and increase the recipient's token balance.

This is the complete 'eosio.token.cpp' file.

/ * @ file * @ copyright defined in eos/LICENSE.txt * / # include "eosio.token.hpp" namespace eosio {void token::create (account_name issuer, asset maximum_supply) {require_auth (_ self); auto sym = maximum_supply.symbol; eosio_assert (sym.is_valid (), "invalid symbol name"); eosio_assert (maximum_supply.is_valid (), "invalid supply") Eosio_assert (maximum_supply.amount > 0, "max-supply must be positive"); stats statstable (_ self, sym.name ()); auto existing = statstable.find (sym.name ()); eosio_assert (existing = = statstable.end (), "token with symbol already exists"); statstable.emplace (_ self, [&] (auto& s) {s.supply.symbol = maximum_supply.symbol S.max_supply = maximum_supply; s.issuer = issuer;});} void token::issue (account_name to, asset quantity, string memo) {auto sym = quantity.symbol; eosio_assert (sym.is_valid (), "invalid symbol name"); eosio_assert (memo.size () 0, "must issue positive quantity"); eosio_assert (quantity.symbol = = st.supply.symbol, "symbol precision mismatch") Eosio_assert (quantity.amount 0, "must transfer positive quantity"); eosio_assert (quantity.symbol = = st.supply.symbol, "symbol precision mismatch"); eosio_assert (memo.size () = value.amount, "overdrawn balance"); if (from.balance.amount = = value.amount) {from_acnts.erase (from) } else {from_acnts.modify (from, owner, [&] (auto& a) {a.balance-= value;});}} void token::add_balance (account_name owner, asset value, account_name ram_payer) {accounts to_acnts (_ self, owner); auto to = to_acnts.find (value.symbol.name ()) If (to = = to_acnts.end ()) {to_acnts.emplace (ram_payer, [&] (auto& a) {a.balance = value;});} else {to_acnts.modify (to, 0, [&] (auto& a) {a.balance + = value;});} / / namespace eosioEOSIO_ABI (eosio::token, (create) (issue) (transfer))

Example command:

$cleos push action eosio.token create'["usera", "21000000.0000 DEMO"]'- p eosio.token usera $cleos push action eosio.token issue'["usera", "21000000.0000 DEMO", "issuance"]'- p usera $cleos push action eosio.token tranfser'["usera", "userb", "1000000.0000 DEMO", "here you go"]'- p usera

Table commands:

$cleos get table eosio.token DEMO stat {"rows": [{"supply": "21000000.0000 DEMO"max_supply": "2100000000.0000 DEMO"issuer": "usera"}], "more": false} $cleos get table eosio.token usera accounts {"rows": [{"balance": "20000000.0000 DEMO"}] "more": false} $cleos get table eosio.token userb accounts {"rows": [{"balance": "10000000.0000 DEMO"}], "more": false}

Note: this article was written when the Dawn4.1 code was released.

=

Share some interactive online programming tutorials related to block chains such as ethernet, EOS, Bitcoin, etc.:

EOS course, this course helps you quickly get started with the development of EOS block chain decentralized applications, covering core knowledge points such as EOS tool chain, accounts and wallets, issuing tokens, smart contract development and deployment, using code and intelligent contract interaction, and finally using all knowledge points to complete the development of a note DApp.

The java ethernet development tutorial is mainly for java and android programmers to conduct a detailed web3j explanation of blockchain ethernet development.

Python ethernet, mainly for python engineers to use web3.py for block chain ethernet development of the detailed explanation.

Php Ethernet Square, mainly introduces the use of php for intelligent contract development interaction, account creation, transaction, transfer, token development, filter and transaction and so on.

Introduction to Ethernet Square tutorial, mainly introduces the intelligent contract and dapp application development, suitable for entry.

Yi Tai Fang development advanced tutorial, mainly introduces the use of node.js, mongodb, block chain, ipfs to achieve decentralized e-commerce DApp practice, suitable for advanced.

C # Ethernet Square, mainly explains how to use C # to develop .net-based Ethernet Square applications, including account management, status and transactions, intelligent contract development and interaction, filters and transactions, etc.

Java Bitcoin Development course, for beginners, covers the core concepts of Bitcoin, such as blockchain storage, decentralized consensus mechanisms, keys and scripts, transactions and UTXO, etc., as well as how to integrate Bitcoin support functions into Java code, such as creating addresses, managing wallets, constructing naked transactions, etc., is a rare bitcoin development course for Java engineers.

Php Bitcoin Development course, for beginners, covers the core concepts of Bitcoin, such as blockchain storage, decentralized consensus mechanisms, keys and scripts, transactions and UTXO, etc., as well as how to integrate Bitcoin support functions into Php code, such as creating addresses, managing wallets, constructing naked transactions, etc., is a rare bitcoin development course for Php engineers.

Tendermint block chain development detailed understanding, this course is suitable for engineers who want to use tendermint for block chain development, the course content includes the core concepts of tendermint application development model, such as ABCI interface, Merkel tree, multi-version state library, etc., as well as rich practical code such as token issuance, it is the best choice for go language engineers to get started with block chain development.

After reading the above, do you have any further understanding of how to understand the eosio.token contract of the eos blockchain? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.