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

Open
erikzhang opened this Issue Jun 25, 2018 · 22 comments

Comments

@erikzhang
Member

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Member

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

igormcoelho commented Oct 12, 2018

fully agree @dicarlo2

@vncoelho

This comment has been minimized.

Contributor

vncoelho commented Oct 15, 2018

I think that it would be a good move.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment