Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TRC-54: Automatically active non-existent account when transferring TRX/TRC10 asset in smart contract #54

Closed
jeancky opened this issue Aug 9, 2019 · 4 comments

Comments

@jeancky
Copy link

commented Aug 9, 2019

tip: 54
title: TRC-54: Automatically active non-existent account when transferring TRX/TRC10 asset in a smart contract
author: Jeancky <jiangxinjian@tron.network>
discussions to: https://github.com/tronprotocol/TIPs/issues/54
category: TRC
status: accepted
created: 2019-08-09

Abstract

Currently in TRON's smart contract, when transferring to a non-existent address, the transaction will be failed. This may cause inconvenience to some DApp developers. Let's discuss whether automatic creation of non-existent address should be allowed during contract transfer. Of course, contract caller need to pay the corresponding fee.

Motivation

At TRON, when these system GRpc API transferContract, transferAssetContract are called, an non-existent address is automatically activated. However, when transferring with transfer and transferToken in a smart contract, the non-existing address is not automatically activated. This can make the user experience inconsistent, and it can also cause problems for developers.

Specification

Before implementing this function, we need to consider that when the address is activated, the instruction will charge an additional 0.1 TRX fee.

There are many ways to do this, here are two possible ways:

  1. Directly modify the semantics of transfer, transferToken, allowing the creation of non-existing addresses. Its drawback is that it may affect contracts that have relied on the "contract will be reverted when transfer to non-existing address" feature. Bringing unknown risks to them.

  2. Adding a new auto-activation instruction in the new TRON solidity compiler, and let the compiler to automatically insert this instruction before transfer/transferToken when generating bytecode. This method allows a version to support this behavior. But when compiled with an old compiler, it will never be supported.

Rationale

In terms of instruction charging, the energy price is an adjustable variable. How to accurately charge 0.1TRX needs to be discussed.

Regardless of the implementation method, we need to consider whether it will have an unknown impact on existing contracts. Also be consistent with the GRPC API.

Backwards Compatibility

  1. In terms of energy consumption, it needs to be consistent with the system GRPC interface.

  2. If we want to do that, we need to review the impact of each implementation on existing contracts.

  3. One of these implementations relies on TRON's Solidity compiler update, which is not compatible with historical compiler versions.

@Sh11thead

This comment has been minimized.

Copy link
Member

commented Aug 26, 2019

Need to consider that:
Is there contract that relies on "transaction would fail when contract transfer to an un-exist address" feature ,that would bring bad effect to them.

And we need to discuss about the fee ,Energy is the only cost in TVM

@jeancky

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

Since non-exist is just a temporary state of the address. Someone may active the address through transfer at anytime. So, it is not reliable. I don't think we need to consider this kind of usage.

@jeancky

This comment has been minimized.

Copy link
Author

commented Aug 27, 2019

About fee. TVM only consume Energy while executing. I think it will enough that we charge the energy cost equivalent to 0.1 trx. That is 10000 energy. What do you think @Sh11thead

@Sh11thead

This comment has been minimized.

Copy link
Member

commented Aug 27, 2019

@jeancky Agreed.
For now , in TVM , sending to non-exist address always causes a TRANSFER_FAID resltcode whether using function transfer transferToken send , It doesn't seem proper , also breaks the function send orgin usage which should not throw any error
We need to deal with this problem.

@jeancky jeancky changed the title TRC-54: Automatically create a non-existent address when transferring TRX/TRC10 asset in a smart contract TRC-54: Automatically create non-existent address when transferring TRX/TRC10 asset in smart contract Sep 10, 2019
@jeancky jeancky changed the title TRC-54: Automatically create non-existent address when transferring TRX/TRC10 asset in smart contract TRC-54: Automatically active non-existent address when transferring TRX/TRC10 asset in smart contract Sep 17, 2019
@jeancky jeancky changed the title TRC-54: Automatically active non-existent address when transferring TRX/TRC10 asset in smart contract TRC-54: Automatically active non-existent account when transferring TRX/TRC10 asset in smart contract Sep 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.