How to mint your own token on DFINITY ? Discussion on token standards

On June 10th, ICP League held the third developer community call, we invited developers from DFinance to discuss how to issue tokens on DFINITY and the ideas similar to the ERC-20 token standard.

insights

• ICP is the first native token of DFINITY and is deployed on the top of DFINITY as a smart contract, so it can be used as a reference to implement the standard
• When implementing the ERC-20 standard on DFINITY, unlike Ethereum, no massage of transactions is stored on DFINITYn, thus requiring the record of transactions under the token standard
• As a container’s space is not big enough to store transaction records, token contracts have some scaling problems.
• DFINITY uses a reverse gas model, users do not need to consume gas when using it. In order to avoid spam attacks, it is necessary to add transfer chargeback or fees to the token standard.

ICP Token

In Ethereum ether is the native token, the transaction such as mining, transferring, interacting with contracts, and paying gas are packaged in blocks and coupled with the blockchain. In DFINITY, ICP tokens are actually built in a smart contract called “Ledger” on the network, and the implementation of ICP tokens’ functions such as query, transfer, transaction management and pledge are in the smart contract (archive_node.rs).

Since DFINITY’s smart contract is more similar to a container under Internet microservices, the state of the smart contract is stored inside the Ledger container. In fact, ICP’s transaction records are stored inside the smart contract and need to be queried using the contract’s functions.

In fact, only DFINITY’s gas token cycles is the only underlying native token on chain, and cycles can only be obtained by burning ICP.

All operations are recorded as transactions in the Ledger container, and DFINITY uses a blockchain-style data structure to record the ledger in the Ledger container at the same time. Note that the blockchain here is just a format for storing the ledger data, not a consensus blockchain. Here is the state of the implementation.

Therefore, ICP can be seen as the first token standard on DFINITY, its code is already open source. When we want to implementa standard similar to ERC-20standard, we’d better follow the design of ICP tokens . Here is the open source link: https://github.com/dfinity/ic/tree/master/rs/rosetta-api /ledger_canister.

Follow ERC-20 token standard

Visit https://github.com/dfinance-tech/ic-token/blob/main/simple-erc20/src/token.mo to see the source code of DFinance following the DFINITY token standard of ERC-20, using the Motoko language.

Owner_ means the token creator, typically the deployer of the container，name_ meanss the name; decimals_ denotes the exact number of bits in the token, symbol_ is the token’s symbol, and totalSupply_ is the total supply of tokens. These are some of the basics.

But in fact, the decimals_ which indicates the number of tokens can be deleted. This parameter is needed in the ethereum contract because solidy cannot support floating point calculations, but the language of DFINITY can support floating point operations.

Balances is a type under the database which represents an account’s balance. DFINITY’s persistent database HashMap is used here to establish a link between accounts and balances. allowance records Approve, which is often used in ethereum to allow an account or smart contract to use your balance.

This implementation follows the operations on Ethereum like transfer, transferFrom, balanceOf, allowance, and approve. Regarding token’s minting and buning, some Ethereum projectswill choose to transfer tokens directly to 0x0 address to burn tokens, because it is impossible to reverse the calculation of the private key of an 0x0 address, so it can never be transferred out again. However, DFinance’s dod not do such things because DFINITY does not have a public burning address yet, so it implements a burning method to directly subtract the balance in the database.

A better DFINITY token standard

DFINITY official open source ICP code is closer to their practice, the code follows ERC-20 standard, try to achieve compatibility, but also become more complex.Here is the open source code: https://github.com/dfinance-tech/ic-token/tree/ledger/src.

In ICP’s implementation, accounts use the account ID, while in this implementation they use Principal ID . The community has different opinions about the two choices.

The biggest difference is the addition of a database to record transfer history messages: since the token is also an implementation of a smart contract on DFINITY, it has the same problem as ICP, i.e. the final consistency of the data comes first and the transaction information is not available on the block. Therefore, it is necessary to create a data structure in the container to save the message. find OpRecord.mo under the core code, every operation of transfer, casting, destruction and approval is recorded in an OpRecord, and there is detailed information under an OpRecord, which is convenient for users to check later.

About scaling

We have talked about scaling many times before, it comes up again in the token standard. Because it is necessary to store a very large amount of data to keep a record of token transfers in a smart contract, and DFINITY only supports a maximum capacity of 4GB now.

In fact, all DFINITY dapps will face the problem of container capacity limitation, and the ultimate solution is to implement a set of automatic scaling database infrastructure, which will divide the data into new containers before a container capacity runs out.

This infrastructure is like a standardized database middle tier, the upper layer DApps can directly call the APIs of the database‘s middle tier, and the scaling problem of dealt by the middle tier. Sudograph is trying to develop a database engine, although it is very convenient for developers to self-define data types, it has not tried to automatically scale the capacity.

In the short term we can also periodically pack some transaction history to external static storage and then delete the history in the DFINITY container and keep it only for a period of time. As DFINITY’s WASM may support 64-bit, which can expand the memory of a single container.

Gas fees resist spam trading attacks

FINITY uses a reverse gas model. Ethereum users pay gas for their transactions, on DFINITY the gas is paid by dapps so users can enjoy the services without paying gas fees.

However, it may be subject to potential attacks, if someone maliciously sends a bunch of junk transactions, or keeps calling the contract, or stuffs your contract with junk data, consuming the contract’s storage space and gas, it will be down. The direct influence is that we can’t make transactions. Attacker can use DDOS attack to prevent everyone from trading, thus controlling the market.

DFINITY’s ICP token took this issue into consideration. Whenever a transfer is invoked, some fees will be deducted, now a call will deduct 0.0001 ICP to prevent attacks. The contract can be designed in such some ways

1. Use transferred token as gas. Every transfer, minting and other operations of the token contract deducts or destroys a certain amount or percentage of tokens. This scheme is very simple and sounds like the deflationary token design on ethereum.

2. Use ICP as gas fee, similar to ICP’s implementation.

3. Every transaction on Ethereum has a fixed amount of gas, so developers can estimate the amount of gas. There is no such interface on DFINITY, but it is possible to implement it. Moreover, DFINITY gas is paid for using cycles with a stable price. So you can calculate the unit price of an operation by estimating how many cycles it needs to consume, and then deduct the corresponding amount of tokens according to the transaction pairs of cycles and tokens in the exchange, so that the processing fee can fully cover the transaction processing cost.

Further Optimization

Remove Approve

The difference between ETH and ERC-20 standards in Ethereum, and to avoid reentry attacks, developers added an additional operation called approve. However, in DFINITY, it has been proposed to remove the approve function to improve the experience and to propose a “subscription” alternative. And this would also prevent attacks, because with approve in the DFINITY model, an attacker could send a bunch of approvals to fill up the memory of the container and bring it down. There are some objections to this, see https://forum.dfinity.org/t/thoughts-on-the-token-standard/4694/4 for the community discussion.

Use Principal IDs to save space

In “An introduction to DFINITY’s decentralized identity, account and wallet, and how developers can take advantage of it? we introduced DFINITY’s Principal ID and Account ID as two similar IDs: Principal ID is used for container usage and Account ID is used for the ledger, both of which are homogeneous. Currently the Account ID is used in the ICP implementation of DFINITY, but some people in the community have suggested to use the Principal ID in the token contract, because the Principal ID is shorter and can save 25% of space.

Language

According to an DFINITY’s AMA, they suggest developers using Rust when programing some something with higher security requirements, such as token contracts.

Managing Contract Controllers

Because DFINITY contracts allow upgrades, the controller of the contract has more power and can even issue additional tokens and roll back operations, so it is necessary to manage the controller better. Developers can assign the controller to zero addresses so that the contract can never be upgraded, or they can replace the controller with a DAO, which is managed by community.

About DFinance

Thanks to DFinance for sharing, DFinanace is building DFINITY’s token standard and helping users issue tokens with one click and build financial foundations such as swap. You can get their news by following https://twitter.com/DFinance_AI and also mint your first token by following the test link.

Website: https://icpleague.com

Discord: https://discord.gg/TUvFXfK9Dv

Telegram: https://t.me/joinchat/qNiiCG5GAB9mZjc1