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

Reduce transaction fees #1433

Closed
Tommo-L opened this issue Feb 3, 2020 · 11 comments
Closed

Reduce transaction fees #1433

Tommo-L opened this issue Feb 3, 2020 · 11 comments
Labels
Discussion Initial issue state - proposed but not yet accepted

Comments

@Tommo-L
Copy link
Contributor

Tommo-L commented Feb 3, 2020

Background

With the large-scale development process of Neo3 and the adjustment of the economic model, compared with Neo2, the transaction fee has been significantly reduced.

But compared to Ethereum which transaction fee is about 0.003$, our transaction fee is still much more expensive than it.

Type\Fee ETH(ETH) ETH($) Neo3(GAS) Neo3($)
Normal Transaction 0.000021ETH 0.003654$ 0.0218339GAS 0.02620068$
Voting Transaction 0.000021ETH 0.003654$ 5.0227917GAS 6.02735$

ETH 174$
GAS 1.2$
Assume that the SystemFee rounding problem has been solved.

Therefore, we have discussed (@dahongfei @vang1ong7ang @wangjiachao) and hope to find a reasonable price adjustment method and set a reasonable fee price. And this is an open issue, we also hope more people can participate in the discussion.

Goal

  • Reduce fees and establish a price competitive advantage with ETH
  • Try to ensure that users holding 10+NEO (100$) can produce GAS in a short period of time to pay a normal transfer transaction (including voting transaction)

Adjustment

  • We think it will be reasonable for a user who holding 10NEO can pay a normal transaction or voting transaction by claimed GAS.

In the latest governance model (designed by Wang Yongqiang), assuming that the reward coefficient of non-voting users is r = 0.1 (recommended value)

image

Assume that, based on the current Neo3 transaction fee, set k as the price reduction. According to the analysis above, we can get 2 constraints:

image

If consider 10 times lower than the current cost of ETH, we need to satisfy k >= 74.2. At this time, the cost of a transaction is about 0.00036$ (As after ETH2.0 online, its cost will further decrease)

Suggestions

  1. The overall cost to be reduced by 100 times, and a normal transaction cost is about 0.00026$, which is 0.000218339 GAS. Then user can pay a normal transaction every 15 hours by holding 10NEO.

    Type\Fee ETH($) Neo3 (adjusted $)
    normal tranaction 0.003654$ 0.00026$
  2. There are some expensive instructions and interoperability methods, in particular the voting transaction fee which is 5GAS. In the new governance model, voting is related to the economic model, and the threshold for voting needs to be lowered.

  3. Disadvantages: The operating income of consensus nodes will decrease 100 times, and the transaction volume will need to increase 100 timesnamely 400 transactions per block, in order to balance of payments.

Neo Version

  • Neo 3

Where in the software does this update applies to?

  • SmartContract
  • Wallets
  • Transaction
@Tommo-L Tommo-L added the Discussion Initial issue state - proposed but not yet accepted label Feb 3, 2020
@shargon
Copy link
Member

shargon commented Feb 3, 2020

Agree, we should reduce the fee in order to be competitive

@vncoelho
Copy link
Member

vncoelho commented Feb 3, 2020

A change is surely needed for ensuring long-term competitiveness.
Before, the 10 GAS free tx was enough. Even with loopholes it was possible to keep the system with that.
Now, another strategy is urgent.

In addition, we need to consider staking and unifying the fees, as @igormcoelho has been mentioning.

The proposal of dBFT 3.0 also makes the consensus more open for other contributors, in particular, by allowing backups and changing it to stake instead of paying GAS, as well as ensuring an additional phase for more robust sets of proposals from primaries.

@diskooooo
Copy link
Contributor

diskooooo commented Feb 4, 2020

Agree with reducing fees thereby creating a competitive Edge. While it poses a disadvantage for consensus nodes, the network is here primarily for its users. Without users and usage, no network and no fees for CN's. One could also argue that CN's have been over-compensated for a long time already.

Also, one could start at reducing fees 10x instead of 100x initially, and take into account the possibility to dynamically adjust fees by using oracles (perhaps suitable for another issue)?

@doubiliu
Copy link
Contributor

doubiliu commented Feb 4, 2020

Why not write the price into the contract and vote for dynamic adjustments?

@i359
Copy link

i359 commented Feb 5, 2020

Normal Transaction fee 0.0001-0.001 gas is reasonable, When the layer-2 network is used, it can be adjusted up properly by vote. is it OK ?

@Tommo-L
Copy link
Contributor Author

Tommo-L commented Feb 5, 2020

Normal Transaction fee 0.0001-0.001 gas is reasonable

Agree.

Currently, we want to reduce at 100x by using ratio like in Neo2.x, and the following three interoperability methods want to be reduced more.

Interoperability methods Current price(GAS) Guide price(GAS)
Neo.Native.Tokens.NEO.Vote 5 0.08(equals to normal transaction)
Neo.Native.Tokens.NEO.GetRegisteredValidators 1 0.05
Neo.Native.Tokens.NEO.GetValidators 1 0.05

Why not write the price into the contract and vote for dynamic adjustments?

I think we can adjust the ratio is enough by writing it to policy contract.

@longfeiWan9
Copy link
Member

Totally agree with @doubiliu & @diskooooo about vote for dynamic adjustments.

It is better to design the system with flexibility and scalability comparing to fix rate which may be changed or updated in the future as the GAS price change or tx volume increase.

@doubiliu
Copy link
Contributor

doubiliu commented Feb 5, 2020

It is not difficult to implement at the virtual machine level, just load the price list and inject it when loading the script.Policy Contract can include voting function to modify the price list and persist it to the database when appropriate.The more troublesome is when to take effect, but this is a governance issue

@vncoelho
Copy link
Member

vncoelho commented Feb 5, 2020

A more trivial way to do that is to keep the proportions fixed and apply a multiplier on the Native Contract, however, this is surely not the design we should aim for in a medium/long-term. I believe that every operator should be possible to be fine-tuned by consensus nodes.

That is a good point, @doubiliu, maybe it need some time before it is applied, some couple of blocks. Otherwise, transactions on the mempool will become possible invalided or pay unnecessary fees.

This was referenced Feb 19, 2020
@Tommo-L Tommo-L closed this as completed Feb 26, 2020
@diskooooo
Copy link
Contributor

@Tommo-L why was this closed eventually (and PR's closed too)? What was decided about this? Will it be made dynamic or not?

From a Discord chat just now:

i'm just making the point that there is a giant bandaid right now that has a huge impact on the neo/gas tokenomics
if you fix the gas cost for each opcode, the gas price will have to be low for adoption of dApps
if you let the gas cost for opcodes float...the gas price can be high...and you just adjust the cost at the CN level
i'm not saying the gas price will go high or low...i'm just saying that there is a "bandaid" in neo2 so all investment in gas is speculation on what the tokenomics will eventually look like. In neo2, the tokenomics imply VERY CHEAP gas as a requirement for adoption.
in neo3, that may stay the same...or it could be completely different. :slight_smile:
the 10 free gas piece effectively covers all current utility on the neo2 blockchain...so currently ALL gas pricing is 100% speculation and 0 utility (all utility is covered by the bandaid)

There is uncertainty about this matter in the investment community, please address.

@Tommo-L
Copy link
Contributor Author

Tommo-L commented May 27, 2020

@diskooooo 😂 Sorry, I still don't know why these two pr be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants