Economics and rewards
In this chapter, we will dig deeper into the fees of the Mavryk network and the validating and attesting rewards. The calculations you'll learn about are helpful from the simplest transaction issuance to the most complex application built on Mavryk. That is why it is important to understand the basics of fees and gas optimizations. Of course, this will be particularly useful if you are a validator.
Transaction cost
Each transaction on Mavryk has a cost for the user. To account for this, the user must include a gas fee when submitting transactions. Validators will then choose transactions using a minimal fee filter. If the validator chooses a transaction, he will add it to the block and propagate it. The fee is therefore used to pay the validators. They are calculated by using the following formula [1]:
Let:
- Minimal Fees:
- Size of the operation (in bytes ""):
(The size "" is the number of bytes in the complete serialized operation). - Gas used for the operation (in gas unit ""):
- Minimal nano-mav per byte:
- Minimal nano-mav per gas unit:
Gas unit cost in Mav is defined by the protocol. It does not depend on the fee market; it does not depend on arbitrary defaults in config files; etc [2]
Then:
The transaction default values are:
In a Mavryk operation, we can add additional information such as smart contracts deployment, smart contract call, etc. These have a storage cost which is represented in mav per byte.
On the Mavryk blockchain, gas refers to the cost necessary to perform a transaction on the network. Validators set the price in gas based on supply and demand for computational power on the network (needed to process smart contract calls and other transactions).
Gas is used to determine the complexity of the transaction execution and also to avoid the risks of infinite loops. It is one of the main factors a validator considers before choosing transactions. Before including a transaction, the validator reviews the amount of gas required and its cost per unit. If this ratio is adequate, the validator selects the transaction.
Each transaction has a gas limit: 1,040,000 . If the contract execution, or deployment, exceeds this limit, the contract is considered unusable. This limit is useful to guarantee that the validators will be able to validate the block in a limited amount of time [3]. The gas limit may seem relatively low, but its value is a network's inclusion metric: any user should be able to run a node and bake a block within the allotted time. Even slow nodes can participate.
Note that a validator also takes into account the gas limit per block. Today, the limit is 2,600,000 . So, of course, it limits the number of transactions to include in a block. However, for the storage cost, it isn't a fee that rewards the validator. Actually, this particular fee is "burned", meaning nobody receives it.
Smart contract execution and optimization
There are two limits to take into account when developing a smart contract. The gas limit is an important parameter for the usability of the smart contract. But there is also a second major limit: each serialized operation has a maximum size of 16,384 bytes. It is, therefore, impossible to upload a smart contract bigger than this limit (origination).
One must account for these two variables to optimize a contract:
The gas consumption
Many options are possible [4]. However, note that a large proportion of the gas is spent on the conversions from byte sequences to protocol-specific typed representations (and vice versa). These conversions can be:- reading
- deserialization
- parsing of bytes
- checking the correctness of types
- conversion back to bytes
Follow this link for more details on the cost of gas.
The contract size
The formula below calculates an approximation of a contract's size:An assumed constant value per instruction:
The number of instructions:
The sum of the sizes of all variable-size constants (strings, bytes) in the contract:
Then the contract's size "" is:
So, the size optimization comes down to decreasing the number of instructions and the variable-size constants. [7]
Mavryk reward
To maintain the network, Mavryk needs validators. They stake their tokens and use their computing power to create blocks, manage transactions, vote, and secure the network. In exchange for these tasks, validators are rewarded with a fee.
Validating reward
When a validator bakes a block, he receives a reward composed of all the transactions fees contained in the block in addition to a network reward computed by the following formula[9]:
where e ∈[0; 2,333] = the number of extra attestations slots beyond the threshold of 4,667.
The validating rewards are MAX_MAV_REWARD_VALIDATOR mav at most, for a fully attested block (not counting the transaction fees).
where s = number of attestation’s slots.
A validator may have several attestation slots among the 7,000 slots available in a given block, depending on its stake. The more stake a validator has, the more slots it gets per block.
For more detail about the Mavryk validating process, please refer to the "validating" module.
Inflation
It's important to note that the Mav token is based on a model with inflation. By adding up the validating and attesting block rewards, each new block generates 20 new Mav (without taking into account the 1.25 Mav generated for liquidity validating). A new block is created roughly every 15 seconds. This represents 42 Million Mav per year ( 80 ṁ 60 mins 24 hours 365 days). At the Mavryk launch, the network was composed of 763 Million Mav. Therefore, during the first year, the inflation rate of the Mav token was approximately . Today, in 2023, the inflation rate is around 4.5%.
What have we learned so far?
Thanks to this chapter, you should now have a better understanding of how Mavryk economics work. This understanding can now help to build viable Mavryk smart contracts.
This chapter is the last one of the Mavryk Basics module. The next chapter is the examination.