SystemFee Distribution Adjust

[doubiliu]

SystemFee distribution adjust

​ In NEO2, GAS fees are rounded as needed, which will increase the cost of using smart contracts.

Current

​ NEO is inseparable in NEO2. GAS can be divided with 1E-8 precision. The cost of smart contract execution will be evenly distributed to all NEO holders. Its revenue = the number of NEO holdings * (mining reward + system fee) / total NEO. If there are decimals in the execution cost of the smart contract, there will be an overflow of accuracy when doing the division. Therefore, the calculation of the execution cost of the contract needs to be rounded up. ​ This processing logic increases the cost of using smart contracts.

Improve Proposals

Thanks to @canesin, @igormcoelho and other core developers for their comments and suggestions in issue #319. Based on these valuable opinions and suggestions, NGD has designed two proposals for the SystemFee distribution adjustment. Considering the issues of voting and other issues, NEO still retains its indivisible characteristics.

Proposals 1

Principle

   GAS decimals will not be changed. And the calculation of contract execution costs will not be rounded up. The integer part of each block's income GAS will be evenly distributed to all neo holders, but the decimal part will be stored as a remainder in the remainder pool and accumulated. When the remainder pool accumulates to more than 1 GAS, its integer part will be redistributed.

   Supplement: Taking into account issues such as future incentive voting, the divisor may not be a fixed value of 100 million, it may be other numbers, which will cause an inexhaustible phenomenon, so the remainder after taking the integer part will be stored in the remainder pool.

Details

a) Income distribution adjust

b) Remainder Pool

It is used to store the remainder after each distribution of GAS to prevent loss of accuracy.

Advantage & Disadvantage

Advantage

The system fee income will not be lost due to accuracy issues and will not affect the total GAS.

Disadvantage

The revenue of each block is not fully distributed, and the revenue due to users in the previous block may be transferred to the next block and distributed to other users.

Proposals 2

Principle

Similar to the traditional financial data processing method, the balance of the overflow is directly discarded. Because the balance value is relatively small, it can be almost ignored.

Details

a) GAS decimals extension

GAS decimals will be extended to 1E-16

b) Income distribution adjust

Advantage & Disadvantage

Advantage

Simple to implement.

Disadvantage

Loss of decimals affects total GAS.

Neo Version

• Neo 3

Where in the software does this update applies to?

• Other:

[i359]

Keep gas accuracy 8 unchanged, and burn overflow. is it OK? Simple to implement, and Gas is more valued for its rarity.

[shargon]

Also we can distribute this overflow to CN. the problem with Burn is that we loose the fixed maximum supply, and you shouldn't burn the token that we need for use the chain.

[erikzhang]

I vote for burning all the sys_fee, and increase the circulation of gas every year.

[vncoelho]

I think it is possible, @erikzhang, we discussed such topics here with @vang1ong7ang. It would be good if such decision is also done considering other aspects of Consensus Nodes, such as staking and claims for those who vote, as well as staking for voting, these trade-offs of game-theory were also a point of discussions during Wang Yong Qiang visit here in Brazil.

[vang1ong7ang]

I agree it is possible and reasonable. We should ensure that the circulation of gas should be more than the burned gas if we do so. And a simple model for that is u*x +v where x is the burned gas (system fee used) and u, v are two constants

[i359]

Brevity is the soul of wit.

[melanke]

I like the idea of increasing the circulation of gas every year because it may create some kind of inflation on the gas value, encouraging the use of it instead of making the users hold it, preventing sudden massive use.

[igormcoelho]

Very interesting discussion @doubiliu! I agree with @i359 on simplicity as core. For me, the simplest way is just to keep 8 precision, give integer parts and give remaining on next block (store "remaining" on the block). If Neo is integral, this field can have 8 precision, but if Neo becomes fractionary, this field can have 16 digits (still keeping GAS 8 precision). I think this is simple, because it keeps overall GAS amount calculation simple and controllable (no need to look at blockchain).

I would love to see an inflationary strategy on GAS as @erikzhang mentioned, perhaps every trimester/semester/year, it's much needed to make GAS more "freely available" to code execution. This also open doors to possibly reward dBFT 3 consensus with a fixed amount on sys_fee, like "operation fee" (MAX value voted/decided by Neo holders, or proposed beforehand when node applies as consensus candidate).

[ Sorry, it becomes longer... xD ] (even more simple: no difference between system and network fees) To be honest, I would also like to quit differentiation between system and network fees, as network fees are used more like Sybil/spam attack protection than consensus reward itself (we don't even know which consensus will get our tx). If consensus get a fixed amount (when proposed as candidates) and a fraction of execution/system fees + network fees, we could just call both fees as "fees" (no network or system), and reward consensus on NEXT block (as this will require code execution) and also give back unused fees to users. Consensus could be awarded proportionally to their "aparent" participation (decided by current primary), so if it doesn't help in XYZ previous rounds, it could not be awarded (primary will naturally get slightly more). Some thoughts, mixed with an efficient dBFT3 proposal in mind ;)

[vang1ong7ang]

@igormcoelho I have the same idea (no difference between system and network fees)

network fees are used more like Sybil/spam attack protection than consensus reward itself

[vncoelho]

I agree as well.

[shargon]

To be honest, I would also like to quit differentiation between system and network fees, as network fees are used more like Sybil/spam attack protection than consensus reward itself (we don't even know which consensus will get our tx). If consensus get a fixed amount (when proposed as candidates) and a fraction of execution/system fees + network fees, we could just call both fees as "fees" (no network or system), and reward consensus on NEXT block (as this will require code execution) and also give back unused fees to users. Consensus could be awarded proportionally to their "aparent" participation (decided by current primary), so if it doesn't help in XYZ previous rounds, it could not be awarded (primary will naturally get slightly more). Some thoughts, mixed with an efficient dBFT3 proposal in mind ;)

Agree, we can take a percentage of the fee for CN, and have only one fee field.

[doubiliu]

Since we're considering burn gas, which will fix this issue.