Our team supports the shift of the EOS network towards the proposed resource model by Block.one - but want to emphasize that this is the first step of the many which are needed as part of a more comprehensive solution. Only after further iteration and development will the network and its ecosystem hit the point where it’s capable of effectively delivering resources to end users and achieve meaningful adoption.
Expectations should be tempered to match this reality. That being said - we do believe this is an important step forward that establishes a foundation for future innovation. It helps reduce friction in many situations the network could face, in both usage and adoption - as long as the this process continues to evolve.
Assumptions
As a primer for the content of this opinion piece, and without expressing the opinions of Greymass on the matters below, the following statements are what we believe to be true under the proposed new resource model:
From the perspective of the network…
- It WILL increase the amount of network resources available for rent.
- It WILL increase the number of transactions per day on the network.
- It WILL reduce the amount of idle and unused network resources.
- It WILL NOT eliminate congestion on the network.
- It WILL NOT eliminate idle and unused network resources.
From the perspective of user experience…
- It WILL reduce the cognitive load of users by reducing the number of options available to obtain raw network resources down to one.
- It WILL require more effort to maintain a specific level of network resources on an individual account.
- It WILL NOT make the user experience of those seeking resources much different than that of using REX.
- It WILL NOT be an easier implementation for wallets.
From the perspective of the resource market…
- It WILL assist in better price discovery of network resources.
- It WILL offer more predictable and smoother price movements.
- It WILL lower the cost of renting network resources (temporarily?).
- It WILL NOT guarantee an increase of APR/yield as compared to REX.
Some of our assumptions here may be incorrect - and we would welcome the debate on any of these individual points if you feel we are misrepresenting this information. We will be happy to correct our position and adapt this content should any of them be proven incorrect.
Deciding the configuration and how to deploy
There are a couple questions that we believe need to be debated and decided upon, which will lead to the optimal configuration values and broader plans for this new resource system. We ask these questions to try and help frame the conversation and help move this process along.
Who is this rental system being designed for?
From the side of the market where rentals are occurring, a decision needs to be made whether the market is being designed for:
- End users utilize it directly with their accounts.
- Resource Providers to redistribute to end user accounts.
Clarification: Resource Providers are systems built to provide free or paid-for transactions to users, examples being Fuel, bloks.io, TokenPocket, and Wombat.
The needs of these two groups are at odds in some aspects. Compromises on behalf of one group or the other may have to be made if an attempt is made to accommodate both, where as coming to a decision to prioritize one over another may prove to be more optimal.
As one example, the rent_days configuration option in the new proposed resource model. This parameter defines the term of the rental as a fixed number of days (30 by default, REX is also 30). A lower amount of days provides an optimal value for Resource Providers, allowing them to more accurately manage costs and pass those savings on to their users - but by lowering this value the end users managing their own resources would have a higher burden having to renew their rentals more often.
Knowing who the target audience for the system itself will help us make informed decisions, and make the bigger architectural decisions that will need to happen in the steps beyond this individual proposal.
Currently we are exploring what the ecosystem would look like if optimized for Resource Providers over End Users, including the reduction of rent_days down to the lowest possible value which won’t create a burden on the system. Dexaran included some thoughts on this topic in the “Observations” section of a well done analysis. If time allows, we may dive deeper into this topic and explore the advantages and disadvantages of different values for this particular setting.
What is the priority of optimizing resource usage?
Currently under both the proposed resource model and the existing resource model, situations can occur where network resources are wasted. Here we are defining “waste” as network resources (CPU mostly) that was allocated to a user for use, but went unused.
Defining the level of priority on reducing waste will inform decisions regarding the configuration of the rental market. It may also help prioritize what some of the next steps after the deployment of the new resource model would be - like exploration into alternative models that may include a form of “rollover” or different resource replenishment models.
What rate does the system shift from the old model to the new?
The proposal needs a well defined process for its rollout onto the network. It cannot be too fast, or two slow, but instead needs a pace which provides enough time for adjustments and prevents system shock.
If the rollout moves too slowly - prices may be unpredictable and create scenarios for resource consumers where market prices artificially spike for periods of time. If the rollout goes too fast - applications may not have time to adjust to the changing conditions and their users may suffer instability or outages.
Can a gradual rollout over a set period of time, where resources shift from the old system to the new, achieve a stable enough transition to avoid these issues? If so, at what pace does it occur? Would a hard transition on a set date in the future without the gradual transition work better?
This topic is one for debate, and will take more time and effort to come up with the right answer for. We are unsure of the proper approach, but look forward to diving deeper into the pro’s and con’s of any and all approaches.
What scope does the MVP of this system extend to?
Many other proposals from other organizations in the EOS community have pitched some ideas worth exploring, but having a well defined scope for this individual proposal will also help clear a path forward.
Currently as we have been viewing this proposal, we are limiting our scope exclusively where network resources are allocated and how a consumer of resources gains access to them. That scope may even be too large, considering some modifications also fall under this umbrella but would add additional complexity. These topics include:
- Creating more than one option for the duration of each rental.
- Adding a fee-based model to provide the ability to pay per-transaction.
- Creating staking pools with different lockup mechanisms.
- Allowing sponsors of transactions on-chain.
It’s our belief that delivering small incremental steps in a bigger process here is key - but actually defining the scope itself for this step will help then determine the next steps. This proposal should not be the end of the process to improve the user experience as we keep reiterating. Further steps can and should explore additional concepts like listed above for inclusion in the network.
Additional topics to keep an eye on
Without spending excessive an amount of time researching and writing about this proposal, we feel there are a number of additional topics that warrant thought which we simply haven’t had time to write about. These topics include:
- The tax implications and burden the system may place on end users.
- The impact the rental market will have on both the size of the blockchain and history solutions.
- The overall cognitive load end users will experience under the system.
- The impact removing resource rights from the token will have on existing users.
- The communication strategy across the EOS community regarding the final changes.
Each of these are also important pieces of the decision making process that should be factored into decisions made by the leadership of this community. We will continue to pursue these topics as time permits and convey our opinions on the matter.
Our vision on the bigger picture, as it stands
As mentioned in the opening of this piece, we stated that the Resource Rental Market is the first step of many. The path we are setting out on is one to improve the end user experience in terms of usability and comprehension, to help users gain access to resources, and ultimately towards driving adoption.
While this individual proposal seeks to increase the availability of resources and has the potential to improve accessibility, it will not push EOS across the finish line into a usable state for many users and use cases. Exploration into further incremental improvements can be made to the system in the future to continue to refine these processes.
The big picture also includes far more than just resource management, it also includes onboarding, education, standards development, and user support.
The fully realized accessibility solution for resources we believe exists off-chain for the end user and is largely dependent on Resource Providers to step up and offer incredibly easy to use solutions. Our efforts in the wallet abstraction layer, wallets, and resource provider technologies reflect this belief, and we will continue to push as an advocate of the average user as we continue building for EOS.
A disclaimer of our potential bias
As it is with all things, these opinions are not without a bias. The experience our team has gained working deeply with wallets (Anchor, eos-voter), signing protocols (ESR, anchor-link), the wallet integration layer (anchor-link, UAL, and Transit), and SDKs in general (eosio-core, swift-eosio) has shaped our views on what we believe are best for the ecosystem as a whole.
We recognize this bias exists and welcome any push back on our opinions if it becomes too strong of a driver. We do however truly believe that the direction we have pushed over the past few years is what is best for adoption of the network.