Why smart contracts pay to rent storage on the Everscale blockchain [Deep Tech]

Firstly, why do smart contracts have to pay rent?

All distributed networks, including Everscale, have a finite amount of computational resources. When actors like smart contracts are deployed on the blockchain, a portion of those resources are consumed. It is unfeasible to maintain an unlimited number of smart contracts for an infinite amount of time on-chain. The resolution of this issue was and still is a hot topic of discussion among top developers of Ethereum, NEAR and other popular networks. Regarding Ethereum, a viable solution has still not been found, which has limited the network’s scaling capabilities. Everscale, on the other hand, has solved the issue in an innovative way, via the introduction of a contract rent mechanism. With the rent mechanism, only active smart contracts that execute some business logic and pay fees are kept on-chain. It is an effective solution from both an economical and technical perspective, allowing devs to manage smart contracts and state storage.

TIP

A classic blockchain is an immutable and eternal store of data. Although it sounds great and looks good on paper, it is quite impractical. One of the main issues has to do with the so-called eternal storage (keeping data on the blockchain forever). Namely, when a person sends a deploy transaction, they pay a fee. This fee is paid only once, yet the data should be kept on the blockchain forever. Thus, miners will have to keep paying to store this data on-chain. From an economic standpoint, this approach is extremely burdensome.

Let’s recall once again what a blockchain actually is

The original blockchain concept describes a chain of blocks from the genesis (first block) to the conclusion. In this construction there is always the possibility of tracing the chain of blocks backwards to check whether everything runs well. However, on the Ethereum network for quite some time, full nodes have begun to synchronize with some kind of snapshot from the recent past — not from the genesis block. Notwithstanding this, many Ethereum developers are still not ready to accept the fact that storing the entire history of blocks from the beginning is not feasible. They insist that the history of blocks is essential for a blockchain and should be stored forever. With this position, some Ethereum devs are continuing to develop special protocols that would make it possible to always check a particular block or transaction irrespective of when it took place and whether it is necessary.

TIP

Considering the high number of dApps already launched on Ethereum, it will be quite difficult for the network to abandon the existing model and switch to a different one.

There is also an issue related to blockchain state growth. That is, if someone initiates a transaction, it is recorded on the blockchain. For example, buying a meme-coin. Even if the price of the meme-coin goes to zero, the information about the purchase will still be stored on-chain forever. As a result of this dynamic, blockchains are forced to artificially limit the rate of recording transactions so that the size of the blockchain state does not grow faster than data storage becomes cheaper. As a result, users are forced to compete with each other for the right to record data on the blockchain via auctions. As we can see in the case of Ethereum, in such circumstances, transaction fees end up increasing on a constant basis.

This issue has been acknowledged by the Ethereum dev team. There is the “State expiry” section in the Ethereum 2.0 roadmap which is supposed to deal with precisely this issue. However, they can’t completely solve the problem without breaking backwards compatibility. So far, they have proposed to remove (with recovery possible) contracts that have not been active for N years from the state.

The Near blockchain is also exploring different ways to solve this issue. Namely, it has proposed a solution for smart contracts to lock N tokens each time a smart contract records new information in the state. The deployer of the smart contract can set the terms dictating when to delete the information recorded and receive the tokens back. This is definitely only a half-measure. On the one hand, not all users can set the terms, and on the other, those who can are exposed to price fluctuations. Therefore, in some adverse situations, the amount to be received in fiat could become significantly less. Other blockchains have proposed to simply remove smart contracts with fewer than N (the figure varies) tokens on the balance from the state.

What’s Everscale’s solution?

Everscale, as one of the most technologically advanced blockchains, never looks to cut corners when trying to solve blockchain bottlenecks. In the Everscale blockchain, each smart contract holds an EVER token balance and uses it to pay rent. The rent for each contract corresponds to the size of the data stored. When the balance of a contract is emptied, it is first deleted with the possibility of recovery, and then deleted completely. Due to this, Everscale has controlled behavior, in which each smart contract decides for itself how long it will exist. More than that, users do not have to compete with each other for the right to record data, leading to a huge throughput in terms of the number of transactions processed per second.

TIP

Note that paying for chain storage doesn’t happen once, the rent payment is continuous. Therefore, if the data is kept for a short period of time, the cost will be significantly less.

In Everscale, a smart contract dev has a lot of options to choose from when funding an operation. The developer can either deposit some EVER tokens on the contract’s balance and subsidize his users or charge gas from users for different operations and keep it for future rent payments. Basically, the gas reflects the cost necessary to pay for the computational resources used to process transactions.

You can see how it actually works in the animation below.

Storage fees on Everscale

Each smart contract in Everscale requires a storage fee, calculated as follows:

storage_fees = CEIL(

(

account.bits

* global_bit_price

+ account.cells

* global_cell_price

) * period / 2 ^ 16

)

Where:

account.bits and account.cells — represent the number of bits and cells in the smart contract, including code and data.

global_bit_price — the price for storing one bit (p18 for both masterchain and workchains).

global_cell_price — the price for storing one cell (p18 for both masterchain and workchains).

period — the number of seconds a smart contract is stored for.

Note: While account.bits are quite easy to calculate, the account.cells value can vary for different types of data. A cell can have no more than 1023 bits and 4 references to other cells. The contract code and numerical variables are each packed into cells and there is a minimal number of cells required to store the data. More complex data structures require more cells to store the same amount of data.

Let’s see an example

We will calculate the minimal fee for storing 1062.5 KB of data for the duration of one day. You can view the contract deployed for this purpose via the following link.

global_bit_price = 1

global_cell_price = 500

period = 86400 seconds

account.bits = 6536465

The minimal account.cells value for 6536465 bits of data is 6500. Therefore, the minimum storage fee would be calculated as follows:

storage_fees = CEIL(

(

6536465

* 1

+ 1064

* 500

) * 86400 / 65536

) = 0.014291591 EVERs

It should be noted that the storage fee for a 1062.5 KB account could be higher. The calculation depends on the features of the smart contract deployed.

If there is not a sufficient amount of funds on the account balance to cover the amount due, the smart contract will be frozen and its balance subtracted from the storage fee and reduced to zero. The remaining storage fee will be marked in the account as debt.