Part one — EOS Resource model
Abstract
The proposed resource model (1) looks like a general improvement to the current system. While also adding additional requirements to users and node operators (in particular those providing or indexing history). The proposed model increases a user’s actions that are required to be filed in their tax reports as well as potentially increasing the growth rate of both block log and indexed history data. This is likely to result in additional difficulties for history providers. Readily available account history is something we see as essential for user experience of any public ledger.
Index
- Abstract
- Introduction
- A potential struggle for filing your taxes
- We may start to see unused resources
- Increased block size and network traffic
- Investigating number of actions and amount of CPU per producer
- Potentially increased growth rate of current history and block data
- Looking briefly at NET utilization
- Summary
Introduction
The new resource model does look like an improvement in general to the current system where a lot of resources stay unused. It will potentially allow users to easier and more freely interact with the EOS blockchain. Especially if there is a layer of resource sponsoring by dapps like Eosrio, Dexaran and polar.io suggested in their articles (2, 3). This idea would complement the new resource model in a neat way to allow common users to avoid the hassle of resource management. Which from a user experience viewpoint is essential.
A potential struggle for filing your taxes
Users and businesses operating in any area where there are requirements to comply with tax regulations may potentially experience difficulties with the new model. Since we are based in Sweden we will use that as an example.
Situations where you need to document and report taxes for cryptocurrencies:
- Selling, Trading and swapping.
- If you buy goods.
- If you buy services.
- If you borrow assets.
- If you lend assets.
- If you earn rewards.
- If you sell services or goods in any way.
The recently suggested resource model will create more taxable events on the EOS blockchain by requiring users to participate in buying service with their tokens. If they also earn and claim rewards for their stake, they will create more taxable events. The current system leaves participation in REX optional, and you can buy tokens once and stake for resources which makes it easier to comply with tax requirements.
By Swedish law you need to store a copy of your taxable events for seven years. Right now, a little more than two years after EOS has launched the available public history solutions are extremely limited. For the full tax reports a user would need all their account(s) history. For a business operating on the EOS blockchain this dataset can become rather large and difficult to maintain for history operators. For this purpose it is essential that a public ledger is freely and easily available for users to access their history. Currently most available history solutions only offer the last 1000 transactions of an account, which does not allow Swedish users to easily comply with their tax requirements.
With the requirements from local tax regulations and the new subscription model for resources the need for full transaction history of the EOS blockchain is essential. With exchanges adding (4) the requirements of KYC on all fiat/crypto gateways, and the available analysis tools becoming better, the risk for users not to comply with their local tax regulations are likely going to grow. Most people today freely comply with tax requirements of their country, and as we move forward this is likely going to be easier to enforce. This is especially true for your average user that does not take intentional steps to distance themselves from their fiat and exchange transactions.
We may start to see unused resources
Under the proposed resource model there could come a situation where a user rents resources that they need for a few transactions and then leaves them unused for 30 days. This is something Dexaran and polar.io discusses in their article (2). With this kind of situation we would have a similar experience as the current one. Users using more resources may feel obliged to use up their paid resources to the fullest and partake in different mining operations with their paid-for and unused resources.
“Ideally a user must never be in a situation where he owns or even locks a certain portion of resources that he does not need. This can prevent the full use of the network in the same way as a user staking all his EOS for CPU and not using the allocated resources prevents the system from utilizing all the physically available resources at full potential without any downtime.”
By being more likely to make use of unused resources, there may be additional actions taking place on EOS which could lead to a faster growing dataset compared to today.
Potentially increased growth rate of history and block data
Along with Michael from eosDAC we are worried that using a larger portion of the resources, making the most performant blockchain in the world even more powerful and performant could have ramifications both in relation to the increased growth of the block log and in particular to the indexed history.
To run a fully indexed state-history node with trace-history and chain-state-history enabled requires around 5 TB of storage for the state-history, and another ~550 GB for the block log (on a lz4 compressed filesystem). We have for the last couple of months been working on indexing a secondary instance of Hyperion (using the newest version) into the latest version of elasticsearch (which should be more performant for the Hyperion API), this has already proved to be quite difficult. Today we are running one state-history node to keep the old Hyperion synced, and another for syncing the new version. The old Hyperion is right now containing close to 17 TB of data.
Increased block size and network traffic
Extra strain will very likely be put on the block producers under the proposed model since blocks are meant to get bigger and consume more CPU to process. The hand-over process already is quite problematic at times and likely all top30 producers will need to start running a separate peering network to transfer blocks between themselves and in accordance with the schedule; minimizing the amount of micro forks.
Replaying, indexing and just keeping nodes in sync is going to require more resources and performant hardware than what is needed today. This is likely to put a strain on peering nodes where we will need our block producers to step up and to provide more stable access to the blockchain.
For the overall state of EOS it would be good if more block producers and block producer candidates started to provide more reliable peering than what is available today.
The way we do this is to have a load balancer in front of multiple nodeos processes (haproxy in our case). We cut incoming connections to the nodes if they get out of sync and redirect them to one of the working nodes instead. When the node is back in sync it will be automagically added to the balancer again.
Investigating number of actions and amount of CPU per producer
Knowing what is in the queue at any given point of time is currently extremely hard. In the investigation below we are assuming that there are always transactions available for the producers to process into blocks — over time this should be close enough to the truth for this small investigation.
This graph shows the number of actions put into blocks per producer, over the last 21 days. Take note that EOS Nation tries to help the chain by processing deferred transactions — which are needed for example for on-chain-multisigs.
Over the last 24 hours the number of actions put into blocks per producer seems to correlate very well with the data over a longer period of time. The table below shows the number of actions per producer over the last 24 hours.
The number of actions put into the blocks by each producer differs widely. The total number of actions during these last 24 hours was 12,755,515 or just below 13 million.
From these two graphs we can see that the data correlates well between number of actions and amount of CPU billed per producer.
This data over the last 24 hours also correlates very well to the data over time (the last 21 days). This means that we can make things simple and only look at the number of actions instead of taking the amount of CPU billed into account.
The average amount of actions over 24 hours per producer is 607,405, or ~58% of what eosrapidprod produces.
Hardware and configurations should be compared and investigated closely so we with certainty can know what makes the difference.
When collecting this data we could see no correlation between more produced actions and missed blocks (over the last 30 days).
Looking briefly at NET utilization
It has been discussed multiple times by many different block producers, block producer candidates and influencers that we should change the billing of NET. We believe that a perfect opportunity to do this has now arrived. To start this investigation we provide the following data.
We recommend the community to look at the resources staked for NET and compare those to the resources staked for CPU for all users that have made any action on chain in the last three months. That data in combination with the data above (that we can help reproduce as needed in the future) should allow us to find and set fair pricing for NET.
Testing related to the new resource model
We are currently running tests on a private blockchain to try to simulate different possible scenarios that might come in to play with the new resource model.
As mentioned in this article we are particularly interested in the handover from one block producer to the next, when the chain is in congested mode and the chain is being heavily used…
This data is not ready to be shared as of yet… Stay tuned for part II…
Summary
With the required resources to interact with EOS, the barrier of entry is rather high and steep. The new resource model can potentially reduce this and allow for more users to easily interact with DAPPs and the chain. We see clear value in changing the resource model to allow for easier onboarding and a better user experience.
We will continue to run our tests and let you all know about the results and conclusions.
Website
Telegram
Github
- https://eos.io/news/eosio-resource-allocation-proposal/
- https://www.eosgo.io/blog/detailed-analysis-of-eos-rentbw-new-resource-model
- https://medium.com/@eosriobrazil/reflections-on-the-new-resource-allocation-proposal-for-eos-mainnet-6d9acc2ef950
- https://cointelegraph.com/news/what-crypto-exchanges-do-to-comply-with-kyc-aml-and-cft-regulations
