Before you think about deploying your EOS decentralized application (DApp) to a blockchain network, as a developer and system planner you should study in detail the cost to run your infrastructure on a public shared network with a limited amount of resources to be consumed. The storage cost and execution cost on a public blockchain network are higher than in any cloud provider like Amazon Web Services, Google Cloud or Microsoft Azure.
This article assumes that you have basic knowledge about EOS Governance scheme, its resource allocation model, EOS Staking mechanisms and Block Producers.
On any EOS public network, there is no pay per use pricing model unlike other blockchains such as Ethereum(GAS fees) or Bitcoin (Transaction fee). The access to the limited blockchain resources is controlled by a mechanism named staking that allows the users with higher ownership on the network, so a higher number of SYS tokens frozen on the system contract, to have higher priority accessing the limited resources.
On an EOS blockchain network the limited resources are:
RAM — Resource required to store the in-memory database that supports your smart contract. This resource is consumed when a new data row is added to your smart contract database table. EOS uses the Bancor Protocol algorithm to adjust the RAM price based on supply and demand. Example: RAM to store the User Token Balances Database.
CPU — Shared CPU time to execute your DApp business logic. This CPU is consumed every time you execute a transaction on the network and depend on the code complexity defined by your smart contract, so the longer your transaction runs more CPU time it will consume. Example: Transfer Balance from User A to User B.
Network Bandwidth — the amount of data submitted to your smart contract. This resource is consumed when you send a transaction to the EOS network and depends on the size of data transported by your DApp transactions.
To use the public resources, the DApp developer should acquire access to CPU and Network Bandwidth by staking the network native token (SYS) or by buying RAM with the SYS token in a dynamic market that follows demand/supply forces. The CPU and Network Bandwidth consumption tables are accumulated in 3 days periods, so the dAPP developer should stake SYS tokens for that period in proportion to the amount of data statically stored, and the number of transactions for that period and the amount of data transmitted.
To reduce these considerable costs, the EOS main network, with the REX market, allows a DApp developer to lease EOS (SYS) resources for a 30 day period to accommodate DApp demand peaks affordably.
More information about REX market: https://eosrex.io/. There are also similar alternatives like chintai.io, but the mechanisms are quite similar.
Right now, there are multiple public EOS based networks that you can use to run your DApp, notwithstanding we will limit our analysis to the following public networks:
EOS — is the original main net launched by Block.One on June 2, 2018. EOS was the first and fastest decentralized self-governed blockchain which encourages its token holders, investors, and developers to share their voice through proposals and voting as a means for consensus. EOS coin is the network SYS currency.
WAX — WAX is an EOSIO based side chain that allows anyone to trade digital or even physical items instantly and securely, to anyone, anywhere. WAX is the public network SYS currency.
TELOS — is an EOS side-chain managed by the TELOS foundation that wants to empower decentralized autonomous communities, fairly compensate the main block producers and standby block producers and provide an affordable public network for DAPP developers. TLOS is the public network SYS currency.
Network Bandwidth Costs per EOS.IO Network
The table below estimated the network bandwidth cost to run 100 transactions per day with a size of 200 bytes per transaction. Your CPU and Network Bandwidth consumption is measured on a 3 day period, so every time you run a transaction your consumption is accumulated over the period and after the 3 days is reconstituted. It is essential to stake CPU and bandwidth for the 3 days period.
As revealed in the table above, if your application does not require a huge amount of data to be transmitted over the network, the SYS stake required is not going to be considered to your overall cost.
CPU Costs per EOS.IO Network
The CPU congestion on the EOS main network has been a hot topic over the last months since the amount of CPU available to run your DApp transactions fluctuated a lot with a huge CPU demand increase imposed by EIDOS Airdrop. It is fundamental to make sure that at any time you have the required resources to make your blockchain network submissions to go through and don’t have any denial of service for your users.
On the following table, we estimated the amount of SYS balance staked to run a dAPP that requires 100 Transactions per day on each network. We estimated the minimum amount of SYS on the 9th of March 2020 prices.
Additionally, for the EOS Main Network, we estimated the loan cost (REX) to lend the same amount of EOS/SYS for 30 days.
The CPU cost per millisecond was estimated based on the following formula and we used some block producers to estimate the price.
CPU Price = (CPU Staked / CPU Available) / 3
For dAPPs with very irregular CPU bandwidth shapes, we recommend you to deal with CPU demand spikes by lending SYS on REX market. This approach will dramatically reduce the SYS self-owned staked balances required to accommodate your application load with no service disruptions.
RAM Costs per EOS.IO Network
The RAM costs are the DApp resource that mostly contributes to your DApp budget. Every time you run a transaction that stores new data information on your smart contract database, the amount of RAM consumed will increase and your budget will be eaten.
We recommend you to optimize the store of information about your smart contract to occupy the minimum space possible.
Aside from that, find out mechanisms and services like IPFS or decentralized storage solutions to offload the storage to a cheaper service. As soon as your DApp scales up, you can assume that the amount of RAM required to run your service will scale up.
At TAIKAI, based on our operation metrics, we estimated RAM demand and the RAM acquisition cost for the EOS main based on the current prices.
Account Acquisition Cost per EOS.IO Network
The DApp users will want to use your DApp as quickly as possible. In fact, 95% will not know they’re about to interact with any blockchain at all.
For that to happen, DApp developers might need to pay for the network accounts required to onboard new users. In the following table, we estimated the costs required to set up an EOS account with 4KB of RAM.
Some DApps use a different scheme to avoid this cost, like supporting virtual accounts, using hierarchical account schemes, etc. We encourage you to find out an approach that suits your DApp and avoids software integration headaches.
Summing-Up
It is essential to calculate the network tokens (EOS, TLOS, WAX) staked required to run your DApp. Your smart contract will require database space to save user data and CPU Bandwidth that accommodates your traffic demand.
Meanwhile, start also to enumerate the advantages to run on each network listed on this analysis and weight your decision. It is not easy to migrate from one network to another, so take your time to make this decision.
If you choose an EOS sidechain, the actual cost is significantly lower 10–50x, but as soon as these networks get more demand, the difference between the EOS networks and the sidechains costs will decrease. The Bancor Algorithm used to calculate RAM prices will have an impact on account acquisition cost and operation RAM required to store information.
The storage pricing, CPU and EOS account acquisition can dramatically increase your infrastructure cost once your dAPP starts to onboard and scale a higher number of users. Some dAPPs offload certain transaction costs to the final users, however, this mechanism needs to be implemented with caution because the casual consumer might not understand it.
Just do your math and plan carefully, otherwise, you could end up in a situation where your users could not use your service because you run out of EOS resources.
On TAIKAI, we are trying to estimate the cost based on metrics retrieved from our operation on a public EOS testnet. We also used some sigmoid demand curves to forecast the demand evolution over time and estimate the resources required to scale up our business. If you want to know more about us:
Our Home
TAIKAI
References
- “EOS New York Resource Planner” — https://www.eosrp.io/
- “How we Calculate EOS Resource Usage” — https://medium.com/shyft-network-media/eos-resource-usage-f0a8098827d7
- “Bancor Protocol“ — https://blog.bancor.network/how-liquid-tokens-work-a4ba30f2482b
- EOS White Paper — https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md
Top comments (0)