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

Adjusting the system pricing model #286

Closed
erikzhang opened this issue Jun 25, 2018 · 29 comments
Closed

Adjusting the system pricing model #286

erikzhang opened this issue Jun 25, 2018 · 29 comments
Milestone

Comments

@erikzhang
Copy link
Member

@erikzhang erikzhang commented Jun 25, 2018

  • Modify the contract storage pricing model
    Now the price of the contract storage is fixed. We plan to modify it to refer to a number of incremental charging patterns as the storage capacity expands, encouraging the deletion of old data.

  • Significantly reduce the cost of smart contracts
    Gas prices have been rising 100 times-fold since the old charges were made at a very low price. The gas will be difficult to apply if the fee standard is not modified.

  • Cancel the free smart contract execution
    Now every time a smart contract is executed, the first 10 gas of the costs are waived. This can result in limited use of gas. Since Neo's holders can get free gas, they should be allowed to spend gas to use smart contracts.
    Oppose: #286 (comment)

  • A limited number/size of free transactions
    Each block allows only a limited number of free transactions to be confirmed, and if this amount is exceeded, the excess transactions are queued to the next block confirmation process. If a free transaction is not confirmed in a certain number of blocks, it will be discarded.

@deanpress
Copy link

@deanpress deanpress commented Jun 25, 2018

Regarding the GAS fee for invocations; If every single invocation will end up costing GAS, NEO could lose an amount of use cases for its smart contracts (gaming/messaging/voting).

If holding a small amount of NEO is sufficient to generate enough GAS for invoking an optimized smart contract every block it will be less of a problem (given that GAS claims happen at least semi-automatically).

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 25, 2018

If holding a small amount of NEO is enough to generate enough GAS to invoke an optimized smart contract every block it will be less of a problem (given that GAS claims happen at least semi-automatically).

Yes, this will be one of the basis for the new pricing model design.

@anthdm
Copy link

@anthdm anthdm commented Jun 25, 2018

I think its time to research the use of state channels on the NEO blockchain. Wich allows us to use real-time processing ofchain and only send one transaction for validation and confirmation.

@canesin
Copy link
Contributor

@canesin canesin commented Jun 25, 2018

We still need to limit the size of free transactions on this setup, what about exploring instead of a budget on the number of free tx per block a maximum block size on the free portion.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 25, 2018

We still need to limit the size of free transactions on this setup.

You are right. I edited the proposal.

@DaveOnBlocks
Copy link
Contributor

@DaveOnBlocks DaveOnBlocks commented Jun 25, 2018

Each point may be better split up into several issues to promote discussion on each one. I apologize for the length of this post.

Overall
How would this impact existing contracts? Seems like these changes could/will drastically hurt existing projects already deployed to the blockchain. Throwing out the existing model that people have put a lot of work into is a big determent to me and would turn me off the platform. Who knows what future change to NEO will wreck my investment into my project.

I assume the purpose of this is to start having GAS be spent instead of held. I know all my contracts are designed to fall under the 10 GAS limit and we only spend GAS during the deployment. With only 55 contracts on the network that means that (aprox) 27,000 GAS has been recirculated back into the economy. The average user is then holding this as a secondary store of value.

Modify the contract storage pricing model
Would be nice to prevent abuse. Would Storage.Put() have a different cost based on how much data was done in that operation? Or would it work that if I have 2kb of data stored and add a small bit of data I would be charged 1 GAS but if I had 10,000kb of data and made a small addition I would pay 5 GAS as my storage is filling up? My concern with the later model is that if my contract becomes popular, it becomes more expensive to use, which (may) hurt its popularity. I do like the idea of a reward for a Storage.Delete call to keep things running smoothly.

Significantly reduce the cost of smart contracts
I think this is a good thing as it has been a big barrier to entry for individuals who may not have the funds. Having a higher cost is a good way to filter out junk projects. Currently the Upgrade cost is the same as the deploy cost, can/Should the upgrade cost be reduced below the deploy costs? It would be nice to encourage upgradeable contracts on the network

Cancel the free smart contract execution
Biggest concern here is the existing contracts costing. I know many of us have designed components to fall under the 10 free GAS limit so changing this may make our existing contracts unreasonable to run anymore. It also depends if the GAS calculations change (e.g. what once cost 8 GAS now costs 0.7 GAS to run). This is a pretty big change and may be something to gradually change over time or show the costing on a roadmap.

This will also have an impact on airdrops as the free GAS allotment has enabled those. I am not wanting to get into a debate on if airdrops are a good/bad thing but I can see the number of airdrops dropping very fast if this change happens as the cost to give things away may be too great.

A limited number/size of free transactions
Is the free as in free GAS or as in 0/low fee on a TX? Can I set how many blocks I want to try for? Can a contract decide this? I feel like this point/idea needs to be expanded on as to how it would be used.

Implementation
These are drastic changes to the NEO ecosystem and economy. I feel these changes will need to be very clearly planned out and communicated well in advance. A drastic change to any economy usually does not end up as intended. If possible these should be done in incrementing steps to not shock developers/users/consumers/etc in an instant.

@vncoelho
Copy link
Member

@vncoelho vncoelho commented Jun 25, 2018

@erikzhang, great step ahead, congratulations for the insights and efforts!
It will surely give more value to the Neo itself.

@canesin, nice suggestion, my friend. The portion of the block sounds good and flexible.
Maybe it should be interesting to have a greedy randomized heuristic for including some type of transactions first? It could balance time when it entered in the queue and some other criteria.

@jmseigneur
Copy link

@jmseigneur jmseigneur commented Jun 25, 2018

As @DaveOnBlocks mentioned above, cancelling the free smart contract execution would be a major pricing change that would endanger the viability of projects that have planned to use NEO base on its initial pricing model. As @mwherman2000 underlines, small storage and light execution pricing should remain very low compared to other systems. For example, 10 first GAS free has been one reason that Reputaction selected NEO over other platforms. It doesn't give a good signal to drastically change pricing model from one version to another. Uncertainty in the stability of the pricing model will scare away a number of projects.

@igormcoelho
Copy link
Contributor

@igormcoelho igormcoelho commented Jun 25, 2018

@erikzhang congratulations for moving in this direction for a Neo 3.0 with improved pricing models. The idea of having NEO asset to backup simple transactions is good, that will allow to "free" transactions continue to exist while paying with claimable GAS (is that correct?).
I believe 10 GAS limit has been the main motivation behind many projects (it's the core reason for our scichain.org project on NEO), and it has accomplished the original idea of having developers to design cost efficient contracts, so I have a proposal for allowing it to continue to exist on NEO 3.0, while not allowing it to destroy the environment:
(1) Every transaction (even below 10 GAS) will have a minimum cost (that can be paid with NEO holding as described before)
(2) For these contracts with 10 GAS limit, GAS prices for operations will be maintained as it is now except for Storage ones (if all other prices go down they could also hurt the model, as they will allow costly transactions to be now made in 10 GAS limit) and another contract deploy class will be created now to allow fully variable GAS costs without the 10 GAS limit.
(3) I propose that, for the contracts with 10 GAS limit, the user pays for all Storage.Put operations that increase Storage (even if it is below 10 GAS limit), according to the new Storage.Put variable prices. Let me explain the logic, and please refute if I am wrong. In my opinion, the only problem with 10 GAS limit is the infinite storage that can be added "for free". From byte to byte, one can put one Terabyte on the Storage space and that certainly shouldn't be allowed. In terms of NEP5 tokens, it's easy for one to create infinite addresses and keep sending a fractional part of a token for lifetime, only to fill Terabytes of Storage with useless addresses. If my proposal is accepted, current deployed contract users will be able to do: (i) do operations below 10 GAS for free, as long as they hold NEO and do not increase storage (they can even move assets from one part to another without increasing storage, that won't be an issue); (ii) pay a variable price TBD in Storage.Put operations when they increase storage (even if operation is below 10 GAS), so will be desincentivized to create random addresses (but a variable Storage price is required to be cheap enough for feasible usage, current price does not allow it).
Will that work for currently deployed contracts?

@Ejhfast
Copy link

@Ejhfast Ejhfast commented Jun 25, 2018

@erikzhang I'm really glad you are thinking about this. The high price of gas makes settlement logic very complicated for systems like NEX. It is hard to fit general purpose settlement logic into 10 free GAS, but we are forced to because otherwise the cost of a transaction is too expensive. Similarly, it would be unfortunate if a big system like NEX does not feed GAS back into the ecosystem because it does everything using the 10 free GAS... so the situation is bad on both ends.

I would also suggest keeping GAS cost the same for any contract deployed up to block X, the time of the new system fee deployment (those SCs can keep the current 10 free GAS system), with some limits on the number of free transactions per block (as @canesin suggested) to prevent storage attacks. This way people who have already deployed smart contracts are not hurt by the update

@igormcoelho
Copy link
Contributor

@igormcoelho igormcoelho commented Jun 26, 2018

.. with some limits on the number of free transactions per block (as @canesin suggested) to prevent storage attacks.

@Ejhfast unfortunately I don't see how giving a limite free tx will prevent storage attacks. It can slow them down but worsen the situation, because attacks will be more tempting to both overload storage and occupy the free transactions on the network (that may even cease to exist due to misinterest). And when they cease to exist, Storage will be paid as I am defending while keeping 10 GAS free (but in this case 10 GAS policy will be effectively and permanently lost).

Introducing free codes also has the risk of opening us to compute exploitation.

@lllwvlvwlll, Tyler (#278) I don't see how free Storage.Delete could be exploited, because the storage is a finite resource on a contract, and the more "exploited", the better. However, @canesin made me see that having REWARDED Storage.Delete can not be beneficial (and indeed be exploited), mainly if the rewards compensate the price of Storage.Put (in this case, an infinite loop of exploitation is possible, that is already being exploited in Ethereum).

We plan to modify it to refer to a number of incremental charging patterns as the storage capacity expands, encouraging the deletion of old data.

@erikzhang I kind of agree with that, but I don't know how this would not punish big contracts just for being big, which is the opposite expected incentive for popularity (as @DaveOnBlocks pointed out). If it was possible to measure its "storage inneficiency", then it would be easy to overprice that.... but how? I even thought of garbage collection and leased user storage (from time to time), but I didn't succeed in finding sustainability in that.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 26, 2018

How would this impact existing contracts? Seems like these changes could/will drastically hurt existing projects already deployed to the blockchain.

You are right, the new design must fully consider the impact on the old contracts, as far as possible do not affect.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 26, 2018

Would Storage.Put() have a different cost based on how much data was done in that operation?

Not in this operation. It depends on how much space has been used in the contract. For example, within 0~100m range, it costs 0.05gas/kb;100m~200m range, 0.1gas/kb;200m~300m range, 0.2gas/kb. (All values here are examples, not actual pricing) Simply, the price increases exponentially as the space used has grown.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 26, 2018

I would also suggest keeping GAS cost the same for any contract deployed up to block X, the time of the new system fee deployment

Now the network will accept InvocationTransactions whose Version==1 . When the new pricing model is used, you need to set the Version to 2. At this time, version 1 and 2 will both be accepted by the network, but after X blocks, version 1 of the transaction will not be accepted.

@hal0x2328
Copy link
Contributor

@hal0x2328 hal0x2328 commented Jun 27, 2018

For example, within 0~100m range, it costs 0.05gas/kb

So there will be no minimum fee for a Storage.Put then? If I store 0.01 KB I only pay 0.0005 GAS for the call? Or is it 0.05 GAS + 0.05 GAS for each KB over the first KB?

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Jun 28, 2018

So there will be no minimum fee for a Storage.Put then? If I store 0.01 KB I only pay 0.0005 GAS for the call?

0.05gas

@deanpress
Copy link

@deanpress deanpress commented Jun 30, 2018

@erikzhang

  1. I remember talk about letting NEO holders vote for invocation/transaction fees. Is this still a consideration?

  2. If costs are introduced to invocations, a feature to consider is letting the smart contract account pay for user-made invocations itself: Smart contract account holds NEO, pays for user-made invocations with generated GAS. There would have to be other anti-spam measures implemented, but this feature would keep the ability for end-users to interact with smart contracts without having to hold any crypto-currencies themselves.

@thirdprize
Copy link

@thirdprize thirdprize commented Oct 10, 2018

If i write a game, i don't expect my users to hold NEO. Hardly anyone would end up playing it if I did. They shouldn't even have to know what NEO is. I'd want to cover the cost of them making their moves myself. 10 free GAS is good as that would cover it. If you scrapped the 10 free GAS and I had to pay for it myself, which is a no go. It would costs hundreds of thousands $ to get enough NEO to claim enough GAS to make it work. I don't have that money. Make it 5 free GAS but don't scrap it.

I can also guarantee that every NEO project up till now works on the principle of 10 free GAS. If you remove it you will kill a lot of projects.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Oct 11, 2018

The contract's deployer can prepay a fee and set a limit that allows the user to use it for free.

Is it possible to do this?

@dicarlo2
Copy link

@dicarlo2 dicarlo2 commented Oct 12, 2018

@deanpress on #2 this is already possible (technically, but perhaps not practically). The smart contract just needs to be designed to allow inputs of GAS from the smart contract to be used by arbitrary invokers as long as the transaction is an invocation that calls the contract. You could even add in anti-spam measures. I say perhaps not practically, because the UTXO system makes this a bit more complicated (only so many outputs available, etc.).

@igormcoelho
Copy link
Contributor

@igormcoelho igormcoelho commented Oct 12, 2018

fully agree @dicarlo2

@vncoelho
Copy link
Member

@vncoelho vncoelho commented Oct 15, 2018

I think that it would be a good move.

@jasonliu91
Copy link

@jasonliu91 jasonliu91 commented Feb 13, 2019

Although users can get GAS for free when they hold NEO, GAS is also a payment currency. It has market prices and fluctuates wildly. It seems that the small GAS price may be very expensive. In addition, GAS can also be paid outside the NEO system, so users are still sensitive to the system's GAS costs, and the current system also lacks price adjustment mechanisms. The current system cost has seriously affected the ecological development, both for users and developers. In order to avoid letting users pay for GAS, developers have to split a feature into two transactions, and need to create sub-accounts in the contract, the user experience and development experience is very poor. If NEO 3.0 solves the problem of system cost, then such a contract should not be directly ported. We hope that before NEO 3.0, there can be a temporary solution, such as increasing the free GAS quota for the contract, and letting the ecology develop first.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Feb 13, 2019

We will reduce the cost of contract execution in NEO 2.x.

@jasonliu91
Copy link

@jasonliu91 jasonliu91 commented Feb 13, 2019

We will reduce the cost of contract execution in NEO 2.x.

Is there a specific version plan? I hope it can be implemented as soon as possible.

@erikzhang
Copy link
Member Author

@erikzhang erikzhang commented Feb 13, 2019

I will start to advance this after the new dBFT development is complete.

@QingmingZi
Copy link

@QingmingZi QingmingZi commented Feb 13, 2019

I will start to advance this after the new dBFT development is complete.

Is it a complete solution to the current stability of NEO? For example, 2.9.5?

@shargon
Copy link
Member

@shargon shargon commented Feb 13, 2019

We should add to this proposal, increase the NOP and PUSH prices to 1, none opcode should cost less than one

@thirdprize
Copy link

@thirdprize thirdprize commented Feb 13, 2019

I have no problem with backing my GAS use with holding NEO but in our case, if a user trades one of our "virtual cards" for another it would be at least 1 GAS (checking who owns what, doing the transfer, etc). It would probably be quite an investment in NEO just to earn 1 GAS a day to trade 1 card.

In all honestly we are now looking at LOOM as they recognise these issues and have done something about it (moved it all off chain). Just saying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.