Lean & Agile Approach For EOS Resource Model

Image for post
Image for post

This article assumes the reader has a firm understanding of the current EOS resource model and the proposed resource model. Several teams have outlined descriptions and responses that can be viewed in this document.

As a block producer (BP) and developers of Chintai, we are very excited by the proposed upgrades to the resource model. Allocation of network resources have been a core focus of our team. The first leasing market for EOS CPU/NET was launched by Chintai nearly 7 months before REX. About 6 months after deploying Chintai we launched an automated resource allocation system called Charm.

The new model aims to make pricing more predictable while utilizing the entire pool of available network resources, rather than a small fraction. In the spirit of efficiency we believe an important element of consideration for the new model is whether or not multiple pools should be made available (i.e. multiple pools with different configurations for multiple user types). We also stress the importance of allocation mechanisms being crucial when making decisions about the configuration of the resource model.

Unpredictability For Major Network Changes

Having closely observed the original resource model, network governance and changes made thereafter, we can confidently assert that it is near impossible to determine the full range of potential outcomes for a major network change. Furthermore, every network change requires a considerable amount of observation before a reliable sample size is established. Only then can conclusions be drawn that lead us to informed optimizations.

For example, before REX was launched there was very little apprehension about the model. REX made resources cheaper and more efficient to access. But REX did not drive EOS off exchanges like many predicted, only a small fraction of the total EOS supply was staked to REX, liquidity went to zero for a period of time which locked the system and on multiple occasions it was used in mining schemes of questionable value. Many of these outcomes were not expected. The same unpredictability was observed throughout the evolution of EOS governance. What “we” thought would happen was always met with surprise.

For these reasons, we believe the best approach for deploying the new resource model is baking in what we do know — there will be outcomes we do not expect. Some outcomes will be positive and some negative.

Macro Approach: Agile

An important feature of the new resource model is the way it is designed to help EOS smoothly transition off the current model. Rather than a blunt on-off switch, the new model can be introduced in stages. For example, any percentage of the resources on EOS can be delegated to the new model, while leaving the remaining percentage in the legacy model. This feature could be used within the agile and lean framework.

Agile and lean is a common product development framework based on trial and error. Product features are quickly trialed to make continuous changes that better serve users and overall development of a product value proposition. The process generally looks something like this:

  • Rapidly add and deploy multiple variations of a product feature
  • Observe how those features are used and gather data
  • Make conclusions based on the data to inform you product development
  • Throttle back the features that are not considered beneficial while emphasizing those that best achieve the goal of a product

This approach is commonly used for businesses of all sizes and has proved to be very successful. In this case we believe the technical agility afforded to us in combination with the degree of uncertainty about outcomes would suggest using multiple pools is profoundly beneficial compared to deploying a singular pool. After gathering data we will be able to make better decisions on which pools to emphasize and which pools to discontinue or diminish.

Much of the community discussion about the new model is exploring tradeoffs for various configurations. For the most part arguments are based on the “one size fits all” approach. In reality, we believe it’s unlikely one size will fit all. Multiple user types with multiple needs will mean multiple allocation mechanisms. We’d like to see experimentation early on with multiple pools that allow business and users to experiment before determining which configuration is best.

To further punctuate why a multiple pool approach might be best long term is our knowledge about the culture of change on EOS. We agree with Yves La Rose in his recent assertion that “the appetite for change” diminishes after a major change is made. We believe this cultural tendency is in part due to changes being made without mode of comparison. It’s difficult to rally motivation and consensus for additional changes without comparisons, especially if an orignal change led to unexpected outcomes that were not beneficial.

In the case of an agile and lean approach, we would have a much larger data set that provides increased in clarity, which could help with apprehension about making additional changes. With an increase in clarity we suspect changes would be more palatable since we would have a clearer path to improved outcomes.

Multiple Pools and Resource Allocation

By providing multiple pools we expect a multitude of business models to emerge in the form of “resource providers” (RPs). The new resource model is set up for RPs to act as a broker between the resource pools and various user types (dApps, end users, investors etc.). RPs can charge a premium on seamless allocation and risk associated with reserving CPU for each user type. RPs are capable of delegating resources for various time frames i.e per transaction, 1 day, 10 days, etc.

Each of these user types has specific needs, tolerance and technical savviness in regards to network resources. One size will not fit all, which is why we suspect RPs will have vastly different approaches to allocating resources depending on user type. This process will also take experimentation to ensure profitability.

We suspect that providing multiple pools maximizes a competitive environment that will promote creative business models and open source tools that can only be discovered through trial and error in an open and live system. This outcome was observed when multiple allocation mechanisms emerged from the current resource models. Chintai, Dunya labs, CPU emergency, Fuel, bloks.io, CPU payer, and bank of staked all have unique implementations of resource allocation. Chintai specifically had 4 rental periods (7,14,21,28 days). Most liquidity moved to the 7 and 28 day market.

Some users types may want long term rental periods that ensure access at a predictable rate for long periods of time. It’s not uncommon for businesses to pay annual fees for services. We would not be surprised if long term rentals were used to lock in long term rates that help businesses create predictability. On the other hand, some user types may want to pay for resources on a per transaction basis. RPs could accommodate this need as well.

Long term and short term rentals are hypothesized to have issues that might outweigh the benefit. For example, long term rentals could result in wasted resources. This might encourage using excess CPU for mining since getting something is better than nothing. On the other hand, a per/transaction rental pool could be costly for network overhead. Per/transaction allocation could be done by RPs, but it’s possible that building a business model based on per/transaction could prove difficult, especially if CPU prices are volatile.

We think it’s premature to determine how RPs would best utilize various pools and have some doubts about the potential for profitability. For these reasons, our suggestion is to start with four pools, observe, collect data and make adjustments as necessary (some suggestions below in the configuration section).

Charm & End User Allocation

Charm is a 3rd party dApp built by Chintai that allows users to automatically purchase resources on an as-needed basis. If an account goes below a predefined threshold, resources are automatically purchased from REX to increase a given resource over the predefined threshold. You can also set a maximum price that you are willing to pay for resources.

We built this system to help alleviate common complaints about UX. The learning curve for understanding resource management is steep for most people. New users are bombarded with resource issues that oftentimes leave them feeling frustrated and alienated by developer terminology. In most cases users don’t want to understand resource management and nor should they be faced with the challenge in optimal circumstances.

In effort to remove resource management friction a “Charm like function” could be provided in tandem with the new resource model. Every account could come ready to use out of the box with the ability to buy resources as needed on a per/transaction basis. Most users simply want to use EOS. Having the ability to pay a small fee to use a dApp that doesn’t already allocate resources would be a major leap in not only the UX of EOS, but for the industry as a whole.

It’s important to note that a per/transaction pool does have some theoretical concerns about overhead. It is currently unknown whether or not the tradeoff for UX would outweigh the potential overhead. We believe it is worth experimentation, which aligns with our vision of multiple pools.


Determining ideal configurations is going to be difficult and take some best estimations. Every configuration has specific tradeoffs. Aarin Hagerty spoke to the difficulty in determining which rental period is most efficient (balancing the theoretical needs of RPs, network usage trends and network capacity) and concludes that it is not immediately obvious which is the best approach.

It isn’t obvious which rental period is more efficient. So for example, say the usage on the weekend is 5 times the usage during the weekday. That means even a resource provider will be wasting a substantial fraction (approximately 57% in this case) of their rented capacity with a 30 day rental. (Of course they could use the idle time to do something like mine, but that is a matter of opinion whether that would still be considered a waste or not.) The system would need to over-provision by 3.3% (1/30) to ensure it isn’t over-subscribing its resources. So the total overall efficiency of the resource provider compared to some ideal capacity would be 44.3%.

With a 1 day rental period, the resource provider can use nearly 100% of their available capacity. But the overall system has to carry the burden of inefficiency to avoid over-subscription. So it may need to only make half the available real capacity available for renting. That means the overall efficiency of the resource provider compared to some ideal capacity would be 50% in this case.

Of course these numbers can radically shift as user usage patterns change.”

Given the difficulty determining which configuration is best, we believe this is more reason to support the idea of multiple pools in effort to commence a fluid discovery process.

We propose introducing 4 pools with the new resource model simultaneously that initially accounts for 5% of the total network CPU/NET in each pool. This would leave 80% of the CPU in the old model. The goal would be to introduce a 5% increase for each pool at regular time intervals to slowly transition. Since we do not know how this will work in real time, we suspect some pools could be discontinued rapidly while others could be favored to take more of the total resource allocation.

Generally speaking we could experiment with the following pools:

1) Per/transaction pool
2) Short Interval
3) Medium Interval
4) Long Interval

Multiple Pools & Mining

CPU mining depends on the ability of a project to create a market that is almost entirely built on greed, hype and euphoria. Profitability is only maintained so long as greed and euphoria is not exhausted.

While there have not been any mining schemes in the recent past, we can assume more will occur. Especially if RP’s need to make profits on unused CPU to support their business model.

There will be inflection points where arbitrage becomes profitable enough for miners for every pool. For these reasons, we believe it’s best to deploy several pools and see which are commonly used for yield farming and which are not.

In the case of RP’s, if they cannot maintain profitable business models based on allocation of resources from a pool they will turn to other means for profit when resources have not been resold — potentially mining. For these reasons, we believe it is very important to cast a wide net and allow efficient business models to emerge out of multiple pools. The pools that lead to an increase in mining may need to be discontinued.

It is possible that some pools will not offer a viable opportunity for yield. For example, long term pools may be profitable at first, but could expose miners to long term uncertainty and losses (price of CPU outweighs gains from mining). This is where we believe RP’s would be particularly prone to mining. Alternatively, It’s easier to predict what will happen in the next week vs. one year from now. It’s possible that short term rentals, especially per/transaction markets would be used for this purpose regularly. This could result in a “stabilizing” force in the EOS resource economy by creating a price floor in which mining will commonly emerge.

EOS42 — Pioneering a Decentralized Future


Written by

EOS42 — Pioneering a Decentralized Future | 开造一个去中心化的未来 | 탈중앙화된 미래를 선도합니다 | Telegram: https://t.me/EOS42 | EOS ID: eos42freedom

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store