Ethereum style cycle metering and payment models for Dfinity Applications

DFINITY platform maintains a per canister balance of cycles and cycles can be transferred between canisters. The primary model that is anticipated is similar to a cloud services model where the developer charges their canisters with cycles and users will use the application without needing either ICP or cycles.

There are obviously situations where other models are desirable for example public good shared services, or where someone just wants to deploy an application and walk away leaving it totally autonomous.

Is it possible for canisters to follow an Ethereum style gas model. for some requests that is the canister:

  • Only processes requests accompanied by payment with cycles.
  • Is griefing resistant, and an attacker cannot use more cycles than they send.
  • Can provide an estimate via a query call of how many cycles are expected to be consumed.

This would seem to require:

  • Cycle/gas cost estimation functionality.
  • Combined send and call messages
  • Segregated metering i.e. distinction between canister and transaction balance.
  • User wallets

A related but slightly different use case is software as a service where an identity has some ‘account usage balance’ that is tracked . This metered usage balance might include cycles consumed on the IPC as well as application specific metering. Further the SAS provider would want to prevent abuse and ensure that malicious customers who have either pre-payed some small amount or will be billed retrospectively cannot grief the system and consume too many cycles

This would seem to require:

  • Cycle / gas cost estimation.
  • The ability to access metering information from within a canister.
  • The ability to “out of cycles” exception based on per user / per operation criteria rather than canister balance.

Are there any plans to support these kind of models either directly or by exposing metering to developers?

5 Likes

** Bump ** I want to know too.

1 Like