Discussion: Enable Energy Sponsorship for Contracts Deployed by Contracts

[kongchi-ken]

Simple Summary

This is a discussion on enabling the energy sponsorship for contracts deployed by contracts.

Motivation

TRON network has a contract energy sharing mechanism that allows the contract deployer to share some of the energy consumption of contract execution, thus provides energy sponsorship for the contract users. But this mechanism currently cannot handle the case where a contract is created by a contract.

With the continuous enrichment of smart contract application scenarios on TRON network, there are more and more cases of deploying contracts (CREATE, CREATE2) through factory contracts. Some contract developers and projects have to deploy additional contracts as transaction entry points to provide energy sponsorship for these contracts, leading to additional costs and certain inconveniences.

Extending the contract energy sharing mechanism to contracts deployed by contracts will improve the flexibility of contracts, and make it easier for developers and projects to build more complex contract systems.

Specification

I can think of two approaches to enable the energy sponsorship for contracts deployed by contracts.

1. Enable TVM to edit consume_user_resource_percent and origin_energy_limit

Because the consume_user_resource_percent and origin_energy_limit fields of a contract created by a contract are 100 and 0, indicating that 100% of the contract's execution energy consumption is borne by the user and that the contract deployer provides an upper limit of 0 energy for a single transaction.
Currently, TVM does not provide relevant commands for contracts to adjust this field.

By introducing opcodes to modify the consume_user_resource_percent and origin_energy_limit fields of a contract in TVM, factory contracts can modify these configs for child contracts, and provide energy sponsorship for child contracts.

This approach extends the TRON contract energy sharing mechanism to support the origin (deployer) of a contract is other contract, without changing the main energy share and consume logic.

2. Allow TVM execution to use the energy of the contract itself.

Another approach is to change the energy sharing mechanism from using the energy of the origin (deployer) to the contract itself.

It also may require the TVM to support the contract to change some of the new share settings.

Both approaches require allowing delegating resource to contracts.

Discussion

Any opinion on energy sharing mechanism or improvement of the mechanism is welcome, thank you.

[simbadMarino]

I agree on this proposal, this is especially needed because more and more often developers rely on Smart Factory contracts like OP said.

[barbatos2011]

Great idea! For the first approach, does that mean the root contract’s deployer will sponsor energy for all sub-contracts as well?

[abn2357]

I have a question, since a contract account cannot hold energy like an external account, so an contract can not provide energy for contract created by it, this is inconsistent with the current logic where creator provide energy for contract."

[kongchi-ken]

Great idea! For the first approach, does that mean the root contract’s deployer will sponsor energy for all sub-contracts as well?

Thank you for your comment.
But that's not the case. it's not the root contract's deployer but the root contract itself will be sponsoring energy for its sub-contracts. Because the origin of the sub-contracts is the root contract, but not the root contract's deployer.

[kongchi-ken]

I have a question, since a contract account cannot hold energy like an external account, so an contract can not provide energy for contract created by it, this is inconsistent with the current logic where creator provide energy for contract."

Thank you for your comment.

That's a good question. Actually, since the FreezeV2 is online, contracts are holding energy, such as sTRX contract. Once a contract freeze it's balance for energy, it's holding these energy, and it can delegate these energy to EOAs, just as how the sTRX energy market runs.

Currently, delegating energy to contracts is not allowed, but contracts can obtain energy by freezeV2 directly, and can delegate resource to EOAs.

The first approach requires allow delegating energy to contracts, as freezing for energy is not suitable for all root contracts, and it will be more flexible for contracts to obtain energy. For now, I didn't think of any problem would be caused by allowing delegating energy to contracts.

[abn2357]

I have a question, since a contract account cannot hold energy like an external account, so an contract can not provide energy for contract created by it, this is inconsistent with the current logic where creator provide energy for contract."

Thank you for your comment.

That's a good question. Actually, since the FreezeV2 is online, contracts are holding energy, such as sTRX contract. Once a contract freeze it's balance for energy, it's holding these energy, and it can delegate these energy to EOAs, just as how the sTRX energy market runs.

Currently, delegating energy to contracts is not allowed, but contracts can obtain energy by freezeV2 directly, and can delegate resource to EOAs.

The first approach requires allow delegating energy to contracts, as freezing for energy is not suitable for all root contracts, and it will be more flexible for contracts to obtain energy. For now, I didn't think of any problem would be caused by allowing delegating energy to contracts.

You're right. After reading the related freeze source code / delegate source code and tip of stake enabled in smart contract , indeed, only delegate has restrictions on the receive address, while freeze imposes no limits on the owner address. But why does delegate restrict the receive address? Perhaps there were some prior considerations—let's wait for other developers' opinion. Either way, I think this tip itself is quite meaningful.

[bladehan1]

Solution 1: The factory contract provides energy for the sub-contract
Solution 2: The sub-contract manages energy independently. If there are multiple sub-contracts, they need to manage the energy distribution by themselves

It is essentially a problem of the contract energy source address.
It seems that adding the contract energy source field allows users to design the energy management method of different contracts by themselves, which can flexibly meet the scenarios of solutions 1 and 2. However, the blockchain should remain simple and add fewer additional fields.

Since the contract can hold energy as an address, it should also be able to be delegated energy. From this perspective, it can meet the needs without adding anything extra.

[onm798]

I think this advice can be very helpful, but I have several questions for the details.

1. To edit the consume_user_resource_percent and origin_energy_limit of a contract, how many opcodes will be introduced? Will the two fields be changed in one command or in two seperate commands? And is there any candidates opcode for this? I think there isn't much opcode choice left, and maybe some of the slots are reserved for potential purpose?

2. What about the previously deployed contracts? If the sub contracts or factory contracts are not upgradable, can the sub contracts get energy sponsor?

[simbadMarino]

Is this solution enabling contracts to receive energy/bandwidth from EOAs or another contract as wel? If not, was this possibility discussed in the past?

[kongchi-ken]

I think this advice can be very helpful, but I have several questions for the details.

1. To edit the consume_user_resource_percent and origin_energy_limit of a contract, how many opcodes will be introduced? Will the two fields be changed in one command or in two seperate commands? And is there any candidates opcode for this? I think there isn't much opcode choice left, and maybe some of the slots are reserved for potential purpose?
2. What about the previously deployed contracts? If the sub contracts or factory contracts are not upgradable, can the sub contracts get energy sponsor?

1. I think the two fields should be modified separately, as it's the same with system contracts and can provide more flexibility.
   As for how many opcodes should be introduced, I think we can introduce two opcodes SET_RESOURCE_PERCENT and SET_ORIGIN_ENERGY_LIMIT with each one responsible for one field. This is more intuitive but less scalable and takes two opcode slots. Or, we can introduce only one opcode such as SET_CONTRACT_PROPERTY, which receives an extra key and value, and the extra key can be used to distinguish the field to be configured. This is less intuitive but more scalable and takes only one opcode slot.
   As for the opcode, currently 0xb0 - 0xcf and 0xe0 - 0xef are available, 0xef is used for EOA delegation. Maybe we can use 0xe0 (maybe plus 0xe1) for the rational functions.

2. If the previous deployed sub contracts and their deployer contracts are not upgradable, they can not get energy sponsor. Because the consume_user_resource_percent and origin_energy_limit of a deployed contracts are default values, which makes the contract can only use user resources. Only after the issue gets online, and the contracts upgrade its implementation and set the fields, the sub contracts can get energy sponsor.

[kongchi-ken]

Is this solution enabling contracts to receive energy/bandwidth from EOAs or another contract as wel? If not, was this possibility discussed in the past?

Yes. Enabling contracts to receive energy and bandwidth from resource delegation is part of this solution.

[waynercheung]

Hi @kongchi-ken , if EOA-a deployed a Contract_b, and Contract_b can create other contracts such as Contract_c , in your approach, when trigger Contract_c, Contract_b will pay for the energy firstly according to the consume_user_resource_percent and origin_energy_limit set to Contract_c, right?

[kongchi-ken]

Hi @kongchi-ken , if EOA-a deployed a Contract_b, and Contract_b can create other contracts such as Contract_c , in your approach, when trigger Contract_c, Contract_b will pay for the energy firstly according to the consume_user_resource_percent and origin_energy_limit set to Contract_c, right?

Yes, and this is the current execution logic.
But currently there is no way to edit the consume_user_resource_percent and origin_energy_limit of Contract_c, leaving the value as default (100 and 0), which makes the Contract_b can only pay zero for Contract_c execution.

The first approach is to enable Contract_b to edit the consume_user_resource_percent and origin_energy_limit of Contract_c. After that, Contract_b can actually pay for the energy of Contract_c execution (according to the configs).

[waynercheung]

@kongchi-ken For the same scenario, what about the second approach?