Smart Contract Economics

[cmichi]

Problem

Substrate continuously charges a contract for rent. If the contract's balance exhausts these liabilities the contract is evicted and a tombstone (i.e. a hash of the code) is placed in its place.

This requires contracts who want to live for a long time to think about an economic model how they can sustain themselves. Currently it's not clear how they are supposed to do this and some necessary information is not yet exposed to ink! (like how much the costs are per block or the rent projection).

Open Questions

• In ink!, how should contracts best charge more for calls in order to save up for their rent fee?
  • Mark as payable, check how much the call costs and require an additional amount? How should the "additional amount" be determined?
• What constants need to exposed in ink!?
• Is it possible to expose an estimate of how many blocks until the contract will be evicted in ink!?
• Are there already best practices in related projects?

ToDo

• Research how related projects solve this.
• Implement a solid example demonstrating smart contract economics. Maybe a contract that just tries to live forever? The example should contain off-chain tests.
  The other ToDos will probably derive from that. For example, the off-chain environment contains a number of unimplemented!() for tombstone/eviction functionality, they need to be implemented.

Resources

• https://wiki.polkadot.network/docs/en/build-smart-contracts#storage-rent

[Swader]

NEAR does this by paying 30% of every TX fee that is a result of a contract interaction to the contract that was used. If the call triggered multiple contracts, or one contract called another, then the 30% is evenly distributed. This is put into the balance of the contract, which uses the proceeds to pay rent or profit, depending on usage and optimization. Perhaps something to consider?

[athei]

But that is no guarantee that those keep the contract afloat, right? Because TX fees are not correlated to storage consumption.

[Swader]

In NEAR the chain's currency is used as two things: paying for tx fees, and permission slip to a certain amount of storage. Think 1 N = 10kb or something like that. So a contract that stores a lot of data has to have a high balance - they cite the example of Ethereum's USDT contract. I would have to have 10k NEAR tokens to keep the state it has now (i.e. the bigger a contract's state, the more balance it needs to have and that balance is effectively locked). Technically, this is up to the user - they need to pre-pay enough to cover the state they intend to host, and then they rely on the tx fees for auto-top-ups if the contract or lib is popular, or implement functions that are payable so that each call to them is more expensive than the base fee.

Anyway, it's just one avenue potentially worth thinking about. The math of reconciling cost vs income is over my head, but just wanted to throw this approach out there so you're aware.

[athei]

So a contract that stores a lot of data has to have a high balance - they cite the example of Ethereum's USDT contract.

This is exactly how the rent payment in pallet contracts is designed, too. With the addition that you can have less balance required to store the state forever which means you pay per block and get evicted, eventually.

Contracts that want their users to pay for the storage need to make every message that adds storage is payable and charge n * RentDepositOffset where n is the amount of bytes added. Every contract that has a balance above bytes * RentDepositOffset does not pay rent.

Is it possible to expose an estimate of how many blocks until the contract will be evicted in ink!?

There is the contracts_rent_projection RPC that does exactly this. There is currently no host function that allows contracts to query this estimate.

[cmichi]

Closing as a follow-up to paritytech/substrate#9669.