Interchangeable tokens in asynchronous networks

Interchangeable tokens in asynchronous networks

p align=”justify”> The adoption of EIP-20 in the Ethereum network allowed the creation of a wide range of coins based on smart contracts. The new interchangeable tokens became the basis for managing third-party blockchain projects and transferring value within the Ethereum ecosystem. The architecture of the Ethereum blockchain and the early implementation of the protocol led to some implementation flaws, for example, the smart contract of the token stores information about all owners, which greatly increases the physical size of the blockchain.

TIP-3 on the Everscale and Venom networks

Since in Everscale, an individual smart contract can only be processed in one shard, the use of one central smart contract token could greatly reduce the bandwidth of the entire network. Thus, a new approach to the implementation of smart contracts of interchangeable tokens was developed. Today, Everscale recommends writing TIP-3 tokens according to realization from our developers.

The essence of the implementation is that there is a smart contract in the network TokenRootWhich:

  • Stores token data:

    • Token name;

    • Token ticker;

    • the size of the fractional part;

    • The address of the token owner’s smart contract;

    • Token emission;

  • Allows the owner of the contract to issue new tokens;

  • Allows you to burn tokens.

  • Allows you to create wallet smart contracts and charge tokens to them using mint.

IN previous article we described the interaction of smart contracts according to the actor model, on the basis of which the Everscale and Venom blockchains are built. Smart contracts exchange messages from which smart contract methods are called. Contract TokenRoot is no exception. To use its functionality, you need to send an internal message to it. All messages sent to the contract address TokenRoot undergo validation. In case the message was sent from a smart contract whose address does not match the address of the contract owner TokenRootthis message is discarded and not processed by the smart contract.

deployWallet

Method deployWallet smart code TokenRoot can be caused by either:

function deployWallet(
     address walletOwner,
     uint128 deployWalletValue
) public override responsiblereturns (address tokenWallet) {
     require(
      walletOwner.value != 0,
      TokenErrors.WRONG_WALLET_OWNER
     );

     tvm.rawReserve(_reserve(), 0);

     tokenWallet = _deployWallet(
       _buildWalletInitData(walletOwner),
       deployWalletValue,
       msg.sender
     );

     return { 
        value: 0,
        flag: TokenMsgFlag.ALL_NOT_RESERVED,
        bounce: false 
     } tokenWallet;
    }

As a result, a new smart contract will appear in the network, on the balance of which contract tokens can be stored TokenRoot.

Sending TIP-3 tokens

The smart contract itself Wallet has all the necessary methods for managing balances, we are interested in transfer and acceptTransfer:

function transfer(
        uint128 amount,
        address recipient,
        uint128 deployWalletValue,
        address remainingGasTo,
        bool notify,
        TvmCell payload
    )
        override
        external
        onlyOwner
    {
        require(amount > 0, TokenErrors.WRONG_AMOUNT);
        require(amount <= balance_, TokenErrors.NOT_ENOUGH_BALANCE);
        require(recipient.value != 0 && recipient != owner_, TokenErrors.WRONG_RECIPIENT);

        tvm.rawReserve(_reserve(), 0);
        
        // получение кода смарт-контракта получателя
        TvmCell stateInit = _buildWalletInitData(recipient);

        address recipientWallet;

        if (deployWalletValue > 0) {
            recipientWallet = _deployWallet(stateInit, deployWalletValue, remainingGasTo);
        } else {
            recipientWallet = address(tvm.hash(stateInit));
        }

        balance_ -= amount;


        // Вызов метода acceptTransfer у контракта-получателя
        ITokenWallet(recipientWallet).acceptTransfer{ value: 0, flag: TokenMsgFlag.ALL_NOT_RESERVED, bounce: true }(
            amount,
            owner_,
            remainingGasTo,
            notify,
            payload
        );
    }

Method transfer, called by the sender, reduces the balance on the account and sends tokens to the recipient. The sender can also deploy a wallet for the recipient and send funds to him. If the receiving smart contract does not respond with a transfer processing error message, the reduced balance and transaction information is stored in the network state.

By calling the method acceptTransfer, the sender’s smart contract finds out the possibility of receiving funds by the addressee and, upon successful execution of the transaction, changes in its own balance by the number of sent tokens are stored in the code. The balance of the contract of the recipient, in case of successful execution of the transaction, the number of sent tokens increases.

function acceptTransfer(
        uint128 amount,
        address sender,
        address remainingGasTo,
        bool notify,
        TvmCell payload
    )
        override
        external
        functionID(0x67A0B95F)
    {
        // Проверка адреса контракта-отправителя
        require(msg.sender == address(tvm.hash(_buildWalletInitData(sender))), TokenErrors.SENDER_IS_NOT_VALID_WALLET);

        tvm.rawReserve(_reserve(), 2);

        balance_ += amount;

        if (notify) {
            IAcceptTokensTransferCallback(owner_).onAcceptTokensTransfer{
                value: 0,
                flag: TokenMsgFlag.ALL_NOT_RESERVED + TokenMsgFlag.IGNORE_ERRORS,
                bounce: false
            }(
                root_,
                amount,
                sender,
                msg.sender,
                remainingGasTo,
                payload
            );
        } else {
            remainingGasTo.transfer({ value: 0, flag: TokenMsgFlag.ALL_NOT_RESERVED + TokenMsgFlag.IGNORE_ERRORS, bounce: false });
        }
    }

Since transactions in Everscale and Venom are performed asynchronously, smart contracts operate on constantly changing data. Accordingly, the mechanism for complete cancellation of transaction results can be laid only at the protocol level, as is characteristic of, for example, the Ethereum blockchain, where operations are performed atomically on a previously known array of data, changes of which will occur only in the event of a successful transaction.

In TVM networks, the handling of exceptions arising during the execution of transactions and the rollback to the original state are embedded in the logic of smart contracts. TIP-3 tokens are no exception: if the acceptTransfer method cannot be processed, the smart contract sends a message that the sender’s balance change must be canceled.

Creation of wallets and validation of interactable actors

In Everscale, the smart contract address is calculated as follows:
hash (contract code + static variables)

So both the sending contract and the receiving contract know each other’s code because it is hashed into addresses, and therefore both contracts know the tokens of some TokenRoot will be transferred and that tokens of this TokenRoot legally received:

Thanks to this implementation, interaction with the smart contract of the token itself is not required, as it happens in Ethereum:

Among other things, the user of the wallet application can be sure that he receives the correct tokens, otherwise all users of this application will receive tokens of another TokenRoot contract, which will instantly highlight an error in token integration.

Distributed computing is an implementation of Everscale’s scaling mechanisms

Each user balance in one or another token is a separate smart contract, which means that with a high load on the network and the need to process transactions in several shards, smart contract data transactions can be processed by different validator nodes, which leads to scalability .

As long as the load on the network is not high, all smart contracts can be in one shard and their transactions are validated by one validator. A similar situation, only on a larger scale, is true for all synchronous blockchains, where the entire blockchain is a single shard in an asynchronous network:

However, when the load increases, synchronous networks cannot increase the number of nodes validating once and parallelize the load. In Everscale and Venom – asynchronous blockchains – shards can be divided into several, and the number of shards in one blockchain can grow up to 256 units. Accordingly, up to 256 validators can be simultaneously allocated for transaction processing.

In the animation below, it is shown how smart contracts are when there is a high load on the network TokenWallet messages are exchanged with smart contracts from other shards – the resulting transactions are processed by nodes from the corresponding groups, taking into account the logical time of transactions:

Thorough control over the amount of data in the blockchain

Since the balance of an individual token is a smart contract owned by an individual user, TokenRoot The contract does not need to store the address of each token holder.

ERC-20 tokens, in turn, store data about each owner, which leads to an infinite accumulation of data and an infinite growth of the physical size of the blockchain:

If a separate wallet contract ceases to be used, sooner or later the funds for payment storageFee will expire and the contract will first be frozen and then removed from the blockchain altogether. In this way, the problem of endless accumulation of data in the blockchain is partially solved:

With the mass adoption of blockchain technologies in the future, the requirements for scalability of networks will only increase: the possibility of asynchronous execution of transactions with tokens opens up opportunities to build a CBDC system on blockchain that scales well.

In addition, more common on-chain stablecoin operations may also require more network bandwidth for significant user growth. It is obvious that existing L1 solutions with synchronous architecture will not be able to provide adequate bandwidth and, as a result, such blockchains will use mechanisms to reduce the demand for network services, the result of which may, for example, be an excessive increase in network fees.

Related posts