search

provenance-io / provenance

A distributed, proof of stake blockchain designed for the financial services industry.
https://provenance.io
Apache License 2.0
90 stars 39 forks source link

Get rid of gas as a construct in provenance blockchain #1025

Closed arnabmitra closed 1 year ago

arnabmitra commented 2 years ago

Summary

Get rid of gas as a construct in provenance blockchain, and only keep the fee construct. Gas was a means to put a limit on the system, we should still set it as having a max threshold value internally

Problem Definition

In talking with @iramiller @derekadams we think it will really make client interaction simpler if there was only fee to deal with, in proposing tx's to the provenance blockchain and to get rid of the gas construct. So Proposal is to get rid of gas as a construct in provenance blockchain, and only keep the fee construct. Gas was a means to put a limit on the system, we should still set it(internally only) as having a max threshold value but clients need not set it and also pay fees based on it. i.e if messages which exceed max threshold(currently 4 million) will still fail so as to protect the system. Fees will be set using MsgFee module per message, for messages which are not in the list will be charged the min fee(let's say 0.,5 hash)

Proposal

1.All clients only pass in fee param with the flat fee required for that MsgType(or the base min fee if fee not defined for that Msg type)

  1. Clients can simulate the fee from the provenance simualtion endpoint
  2. We can change the cosmos endpoint if required, not sure if it's required.(and will add to the fork)
  3. Set every tx to start at gasmeter of 4 million (or whatever the max threshold is defined)
  4. If they fail because of running out of gas even at 4m (or whatever the max threshold is defined) then we take the fees provided.
  5. All failed tx's get charged the whole fee or a percentage of the fee, whatever is seen to be more appropriate.
  6. Fee table is to be set up as params in the msg fee module which already exists.
  7. Fee checks are already assessed in msgservicerouter for additional fees, so they probably will work similarly.
  8. wasm module also go through the same checks in msgservicerouter so should be maneagable to change.
  9. Major downside: Clients will have to understand this new construct but overall it should make the fee system easier hopefully.

For Admin Use

nullpointer0x00 commented 2 years ago

All failed tx's get charged the whole fee or a percentage of the fee would this be per tx type?

iramiller commented 2 years ago

I think we can't do "all of the fee" because of the original concerns with very large basis point fees and failed tx... we would likely need a "base fee" that we could add to every request ... this would also serve as a floor price on msg based fees ... something like 0.5 HASH that would be reasonable as a default for bank-send operations... the only catch I see with this approach is that it would be nice to be able to have certain tx with zero costs (like IBC relay associated tx for example)

arnabmitra commented 1 year ago

complexity noted here https://github.com/provenance-io/provenance/blob/feature/fee-only/docs/architecture/adr-001-no-gas-fees.md if we need it ever