We are used to paying based on how long we use some resource – whether parking meters, toll highways, or safe deposit boxes. We don’t purchase the above in order to give ourselves indefinite rights, but rather rent them – paying an amount per unit of time.

The DLT industry is recognizing the need for the same model in charging for usage of the resources of the network – moving from ‘ownership’ (in which a client could effectively buy a piece of the shared ledger of transactions and state in perpetuity with only a one time ‘purchase’) to ‘rent’ (in which clients are expected to continuously pay for the network maintaining and storing a given piece of data).

Hedera has designed rent into the fee structure – clients pay for storage based on how large a data object is and how long it is to be stored.

What is rent?

Rent, in the context of DLTs, refers to a requirement that clients storing objects in the consensus state pay a fee for that storage and that the fee will reflect the temporal duration of that storage. If the initial transaction that creates an object does not have the requisite rent, the creation will fail. Likewise, once an object’s rent fee has run out, it can be removed from state.

Different rent models can be distinguished by:

• How is rent paid? For instance, does rent manifest as explicit fees collected from the client? Or are coins instead burnt (and so contribute to deflation)?
• Which party receives the rent? For instance, does it go direct to the nodes storing state? Or is it collected on behalf of those nodes?
• What happens when rent runs out? For instance, is there a period of reduced access or functionality to alert the owner of the imminent deletion?
• Once deleted, is recovery possible? If there is a recovery mechanism, from where is the ‘backup’ retrieved?

Immutability?

How do we reconcile rent and the potential for the deletion of some data from the ledger with immutability?

A DLT’s fundamental purpose is to allow a network of nodes to establish a consensus state of some set of business data, e.g. how many coins each party has, where in the world various shipping containers are located, etc. This would be trivial were it not for the fact that transactions are constantly changing the state, e.g. coins are being spent, shipping containers are being shipped, etc.

The state is by definition mutable – it changes constantly based on the transactions that are occurring. Immutability of state then means not that changes can’t occur, but rather that only valid changes can occur – where validity is defined by the network. The default policy for changes on blockchains has been:

• Accounts can be created
• Account state can change, if the transaction is signed by the appropriate parties
• Smart contracts can be created, but not subsequently modified or deleted
• Smart contract state can change, if the transaction is signed by the appropriate parties

The possibility of deletion, should an object’s rent run out, extends the above list to include:

• Accounts and smart contracts can be deleted, if their rent runs out

Note: some proposals for rent do not require an automatic deletion mechanism. Instead, clients effectively pay for the present value of an infinite sequence of storage costs, for all time, and are encouraged to remove data from state when it is no longer relevant with a refund of some of the initial fee.

Why is rent necessary?

The consensus state is maintained by all network nodes – if state is allowed to grow without bounds, then the storage burden associated with running a node would grow accordingly – and likely preclude smaller actors with less financial resources from acting as nodes.

Rent is designed to:

• Discourage dishonest clients from performing a denial of service attack by uploading large volumes of data to the ledger – forcing nodes to store those terabytes and potentially filling up storage – and so preventing valid transactions from being processed. Rent does not prevent the attack, but can make it economically prohibitive as the attacker necessarily needs to pay for the storage of those bytes for as long as they run the attack
• Encourage honest clients to be discriminating in creating and storing objects in state. Without rent, honest nodes might not fully confront the negative consequences of indiscriminate storage and sloppy smart contract programming, causing the same state growth as in the above attack even if unintentional

Additionally, rent can help to encourage parties to run nodes, because rent can be used to compensate (either directly or indirectly) nodes for the costs associated with storing state.

Rent & smart contracts

It is for smart contracts that the possibility of deletion due to rent depletion is arguably most significant – this is because:

• Smart contracts may be large – both bytecode and their own internal state – and so amplify the need for rent
• Multiple parties may have a vested and differing interest in the continued persistence of a smart contract

Consider a dapp that uploads an ERC20 smart contract and pays rent for the first year of storage of the bytecode and the initially small internal state. Over that year, the token grows in popularity and so the size of the internal state tracking ownership of that token grows accordingly – possibly growing well beyond the size of the bytecode. It may be the user who pays for each individual increment in the size of the state.

After a year, the contract’s rent is up for renewal – who should pay the rent for the now much larger combination of bytecode and internal state? Should it be the contract owner (if one exists)? Or the users? Or both?

The issue is represented in the graphic below:

If the smart contract owner designed a suitable economic model for realizing profit from the token’s popularity, then they would hopefully have both the motivation and the means to fund the next year of storage. But perhaps the dapp was designed to not have an owner, and to run independently for the benefit of its users. The individual owners of the tokens clearly do not want the smart contract to disappear, taking with it all their value. Given that interest, shouldn't they contribute to the costs of the persistence of that value?

Of course, if neither the owner nor users are motivated to contribute to the rent of a smart contract, then it’s questionable whether or not it has any value and even needs to be continued to be persisted in state.

Below are potential models whereby the risk of deletion from unanticipated future state size growth can be mitigated:

• The smart contract owner takes on the responsibility of paying rent, but designs in constraints to the size of state to control its future rent costs. For instance, imagine a contract for some tokenized real estate that restricts the number of part owners at 100 – potentially enhancing value through exclusivity
• The smart contract owner takes on the responsibility of paying rent and designs a revenue model that ensures they will always have sufficient funds to cover rent and prevent deletion
• The smart contract itself collects tiny fees from its users every time they interact with the contract and so effectively self-funds its future rent. As long as the contract has sufficient usage, it can continue to cover its rent

Hedera's rent model

Hedera’s fee model ensures that the storage of any object reflects:

• The size of the object in bytes
• The duration of the storage in seconds
• The relative scarcity of the storage medium, such as RAM v. hard drive

When a client creates an object (account, file, or a smart contract) in state, they submit a transaction that specifies an expirationTime as the time in the future that the object will no longer be needed, and can be deleted.

The total fee for that transaction will include the normal fees of submitting a transaction and having it processed. In addition, it will include the fee for the number of bytes that are being stored, multiplied by how long they will be stored. There will be a price in hbars (bytes * time) for storing it in RAM, or a lower price for storing it on the hard drive (or other storage device). Typically, accounts are in RAM, and files and smart contract states are in storage.

The rent is collected by the Hedera Treasury. Once a day, the nodes that are storing the data receive a payment from the Treasury that is designed to compensate for the associated costs (for all storage, not each object individually). The two are not tied to each other, so in the short term, Treasury can make up for insufficient rent being charged. In the long term, the economics should average out so that the nodes are compensated enough to cover the storage costs, and the rents are sufficient to cover the amount that Treasury is paying.

This initial fee pays for the storage of the object until the expirationTime. After that time, unless the rent has been extended, the object will be automatically deleted from the state by all nodes.

To prevent this deletion, one way to extend an object’s rent is with an explicit update transaction. For instance, if a file was initially created with an expirationTime one year in the future, after 11 months the client could ensure the continued persistence of the file for another period of time by sending a fileUpdate transaction giving a new expirationTime (necessarily later than the first). The rent fee for this storage extension would be determined by subtracting the old expirationTime from the new.

For crypto accounts and smart contracts, there is an alternative option for paying rent – the client can stipulate an autoRenewalPeriod – after which time the rent for that account or contract will be automatically paid. For instance, if the transaction creating a smart contract stipulated an autoRenewalPeriod of 3 months, then the client’s account would pay for the initial 3 months of storage (for bytecode and initial state) and after that time period of time, the smart contract’s associated crypto account would pay for 3 more months of storage (of both bytecode and the new state). As long as the associated account had sufficient hbars, the contract would live indefinitely – paying for itself 4 times a year without the need for explicit update transactions to be sent. Auto renewal is not an option for files as there is no associated crypto account from which those rent fees could be withdrawn.

The third model for paying rent for smart contracts discussed above, specifically requiring that users make payments into the smart contract’s associated account so that the contract will be able to pay the next rent fee, is directly supported in Hedera. This model is shown below; each smart contract call sent by a user would effectively pay for its own current rent for any growth in state (sent to Treasury as described above), as well as future rent (sent to the smart contract’s account).

Summary:

We have designed the economics of Hedera such that transaction fees account for the:

• Degree to which a given transaction consumes the resources of the network
• The scarcity of those resources
• The duration for which the resources are consumed

Rent for storing crypto accounts, smart contracts, and files in the consensus state maintained by all nodes is a natural consequence of the above model.