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

[NEO2/3] Allow divisible GAS fees without making NEO divisible (higher unit supply) #319

Closed
canesin opened this issue Jul 16, 2018 · 26 comments
Labels
design Issue state - Feature accepted but the solution requires a design before being implemented enhancement Type - Changes that may affect performance, usability or add new features to existing modules. ledger Module - The ledger is our 'database', this is used to tag changes about how we store information vm New features that affect the Neo Virtual Machine or the Interop layer

Comments

@canesin
Copy link
Contributor

canesin commented Jul 16, 2018

Idea:

System fees would be aggregated by block and divided in two portions, integer and remainder (simple mod operation), remainders would be re-added as sys fees to the next block, so if the aggregate sys fees in a block are X.Y GAS than X is distributed to NEO holders as it is today (1e-8 each) and Y is moved to next block sys fee to be mod again, making it a recursive distribution of the integer part and never blocking more than 0.999* GAS.

Justification:

This will allow the use of better fee structure for GAS costs (storage and computation) without making huge changes in current economic model for NEO.

What it improves upon the current design:

Current proposal is to make NEO divisible, something that in practice means increasing the supply of the basic unit and will have huge impacts on the network. The current supply has already shown to be good for distribution of governance power. It preserves all advantages of existing system.

Additional to that making NEO divisible will make voting systems complex, this proposal keep the voting unit.

What are the possible drawbacks and how to mitigate:

Computational cost can be minimized if the X.Y separation is done when blocks are forged, so when claims are made it is no different than current system.

[EDIT] This proposal was edited to not redistribute the remainder as net_fee but push it as sys_fee on next block, effectively not distributing funds to consensus nodes

This proposal could be readily applied to NEO2 and solve current pain points in the community. The intent is to carry it over to NEO3 avoiding the need to make the governance token divisible, keeping more in line with original intent of the dual-token model.

@canesin canesin changed the title [NEO2][NEO3] Allow divisible GAS fees without making NEO divisible (higher unit supply) [NEO2/3] Allow divisible GAS fees without making NEO divisible (higher unit supply) Jul 16, 2018
@Flankarooo
Copy link

+1 !

@erikzhang erikzhang added the enhancement Type - Changes that may affect performance, usability or add new features to existing modules. label Jul 16, 2018
@erikzhang erikzhang added this to the NEO 3.0 milestone Jul 16, 2018
@EdgeDLT
Copy link

EdgeDLT commented Jul 16, 2018

Great suggestion, full support. I really like that this will give us a way to incentivize consensus nodes, we shouldn't rely solely on goodwill for a stable, honest network.

@vncoelho
Copy link
Member

Hi, Canesin.

About the fees, I did not get the logic very well.
If the fee is "A.B", then, A goes to Sys. fees and B to Net fees?
EX:
"1.99" GAS, then, 1 goes to Sys. fees and 0.99 to Net fees?

It could be a little strange. I think that the network fee should be the costs of the execution of each TX. Sys. fees should be only services related to registration and maintenance, right?

@vncoelho
Copy link
Member

vncoelho commented Jul 16, 2018

Regarding the Neo divisibility, I also think so, Canesin.
I think that it should be re-discussed later in the future, in 3-4 years, or something like that. Not now.
If we look deep, it has some impacts on the Ecosystem.

If it is just related to voting, perhaps a SC could allow someone to split their Neo voting power into several decimal units, if someones wants to decentralized his decision making.

@EdgeDLT
Copy link

EdgeDLT commented Jul 16, 2018

@vncoelho

Not quite. Total GAS fees from system calls = A.B

A is distributed to all NEO holders as part of their usual distribution.

B is classed as a network fee and is paid to consensus nodes as an incentive for helping with validation.

So if a block had 50.9 GAS of sys_fees, NEO holders would receive their split of 50, and consensus nodes would receive a split of 0.9. Because only the remainder is distributed to consensus nodes, they would never get more than .99* GAS split between them per block, which is works out to be pretty fair.

One of @erikzhang's reasons for making NEO divisible was because you can't distribute decimal GAS to 100M NEO; you'd need a higher precision for GAS. With Canesin's solution, only consensus nodes would receive the decimal portion of GAS, and because there are a lot less of them, there's no problem distributing it without going beyond 8 decimal places. In reality each node would receive 1-3 decimal places worth of GAS per block, depending on the number of CNs.

@vncoelho
Copy link
Member

Thanks, @Edgegasm.
I was not aware about this difficulty of distributing decimal Gas to Neo Holders. Thus, Canesin solution is simple and works, as expected from him...eahuehauea

Following this reasoning, CN would keep performing their "job" for "free", right? Which network fees would they receive? A per-agreed network fee for each Primary Speaker (the one who creates the MinerTX), that was previously agreed during the voting phase?

@EdgeDLT
Copy link

EdgeDLT commented Jul 16, 2018

Currently, consensus nodes can only earn fees from enabling transaction fees, but competition to run nodes will keep those tx_fees low or non-existent.

This is good for the average NEO users because it means they can essentially trade for free, but it means consensus nodes will operating at a loss and only doing so based on goodwill for the network (maybe a dApp developer runs a node at a loss because it earns them respect from the community for example).

So this approach will actually give an economic incentive to CNs that they don't currently have. To my knowledge, there are no other ways for them to get any fees on the current model. So right now they are doing their job for free, but Canesin's solution to GAS distribution will also give them a slight GAS reward for participation. As for how the network fee itself is distributed, I think it should just be shared equally amongst all nodes that participate in the validation for any particular block. This can be discussed further though.

Because the reward is pretty low, at most it will probably let them break even on costs or maybe profit very slightly over a long period of time. So it shouldn't incentivize malicious nodes, but it will keep things fair for everyone.

@t-ant8
Copy link

t-ant8 commented Jul 16, 2018

Issue:
The overall idea is very good, however I do see an issue in the concept of X.Y GAS splitting for NEO holders and CNs.
• The amount of .Y is random, which gives CNs an incentive based “on luck”. In one block CNs will receive .99 GAS and in another, they might receive .01 GAS. I don’t think this model is attractive for CNs as an incentive.

Proposal:
I would rather propose a distribution model, which is less random, and in the same motivates more enterprises / people to run a CN, i.e. to promote decentralization. A GAS-distribution based on “CN network-effect”, i.e. the more CNs running, the higher the GAS-distribution.
• Let’s say, we keep a large chunk of sys_fee for NEO holders. So maximal 20% of the collected GAS within a block shall be distributed: The formula could be a tanh-like function, e.g. GAS_for_CNs = 0.2 * collected_GAS * tanh(y*x), where x = number of CNs and y = tuning parameter for the steepness of the curve (e.g. saturated when 1000 CNs).
This motivates the existing CNs to promote others to join the CN-network and keep decentralization maximized. However, the technical feasibility of this implementation is not discussed.

@toghrulmaharram
Copy link

@canesin There is a possible attack vector to this approach. The Speaker node could pick-and-choose the transactions to his/her liking to maximize the profitability of the forged block by bringing the sys_fee remainder closer to .99 which means that some transactions at any given moment could be disadvantaged.

@toghrulmaharram
Copy link

@t-ant8 Anything above the 50 (technically, 49) mark is going to have an impact on the efficiency of the consensus (though the official specification puts the maximum number of suppoted nodes at 100, for some strange reason).

@t-ant8
Copy link

t-ant8 commented Jul 16, 2018

@toghrulmaharramov thanks for the info, didn't know that. However, any number in the proposal are arbitrarily chosen. I think, 20% of the collected GAS-fee is also too high.

But the idea is to maintain a high number of CNs (40,50 CNs etc.), and to motivate enterprises / people running CN to further promote the NEO ecosystem by rewarding them with more GAS, as more CNs join-in and more projects run on NEO blockchain.

@toghrulmaharram
Copy link

The idea is to ditch the dBFT consensus protocol altogether and to switch to something more efficient like hbbft.

@canesin
Copy link
Contributor Author

canesin commented Jul 16, 2018

@t-ant8 this is not a proposal for CN incentive, this are sys_fees paid in the block and fees in a block will always be "random". The motivation is to allow fractional fees on sys_fees, currently the sys_fee can only be on GAS integers since it has to be claimable. This leads to everyone optimizing for the 10 free GAS not only because it is free but because the next step in fees is 1 GAS, too expensive. This will allow it to be 0.0000001 for example. However as @Edgegasm noted it does give a incentive, which are not very different of network fees, one way to see this is that while net_fees reward work done to prioritize and forge blocks the Y fee would be the fee to redistribute sys_fee GAS across the network.

@toghrulmaharramov that attack is not possible, all nodes should sort equally (currently total_fee/msg_size than time), the speaker would be Byzantine and another would be selected.

@toghrulmaharram
Copy link

@canesin Nothing stops the Speaker from choosing the transactions that suit his/her agenda, later claiming that the ones not included to the block proposal were not propagated to his/her node in time to be included. I don't understand how sorting relates to this.

@neo-project neo-project deleted a comment from Flankarooo Jul 17, 2018
@mwherman2000
Copy link

mwherman2000 commented Jul 17, 2018

Not quite. Total GAS fees from system calls = A.B

A is distributed to all NEO holders as part of their usual distribution.

B is classed as a network fee and is paid to consensus nodes as an incentive for helping with validation.

So if a block had 50.9 GAS of sys_fees, NEO holders would receive their split of 50, and consensus nodes would receive a split of 0.9. Because only the remainder is distributed to consensus nodes, they would never get more than .99* GAS split between them per block, which is works out to be pretty fair.

@Edgegasm, is this intended to applied before or after GAS fee discounting? ...esp. for the B portion?

@mwherman2000
Copy link

mwherman2000 commented Jul 17, 2018

• The amount of .Y is random, which gives CNs an incentive based “on luck”. In one block CNs will receive .99 GAS and in another, they might receive .01 GAS. I don’t think this model is attractive for CNs as an incentive.

@t-ant8 You can't look at this from the perspective of individual transactions (you can but it doesn't make sense statistically). Over the medium/long-term (say 1000+ Tx), .Y is going to have a random distribution, so...

  1. Every CN will ultimately receive the same benefit
  2. Because of the properties of a random distribution, why not simply give each CN 0.5 GAS per Tx? It produces the same result. #KISS

@Sinepitiss
Copy link

Sinepitiss commented Jul 19, 2018

@toghrulmaharramov well as @mwherman2000 mentioned random distribution should in the end make an average result that keeps getting closer to ~0.5 GAS ,which means it shouldn't be hard to see which nodes have an usually high remainder which would be a big hit to their credibility and would probably result in that consensus node losing all support(or nodes if they run multiple).Which would make them loss in the long run.And as we know credibility is very important in any blockchain.

Well if we wanted to make 100% sure that CN receive close to stable income and they wouldn't have incentive to cheat I would suggest this: remainder of GAS goes to a seperate pool and that pool sends out 0.5 GAS to be redistributed ,the 0.5 value changes only on two occasions:
1.The pool has less than 0.5 GAS then it distributes what it has and saves the amount it owes
2.The pool owes to the consensus nodes ,then it'll send out what it owes+0.5.

Is it absolutely necessary?I think not ,but I'm throwing it in for the sake of brainstorming.

This addition would provide the following :
1.There is no reason for CN to manipulate which transactions they process
2.CN holders in 99.999999% get the same amount of GAS

@EdgeDLT
Copy link

EdgeDLT commented Jul 19, 2018

General consensus so far seems to be that a 0.5 GAS per block average is a too high, and a bit of maths shows us why.

Assume 100 nodes, call it an average of 0.005 GAS per node per block. 15 seconds blocks would mean 5760 blocks a day, or 28.8 GAS per node. At $10 per GAS, that's $288 a day or $105,120 a year.

Any decrease in block time, decrease in number of nodes or increase in GAS price turns that from an already ridiculous figure into something insane.

I still like the concept for the purpose of incentivizing nodes and dealing with decimal GAS in sys_fees, but this is already way over-tuned. We need to balance it somehow @canesin.

@erikzhang erikzhang added discussion Initial issue state - proposed but not yet accepted and removed enhancement Type - Changes that may affect performance, usability or add new features to existing modules. labels Aug 4, 2018
@igormcoelho
Copy link
Contributor

Don't get me wrong @canesin, I like your idea for solving the problem, but I think the second fractional part should just be kept for adding up in future blocks until it gets integer (discussed this in @saltyskip proposal).
And I dont think consensus nodes will ever need monetary incentive, and shouldnt have until we are able to vote. Let me explain why. If we could vote right now I would be interested in running a consensus node for free, and Im just a random brazilian guy. The prices to hold one seem accessible to me, and if I need money, Im sure the community will donate for me to keep it running. So imagine how many computing companies will want to run one for "free" right now (just for the propaganda and network influence) , I imagine thousands at least, and we dont need thousands of cnsensus nodes. Voting will solve this for sure, people will fight to host a free CN.

@igormcoelho
Copy link
Contributor

Another point is that bigger NEO holders should want to run CN , even to guarantee their value, and they will receive gas as everyone else, so more and more reasons for "free" CN.

@canesin
Copy link
Contributor Author

canesin commented Aug 8, 2018

I am not against moving the remainder of GAS being redistributed also. The spirit of the proposal was to solve a pressing issue today (the fee structure needs the possibility of charging fractional GAS fees as soon as possible) in a way that is clear how to implement today also (just re-assign the fees as needed).

Updated the issue to reflect that, I propose that instead of keeping track of a dedicated pool make the distribution process itself as a dynamic pool. So from X.Y we just move X to redistribute and add Y again as sys fee to next block.

@igormcoelho
Copy link
Contributor

Congratulations @canesin and @saltyskip, I think it's quite possible and easy to implement this way right now. @canesin I think it would be better if you re-edit the post, keep the original idea of passing the second part to the consensus, and put an "[edit]" or "[update]" below it, with the new discussed idea... otherwise some conversations here will not make sense hahaha

@lerider
Copy link

lerider commented Aug 9, 2018

I'm in favor of adding up the fraction and distributing once it is an integer.

I'm not in favor of distributing the fraction to CN's as this can be a very high economic incentive to run a CN (which I don't see desired because of conflict of interest with users).

@lock9
Copy link
Contributor

lock9 commented Jul 18, 2019

@neo-project/core
Help, please.
Is this needed for neo 3?
It seemed very important at the moment but it looks it won't be added to neo 2, only neo 3.
Can someone confirm?
Thanks

@canesin
Copy link
Contributor Author

canesin commented Jul 31, 2019

@lock9 with the change to NEO3 @erikzhang was remembering that if the supply is not fixed in exactly 100,000,000 GAS it could be fractional. I don't know exactly that he meant by that without the use of a pool, since each NEO would be below 1E-8, I am probably missing something in the math but @igormcoelho appears to have understood.

@lock9 lock9 added design Issue state - Feature accepted but the solution requires a design before being implemented ledger Module - The ledger is our 'database', this is used to tag changes about how we store information vm New features that affect the Neo Virtual Machine or the Interop layer enhancement Type - Changes that may affect performance, usability or add new features to existing modules. and removed discussion Initial issue state - proposed but not yet accepted labels Aug 11, 2019
Thacryba pushed a commit to simplitech/neo that referenced this issue Feb 17, 2020
@canesin
Copy link
Contributor Author

canesin commented Jun 1, 2020

@erikzhang I think this can be closed with the new inflation syste on NEO3.

@canesin canesin closed this as completed Jun 1, 2020
@erikzhang erikzhang removed this from the NEO 3.0 milestone Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Issue state - Feature accepted but the solution requires a design before being implemented enhancement Type - Changes that may affect performance, usability or add new features to existing modules. ledger Module - The ledger is our 'database', this is used to tag changes about how we store information vm New features that affect the Neo Virtual Machine or the Interop layer
Projects
None yet
Development

No branches or pull requests