ERC-1376 Service-Friendly Token
kumanoko24 opened this issue · 4 comments
eip: 1376
title: Service-Friendly Token Standard
author: Atkins Chang (@AtkinsChang), Noel Bao (@kumanoko24), Jack Chu <jack@fstk.io>, Leo Chou <leo@fstk.io>, Darren Goh <darren@fstk.io>
type: Standards Track
category: ERC
requires: 20
Service-Friendly Token Standard
Full EIP is at Service-Friendly Token Standard repo.
我們也有中文版喔！
Simple Summary
This Token standard is designed to allow Tokens to interact with service-based smart contracts and off-chain services seamlessly and without friction, providing a friendly environment for the Tokens.
Abstract
Originally designed to be a crowdfunding tool, Tokens now have a painful period of transition to being a Utility Token, to provide their service to the Token holders. Many projects and companies lack sufficient Smart Contract functionalities in their Tokens, which makes it difficult to support the fundamentals of their business venture and to apply it to real-world services and products.
The following interface designs are based on the fundamental features and aspects of a Robust Tokenisation that businesses need. This including removing the difficulties of secure bindings among smart contracts and on-chains and off-chains integration. We, FST Network based on our experience, understanding of the Token Standards that are available in the market, FST Network have made several improvements on the Token Standards aiming to build a Native Token Environment, a friendly environment for Tokens.
FST Network have also developed a Token transfer relay, which simulates blockchains in the form of smart contracts for the Tokens, and releases end-users from the need and limitation of only using Ether as transaction fee (gas fee) when making a Token transfer.
Motivation
We categorise this interface standard to the following:
- The improvements made on ERC-20
- The improvements made to make a Token service-friendly
- The improvements for Robust Tokenisation
As the most basic and most common way of controlling and storing Tokens, ERC-20 has proved to be a feasible and viable direction, however due to different implementations, such as gas consumption and mathematical safety of execution, many Tokens have suffered abuse and denial-of-service that led to financial loss.
We have made optimisation and made mathematical checks for the implementation of transfer and approve, and how to store balance and allowance efficiently.
To define a service-friendly environment, we must first identify the design goals of the payment flow and the smart contracts on the Ethereum Blockchain.
The payment flow of an Ethereum transaction:
(EA) --[tx]-> (CA 1) --[msg]-> (CA 2) --[msg]-> ... --[msg]-> (A)
The payment flow of a ERC20 Token transaction:
(EA) --[transfer]-> (A)
or
(EA) ---[approve]-> (CA)
(EA) ------[call]-> (CA) --[transferFrom EA]-> (A)
EA represents External Account
CA represents Contract Account
A represents EA and CA
Most of the current Token standards have difficulties to compose multiple continuous processes in one Ethereum transaction, in addition, the transaction must be triggered after the process of approve is done, this process is also in risk to be attacked by other smart contracts, by deliberately consuming the allowance more than the intended consumption.
From the statement above, we can see the Tokens are less direct and dynamic compared to Ether. Since Tokens are driven by smart contracts, Tokens must follow the execution process of the Ethereum transaction, which means the recipient address of a Token transfer transaction is the Token smart contract instead of to in transfer. The process and implementation of the Token transfer is not intuitive as Ether's transfer.
And because the Token ledger is within the smart contract of the Token, any mutation to the ledger (the balance and the allowance) or the logics must be designed and wrapped in the Token smart contract. Otherwise, the Token smart contract has to authorise or approve external smart contracts to extend the logic that is related to the ledger. But the former option slows down the development cycle, the latter option will increase the execution cost and security risks.
We had experienced the inconvenience during the development of smart contract module and providing modularisation services. Our goal is to make the Token payment flow described below:
(EA) --[transfer and call]-> (CA 1)
--[transfer and call]-> (CA 2)
--[transfer and call]-> (CA 3)
...
...
--[transfer and call]-> (A)
In short, we hope to make payment flow and execution flow of the Tokens are as natural as Ether's, and make the services provided by the Tokens more direct, intuitive and easier to develop, instead of setting back the business due to the inconvenience of ERC-20 Token standard.
To achieve this goal, we have improved the transferAndCall in ERC-223 and ERC-827, and ensure the receiverContract (the Service smart contract) always gets the real value and the real from (the origin of the Token transfer), and make the receiverContract unable to attack the from. We will explain this in detail later.
Moreover, what was mentioned above is not only to increase the consistency and the linking flexibility among the service-based smart contracts, making the business logic and the payment flow more modularised and secured, but to make on-chain-off-chain integrations more complete and more consistent, reducing the needs of status checking or multi-phase commit development, encouraging more developers' adoption.
As for the improvement made for Tokenisation, it is based after our service-friendly Token, and we took a step further to conduct important features for businesses such as CRM functionality and Token relay to achieve a De-Ether environment.
The important feature for CRM is compacting multiple Token transfers and making the process as light and predictable as possible, which allows businesses to have more flexibility for CRM applications.
The Token relay is to remove the biggest technical barrier, which is the need for end-users to pay Ether in a Token transfer as the transaction fee.
If the situation is in a context of that Ethereum is a decentralised computing platform and cash platform, and to execute smart contracts, the end-users must pay Ether to stablise the Ethereum network and incentivise the miners to sustain the network, then it's very rational and acceptable to everyone.
But if it is in the context of Tokens, it becomes illogical and cloggy.
The idea of "No Ether, No Token usages" obstructs the utility of Tokenisation.
So we have implemented a feature that allows the origin of a Token transfer to sign a specific Token transfer request, and the Relayers check its transfer fee (in Token) and the signature, then the Relayers relay the request by sending the request to the Token smart contract, which also means the Relayers pay the Ethereum gas fee for the request.
Then the Token smart contract checks the relayed transfers and avoid any attack among transfer origin, relayers and the receivers.
Further details are available at Service-Friendly Token Standard repo.
Specification and Rationale
Service-Friendly Token Standard repo
Backwards Compatibility
This Token Standard is fully compatible with ERC-20.
Test Cases
We have tested the Token via the scripts off-chain, and several testing smart contracts on-chain.
Service-Friendly Token source code:
https://github.com/fstnetwork/Service-Friendly-Token-Standard/blob/develop/MinServiceFriendlyToken.sol
The test cases will be open-sourced soon.
Implementation
The Token that FST Network (https://fst.network) has issued, is one example of the Service-Friendly Token mentioned above, and it is integrated with the modules that FST Network provide via our Decentralised Tokenisation Platform to form a robust service-based smart contracts.
Mainnet address (Funder Smart Token, FST):
https://etherscan.io/address/0x51c028bc9503874d74965638a4632a266d31f61f#code
Copyright
Copyright and related rights waived via CC0.
Updated format and PR link
full eip link updated !
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.