'Stake CPU and never use it' problem

• Dexaran: A Detailed Analysis of EOS rentbw New Resource Model
• Dexaran: The flaw of the legacy staking model was the fact that careless stakers were staking CPU and never using it thus putting physically available resources to sleep. I see that with this new model the flaw is that the network only counts actually rented resources i.e. if utilization is 0.9 then 10% of physically available resources will never be used in practice.
  Also if resources are super cheap then I can rent 100x more than I actually need and I will never use it which is similar to "stake CPU and never use it" problem. The difference is that staking is completely free while renting is not (unless the price of resources is close to zero). So the state of the contract at 1.0 utilization does not correspond to 100% of physically available resources being used from what you are saying. This looks weird in my opinion. The main goal of the resource distribution model is to ensure that resources are being used efficiently without downtimes and unutilized fractions. At least we can certainly calculate the amount of "100% CPU" available - it equals to 9.6 CPU hours per day for mainnet at the moment. If some fraction of this physically available resources is not used nor can be used even in theory then I would argue that it is a bad feature.
• Ralf - GenerEOS: I mostly agree with your analysis, however I'm not sure this statement about the proposed resource model is 100% accurate: "The main goal of the resource distribution model is to ensure that resources are being used efficiently without downtimes and unused shares of physically available resources." I believe (and I could be wrong there) that the main goal of the new resource model is to achieve a generally more balanced approach in terms of network utilisation (i.e. not too much under- or over-utilised) by keeping resources fairly priced and more predictable. Regarding the 'nothing at stake' problem i.e. unused resources going to be utilised in mining, I don't see this as a long-term issue. While this might potentially be the case initially, once more "useful" services get deployed on EOS, users will want to reserve their resources in order to be able to use those services and not waste them in mining. Alternatively those new services might rent the required resources on behalf of their users, which also will result in less capacity being available for mining. So I believe the issue of mining will naturally (and gradually) disappear with the network and provided services maturing. Also, I believe that the issue of "wasted resources" i.e. users having to rent resources for 30 days when they only want to transact once a week or less in my opinion is overrated. There will certainly be some users that might prefer to rent those resources themselves, I believe the majority of users will be utilising the likes of Fuel or similar types of 3rd-party resource providers. A 30-day rental period is not really an issue for a business / dapp that requires large amounts of resources (and I believe we should focus on those types of users as smaller users will most likely interact via wallets that can take care of resource management for them). I agree that some of the parameters could be and probably will be further tweaked (even after go-live, once we see the model in action) but overall I believe the new model will help achieve better utilisation of the available resources.
• Exception from GenerEOS official feedback on 25 Sep, 2020. The ‘Nothing at stake’ problem: Regarding the ‘nothing at stake’ problem i.e. unused resources going to be utilised in mining raised in [4], we don’t believe this to be a long-term concern. While this might potentially be the case initially, we believe that once more “useful” services get deployed on EOS, users will use their resources more sparingly in order to be able to use those services and not waste them in mining. Another quite likely scenario is that those new services will rent the required resources on behalf of their users, which also will result in less capacity being available for mining. We believe that the issue of mining will naturally (and gradually) disappear with the network and provided services maturing. The ‘Wasted resources’ problem: One problem raised in [4] was that users will have to rent resources for 30 days when they might only want to transact once a week or less, which will result in a large percentage of the allocated resources for that user to go “wasted”. Similar problem was also voiced in [5]. We believe that this concern is overrated. There will certainly be some users that might prefer to rent resources themselves with some of those allocated resources going unutilised, however we believe the majority of users will be utilising third party providers (the likes of Fuel or Charm) to manage their resources for them (and paying a fee for this service). A 30-day rental period is not going to be an issue for a business / dapp that requires large amounts of resources (and as we can see in our analysis further below, we believe that we should focus on those types of users when analysing the resource model at large).