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

An implementation for fractional gas on system fees #692

Closed
igormcoelho opened this issue Apr 7, 2019 · 2 comments
Closed

An implementation for fractional gas on system fees #692

igormcoelho opened this issue Apr 7, 2019 · 2 comments
Labels
discussion Initial issue state - proposed but not yet accepted 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

Comments

@igormcoelho
Copy link
Contributor

igormcoelho commented Apr 7, 2019

As discussed on #319, and also explained here #326 (comment) it is feasible to implement fractional (divisible) gas fees (without making Neo divisible) in the following way.

The proposed idea won't change any block format and it is fully backwards compatible, to be implemented as soon as possible.

Currently, only integer system fees are allowed, due to a control on InvocationTransaction. On Blockchain file, the computation of system fees just aggregate the values on transactions, storing that on SystemFeeAmount inside Snapshot (which will also be integer). This is needed to be integer, otherwise it will break calculation of redistribution (becoming smaller than Fixed8). So, to allow divisible system fee and to redistribute only integer gas, the proposal is to:

  • redistribute the integer part (as usually done)
  • store the fractional part and aggregate it on future blocks, until it gets integer

To publicly store this information, the proposal is to deploy a Validators Contract (as discussed #686 (comment)), and create a storage key on this contract regarding FractionalSystemFee.
Example:

  • invoketx1 has system_fee = 4 GAS
  • invoketx2 has system_fee = 3.7 GAS
  • invoketx3 has system_fee = 5.5 GAS
    Suppose that contract storage FractionalSystemFee has zero GAS, the total system_fee value passed to snapshot will be: floor(0 + 4 + 3.7 + 5.5) = floor(13.2) = 13
    The exceeding value of 0.2 will be stored again on FractionalSystemFee.

To put this into production, it will be easy, as long as the following steps are done:

  1. InvocationTx keeps blocking fractional gas
  2. Validators contract is deployed
  3. Consensus Nodes are updated to process fractional Gas
  4. InvocationTx starts to allow fractional gas

The deployed contract can have this format (using #690):

# standard entrypoint Main(string operation, object[] args)
JMPIF ... # verify if operation is 'storage_write', otherwise user is free to read data using function `storage_read`
# verify authorization to write
GetValidatorsScript
Hash160
Runtime.CheckWitness
# now only CN will execute this part
Storage.Put Global_variable_prefix+args[0]  args[1] # FractionalSystemFee value

This way, we can have this feature already on Neo 2.X, and prepare ground for improved fee system on 3.0.

@erikzhang
Copy link
Member

There is no need to store anything for fractional gas on system fees. We can accept that the total amount of gas is not exactly equal to 100 million. (A small amount of less than 100 million is acceptable.)

@erikzhang erikzhang added the discussion Initial issue state - proposed but not yet accepted label Apr 8, 2019
@igormcoelho
Copy link
Contributor Author

I get your point @erikzhang , and in fact, there are nice proposals for actually make it explicitly inflationary/deflationary. However, I would prefer to keep the precise amount redistributed, and to adopt another explicit and calculated equation to produce that behavior.

@erikzhang erikzhang added this to the NEO 3.0 milestone Apr 8, 2019
@lock9 lock9 added 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 labels Aug 12, 2019
@lock9 lock9 added this to Backlog in NEO 3 Releases Aug 12, 2019
@erikzhang erikzhang removed this from the NEO 3.0 milestone Dec 6, 2019
Thacryba pushed a commit to simplitech/neo that referenced this issue Feb 17, 2020
* Update v2.9.2.md

* Update v2.9.2.md

* images

* updates for EN
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 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
Projects
Development

No branches or pull requests

3 participants