ICP League co-hosted the third developer call with community developers and invited developers of DFinance project to discuss how to mint their tokens on DFINITY and design ideas similar to the ERC-20 token standard.
On June 10th, ICP League held its third developer call with community developers, inviting developers of the DFinance project to discuss how to issue tokens on DFINITY and design ideas similar to the ERC-20 token standard.
Highlights of this session.
ICP itself is the first token of DFINITY, which is deployed on the chain in the form of a smart contract, and thus can be used as a reference for implementing the standard.
(b) When implementing the ERC-20-like standard on DFINITY, unlike Ether, the massage of transactions is not kept on DFINITY’s blockchain, thus requiring the recording of transaction records under the token standard.
the token contract has a scaling problem because of the need to keep transaction records in a limited container space.
DFINITY uses the reverse gas model, users do not need to consume gas to use it, so in order to avoid a large number of spam transaction attacks, it is necessary to write the transfer deduction or fee in the token standard.
Implementation of ICP tokens
In the Ethernet network, ETH tokens are the native tokens at the bottom of the blockchain, and their transaction events such as mining, transferring, interacting with contracts, and paying gas are also packaged in blocks and coupled with the blockchain; while in DFINITY, ICP tokens are actually built in the network called “Ledger In DFINITY, ICP tokens are actually built in a smart contract called “Ledger” on the network, and the functions of ICP tokens such as query, transfer, transaction management and pledge are now in the smart contract (archive_node.rs).
Since DFINITY’s smart contract is more similar to a container under Internet microservices, and the state of the smart contract is kept 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 the 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. Note that the blockchain here is just a format for storing ledger data, not a consensus blockchain as we understand it. Here is the state of the implementation.
Therefore, ICP can be seen as the first token specification on DFINITY, whose code has been open sourced, and it is best to follow the design of ICP tokens when implementing a standard similar to ERC-20, open source link: https://github.com/dfinity/ic/tree/master/rs/rosetta-api /ledger_canister.
Following the 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’s DFINITY token standard following ERC-20, written in the officially developed language Motoko. It is written in the official language Motoko.
owner_ is the token creator, usually the deployer of the container; name_ is the name; decimals_ is the exact number of bits of the token; symbol_ is the symbol of the token; totalSupply_ is the total supply of tokens. These are some basics.
But in fact, decimals_, which indicates the number of bits of tokens, can be considered to be deleted. This parameter is needed in the ethereum contract because the solidy used by ethereum cannot support floating-point calculations, but the language of DFINITY can support floating-point operations.
balances is a type under the database that indicates how much the balance of an account corresponds to. 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 balances.
This implementation follows the ERC-20 operations of transfer, transferFrom, balanceOf, allowance, and approve. Regarding the token minting and destruction function, many projects on ethereum will choose to transfer tokens directly to 0x0 address for destruction, because it is impossible for someone to reverse the calculation of the private key of 0x0 address, so it can never be transferred out again. However, this is not done under the DFinance standard, because DFINITY does not yet have a recognized destruction address, and therefore implements a burn method that subtracts the balance directly in the database.
More in line with the DFINITY token standard
The official open source code for the ICP implementation, which follows the ERC-20, is closer to the official approach, trying to be as compatible as possible, but also becoming more complex, and is available at https://github.com/dfinance-tech/ic-token/tree/ledger/ src.
In DFINITY’s ICP implementation, the account used is the account ID, while in this implementation the Principal ID is used, I have described the difference between the two in “Introduction to DFINITY’s Decentralized Identity, Account and Wallet, How can developers take advantage of it? The community has different opinions about the choice of the two.
The biggest difference is the addition of a database for recording 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 transfer, casting, destruction, approve operation is recorded in an OpRecord, and there is detailed information under an OpRecord, which is convenient for users to check later.
We have talked about scaling many times before, and the same comes up again in the token standard. Because of the current need to save token transfer records in smart contracts, this would be very large data, and DFINITY currently only supports a maximum capacity of 4GB.
The ultimate solution is to implement an auto-scaling database infrastructure that will divide the data into new containers before a container’s capacity is exhausted.
This infrastructure is equivalent to a standardized database middle tier, the upper layer DApps can directly call the interface of the database middle tier, and the expansion problem of the database container is by the middle tier. At present, although there is an attempt to implement the sudograph of the database engine, he is currently more convenient for developers to customize the data type, and has not tried to automatically expand the capacity.
Of course in the short term, it is also possible to periodically pack some transaction history into external static storage and then delete the history in the DFINITY container and keep it only for a period of time. And DFINITY’s WASM may support 64-bit, which can expand the memory of a single container.
Handling fees resist spam transaction attacks
As described in “Why it’s the next generation blockchain, 8 core advantages of DFINITY! As introduced in “Why DFINITY is the next generation blockchain, 8 core advantages of DFINITY!”, DFINITY uses a reverse gas model, where users on Ether pay gas for the transactions they send, and DFINITY pays gas by deploying contracts, so ordinary users don’t need to pay a fee to enjoy the services of the contract, including token transfers, of course.
However, it can 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 manifestation on the token contract is that everyone can’t transfer money, and can even use this DDOS attack to stop everyone from trading, thus manipulating the market.
DFINITY’s ICP tokens take this into account when they are implemented, and each call to transfer money requires a fee to be deducted, and now one operation is fixed to deduct 0.0001 to prevent attacks. And the token contract can derive more interesting designs when designing.
- What coins are transferred and what coin fees are deducted. 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 a lot like the deflationary token design on ethereum.
2、Transferring coins deducts ICP as processing fee, similar to ICP’s own implementation.
3、Every computing operation on Ether has a fixed amount of gas consumption, so developers can estimate the amount of gas consumed by an operation. At present, 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 will consume, and then deduct the corresponding amount of tokens based on the transaction pairs of cycles and tokens in the exchange, so that the processing fee fully covers the transaction processing cost.
Further Optimization Removing Approve
The difference between the ETH and ERC-20 standards in the Ethernet network, and to avoid re-entry attacks, has led to 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.
Using 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.
Officially, in the AMA, it is recommended that developers use Rust to write code with higher security requirements, such as token contracts.
Managing Contract Controllers
Because DFINITY’s contract allows upgrades, the controller of the contract has more power and can even issue additional tokens and roll back operations, so it needs to manage the controller better. It is possible to assign the controller to a zero address so that the contract can never be upgraded, or to replace the controller with a DAO that can be managed collectively by the community.
Thanks to DFinance developers, 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.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/how-to-mint-your-own-token-on-dfinity-and-a-discussion-on-token-standard/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.