EOSCommunity.org Forums

Fuel as a system contract

I think it would be good to explore the feasibility of promoting Greymass Fuel from a layer 2 service to layer 1 system contract.

Quick rundown of Greymass Fuel for those who aren’t familiar with how it works: It’s a service run by Greymass that exposes a HTTP API where users can submit a transaction (or EEP-7 signing request) and get a modified transaction back where the greymassfuel account is the resource payer, along with a signature to approve the transaction. The user can then sign the transaction and submit it to the chain to transact without having resources staked or rented.

The resources for the service can be paid for in the following ways:

  • Free quotas per user account or smart contract account (designed for staking, likely to go away with PowerUp deployed)
  • A pre-paid balance on a smart-contract that fuel maintains
  • Transaction fees appended to the transaction returned by the service

To achieve this the service employs a “taste-tester”, which is a nodeos instance with a patch applied that allows it to push transactions without the required authorizations (and immediately roll them back). The taste tester node is what allows it to figure out how much resources a transaction would use and what fees to charge (and even buy RAM for the user if it’s needed).

I think implementing something like fuel at a system contract level would be a great complement to PowerUp.

Question is how hard would it be to implement something that would allow a contract to access the metering information? E.g. where the last action or some special deferred inline action could user.balance - usage_us; assert(usage_us < max_usage_us && user.balance >= 0)

3 Likes

Exactly! That is what I’am thinking about for a long time. This will make EOS much more convenient.

I approve of this, eosio is missing some needed resource management infrastructure.

Does implementing it as system contract allow for exploit?
If there are no vulnerabilities, what are the cons?

I clearly see the benefits

NET and RAM: Easy. See spec-repo/esr_query_consumption.md at master · EOSIO/spec-repo · GitHub

CPU: More work, including changes to the block format. See spec-repo/esr_subjective_data.md at master · EOSIO/spec-repo · GitHub

Both are hard forks.

2 Likes

I have talked about this at length, both in private channels as well as in public Telegram channels, so I figured I’d take a bit to lay out my thoughts on the pros and cons of something like Fuel operating on-chain. For this post, I’m specifically referring to a Fuel-like system that uses a prepaid balance which is deducted from as the user performs transactions.

My current thinking, and I could be completely wrong, is that an off-chain service like Fuel is going to be more efficient for the network than an on-chain solution with similar features. This will be especially true for the party responsible for the costs of that transaction, unless the network subsidizes the extra resource consumption the blockchain needs to process the Fuel-like functionality.

The analogy I have tossed around is simple token transfers. Currently they range between 200-300ms of CPU usage per basic token transfer. Just for simplicities sake, let’s assume this has a cost of 1 (or 0.0001 EOS) for 200ms of CPU.

If a prepaid balance were maintained on-chain, that simple token transfer now also needs to perform:

  • Additional checks against that users balance.
  • Computing estimates and calculating resulting fees
  • Table row updates to the users balance.
  • Potential recording of the results of the fee transaction.

All from within the Fuel-like system contract. These actions are going to take extra CPU to perform (unless subsidized by the blockchain) and increase the usage to a number higher than the 200ms the transfer would have originally taken, which increases the original cost of 1 by the same factor.

Just for the sake of an example, let’s say it’s 2x the cost. If the average user is presented with a choice:

  • Pay 1 to use the off-chain option
  • Pay 2 to use the on-chain option

Which do you think they will choose?

I’m pretty confident most users are going to go with the cheaper option. The reason it’s cheaper is because the accounting and estimation is done off-chain.

Now, that’s not to say the on-chain method is not worth the increased cost. It very well might be, especially in situations where the off-chain methods end up censoring specific things or becoming unreliable. The fact that an on-chain system is not operating on a central server can be viewed as a positive - it just comes with an increased cost to whoever is paying for that transaction to occur.

When considering to develop an on-chain solution, these in my opinion are important concepts to think about to justify whether or not its worth the time and effort in building it. For most users, I really believe they would be willing to sacrifice these features for cheaper transactions.

That’s very interesting, looks like it would be doable with the additions specified there! The BP provided RNG opens up some cool possibilities as well. Do you know if there is a specific reason it hasn’t been implemented yet?

Yeah ideally the system contract would subsidize the overhead it introduces.

We had other projects that took precedence

1 Like

I think one should keep in mind that you are not necessarily giving up decentralization to a significant degree just because it is off-chain. Yes, a particular off-chain resource provider is using a centralized server, but if there are many resource providers in competition with one another then the overall system could be quite decentralized. This is especially true if they are all using a standard API (which I believe is what you are trying to achieve with Fuel if I am not mistaken) that all wallets and resource providers could integrate with, so that the barrier to switch over from one resource provider to another is minimal.

If there is basically no cost to switch between resource providers and it is as easy as a a few clicks, then that competition should in theory cause the resource providers to avoid doing the undesirable things that users may be worried about when they think about having this service provided as a first class system contract, e.g. censorship or high profit margins.

Another thing to consider is that the competition between resource providers can allow them to provide a greater diversity of convenient resource packages to the end users, rather than forcing everyone into the limited options coded into the system contract. Perhaps some resource provider businesses find a smarter algorithm for throttling users that meets their expectations 99.9% of the time but allows them to get away with powering up a much lower quantity of resources and thus end up charging cheaper rates than competitors or even what the system contract would have charged (e.g. because the system contract was being conservative in its algorithm).

Very true. I talked with @johan a bit more on the topic and I probably should have chosen different words. He described the current system as “fragile” (which it could be in some senses), which could occur if it was not “decentralized” enough (in a sense, maybe not the way crypto users typically apply it) and the broader system didn’t have enough providers.

I’ll let him weigh in on that if he wants.

That’s definitely the intention. We have a pretty well rounded API schema defined at this point, which we might as well publish as a standalone piece of documentation to start getting eyes on.

Also very aligned with our current intentions. This portion will likely come later though, as it’ll require cooperation of both the Resource Provider API specification and probably a new wallet layer SDK similar to that of UAL.

2 Likes

I think a good way to solve this problem is to establish a state channel contract, and then put the operation of payment for resources off-chain. Resource providers like gm can simultaneously become intermediate nodes of the Lightning Network. At the same time, this state channel can also be used to make small payments for streaming media or other network services (such as ipfs).