As for the “authorization” operation, many new Ethereum users are confused when they first operate the smart contract. I don’t understand what authorization is, let alone why authorization initiates a transaction, and the transaction itself does not carry any assets, and at the same time, it has to pay a miner’s fee.
In this article, we will explain the nature of “authorization” operation from the perspective of technology.
When users interact with Ethereum smart contract token assets, they must first approve. So, why do you need authorization?
Let’s give an example of a miners’ quotation for nest oracle:
- Bob is a nest price maker. When he participates in the ETH/USDT price prediction machine quotation, he needs to transfer the ETH and USDT assets into the quotation contract according to his own quotation data. Here, it is assumed that 10 ETH and 1600 USDT are used to conduct a quotation operation.
- Then Bob must first authorize the USDT asset to the quotation contract of nest Oracle, so that the quotation contract has the authority to operate the USDT asset in Bob’s wallet, so that the transaction logic related to USDT asset can be executed smoothly when the verifier takes the order within the quotation life cycle.
- Authorization here is essentially an on chain transaction, requiring users to pay miners’ fees (Gas fees). The purpose is to tell the USDT token contract that target smart contract a has the right to control the number of USDT assets in my wallet X. Then, when the target contract A needs to conduct USDT transactions, it will take the initiative to obtain no more than x USDT assets from the USDT token contract.
However, in the above case, another question arises. Why only ERC20 tokens such as USDT need to be authorized while ETH does not?
Technical analysis: because ETH is the native asset of Ethereum network, when transferring money to the target smart contract, the underlying layer of Ethereum network forces the target contract to have a certain receiving method, so the transaction itself can carry ETH assets into the target contract; while ERC20 token only changes the ERC20 token when transferring to the target contract The target contract will not receive any notice for the account book information of the contract itself.
Therefore, ETH does not need authorization operations like ERC20 token when it interacts with smart contracts.
To be exact, there are two steps in the authorization operation:
Step 1: authorize the transaction itself. It is to tell an ERC20 token contract that in the future, a target smart contract address a may come to my wallet account to take x quantity of token assets;
Step 2: the transaction execution itself. When the logic execution in the target contract A requires the token transaction, contract a will take the initiative to trigger the transfer transaction of ERC20 token to take away the X quantity of the token; on the contrary, if the transaction of the token is not involved, even if it has been authorized, the asset transaction will not really occur.
In short, after the authorization operation, the token transaction is not necessarily executed, but such a fund operation authority is reserved for the target contract A.
In order to avoid users’ repeated authorization operations, many smart contract developers usually set the maximum number of tokens authorized to the target smart contract by default. Obviously, there are certain risks in this way. If there is a loophole in the smart contract or the contract administrator does something evil, the user’s token assets will be lost, which is the problem caused by “over authorization“.
Whether in NEST DAPP or imToken wallet, we often encounter this problem.
In order to solve the problem of “over authorization”, NEST DAPP has an authorization management page. If a miner does not expect to participate in NEST Oracle quotation in a short time, he can “cancel authorization” to eliminate the security problems caused by existing authorization. imToken wallet also takes some measures, such as “clear authorization information” for each authorization, and has an exclusive DAPP for authorization management, so that users can freely manage their existing authorization.
The feasibility scheme of skipping authorization operation: by implementing specific transfer logic in ERC20 token contract, that is, a method of forcibly invoking the target contract while transferring money, the current authorization operation can be avoided. However, in order to keep the purity of token contract, the mainstream ERC20 token does not implement this function.