We have been hard at work on the 2nd version of Fuel and the evolution is progressing rapidly at this point. Last year we showed off what it will look like to add transaction-based fees, and recently we teased out a transaction from one of our development Fuel servers which showed something new:
Fuel offering RAM to an account, for a fee, that didn’t have enough to perform the given transaction.
For over a year now we have been providing CPU and NET for those in need through Fuel - and soon with the addition of RAM we will have all 3 resources on the network covered. Today we’re showing what that looks like, end to end, from an example dapp into Anchor for signing. For context…
- The example below shows the ihasnocpunet account logging into an example dapp.
- This account has very little tokens staked, no rented resources, and no available RAM.
- The user wants to use the dapp to vote for teamgreymass as a block producer.
- The user is going to click a single button programmed to perform this action for them.
With all that in mind, this is what the end user see’s during this process…
To break down what’s happening here, I’ll outline the steps and information shown to the user. It still needs a bit of refinement to really simplify the displays down, but at this point is the most streamlined experience that exists.
- The user is first prompted to login. They click the button below the QR Code since they are using Desktop, which opens Anchor, and they approve the login request.
- The user is now logged into the application and it displays a single button they can use to vote for Greymass. They click it to perform the action.
- Behind the scenes, our Fuel APIs, acting as a resource provider, kicks in and check to see if the transaction could be successful without intervention. It determines it cannot be completed as-is, the user doesn’t have the required CPU, NET, and RAM, so the API responds with an offer to add a fee to complete the transaction.
- The user interface receives this response from the Fuel APIs and prompts the user, letting them know in order to proceed, a fee is required. It displays the amount and how long this offer is valid for. This wouldn’t appear if the user had the required resources of their own. However in this instance since they do not, instead of just showing an error and telling the user to go fix it, it offers an alternative path forward.
- The user accepts the fee - which then sends the transaction to their Anchor wallet for approval. Within Anchor, the user can see the transaction, and a new tab is available called “Transaction Fee” which shows them a breakdown of what the fee is for.
- In this instance, the CPU/NET is free. Fuel is offering to cover those resource costs for the user within the free quota it gives users each day. However, the account also needs RAM - which needs to be paid for. The transaction fee breakdown shows this as the source of why there is a transaction fee. If the user also had no free quota available, the CPU/NET fields would also show proportional fee amounts.
- The user approves and signs the transaction in Anchor, it is sent back to the external application, and the transaction is successfully submitted to the blockchain.
In the not too distant future, these changes will be deployed live to our API servers and made available to any application integrating with the next versions of our Anchor SDKs. The users of those applications will benefit from not having to worry about CPU, NET, or RAM - unless they want to.
To begin with, these features will be exclusive to Anchor. Expanding these features outside of Anchor will require additional development within the more generic EOSIO space - but it is our goal over the course of the year to make them available for any desktop, mobile, or hardware wallet. It is also our goal to publish specifications that can be used as standards to allow multiple Fuel-like services in the wild, giving consumers a choice in who they obtain these resources from.
Understanding the problem in UX with EOSIO resources
As a brief primer to really understand the problem this solves, we are going to look at the block producer voting action as shown in the example above. It’s an action users are encouraged to perform to select the block producers to help secure the network. Voting on the EOS network requires 3 kinds of system resources:
- CPU, to cover the computational power needed execute the vote.
- NET, to cover the bandwidth costs of the data being sent to the network.
- RAM, to apply and retain that vote in the blockchain’s active state (memory).
These same resources are required for most types of activity on the network. Up until the advent of Fuel, users had to understand this - or the transactions they were trying to perform would fail. The user needed to either rent or stake tokens to CPU and NET to cover those costs, and they also needed to purchase RAM from the system in some cases. This all had to be done manually, by the user, and if done incorrectly they would get errors such as:
Transaction failed - billed CPU time (1342 us) is greater than the maximum billable CPU time for the transactions (71 us)Account using more than allotted RAM usage.
These errors would occur after the user tried to perform an action, interrupting them, and putting them in a situation where they had to go learn how to resolve the problem. Most of the time this required asking for help and then retrying the action they were trying to perform in the first place. It’s a bad experience.
Most end users aren’t going to understand this process, nor care to learn how to manage this all themselves. This is one of the largest hurdles in this ecosystem, and a huge point of frustration for so so many users. It’s the reason we have dedicated time to building out and seamlessly integrating Fuel into the ecosystem. It’s a proactive approach that lets the users do what they need to do, as opposed to the retroactive approach of “go fix it and try again” the EOSIO ecosystem has taken so far.