Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add provision to support free transactions #3193

Closed
4 tasks
svaishnavy opened this issue Dec 26, 2018 · 10 comments
Closed
4 tasks

Add provision to support free transactions #3193

svaishnavy opened this issue Dec 26, 2018 · 10 comments

Comments

@svaishnavy
Copy link
Contributor

svaishnavy commented Dec 26, 2018

Summary

Add the ability to have zero-fee/zero-gas transactions.

Problem Definition

I am working on a cosmos-sdk based application. One of the requirements in my application is for witnesses to create transactions that certain external events indeed took place. I do not want to have fees/gas for those transactions created by witnesses in my application. I'm not sure how this could be achieved. Preliminary discussion on this is here: https://forum.cosmos.network/t/want-to-be-able-to-add-free-transactions-in-each-block/1470

What problems may be addressed by introducing this feature?
The problem addresses flexibility in paying transaction fees by Transaction type/User/etc..

What benefits does the SDK stand to gain by including this feature?
Adoption of SDK would increase with maximum flexibility in feature set. One limitation of current blockchain models is that it requires fees to add any information in blockchain. In majority of cases, the information may have to be obtained from external parties. Having a way to add these external information without fee would be beneficial in different applications and enables easier adoption of blockchains.

Are there any disadvantages of including this feature?
The first obvious thing that comes to mind with no fee would be DDoS/Spam attacks, however spam could be avoided in CheckTx step itself, by checking if the transaction is of certain type or if a transaction is from a set of users. So I do not see any disadvantages to including this feature in SDK. Moreover, the application could decide what fees should be collected for each transaction.

Proposal

The full requirements I can think of for this feature are:

  1. At the minimum, certain transaction types could be made free.
  2. (OR) we need transactions from certain users(witnesses in my application) free(whichever is easier).
  3. (BONUS) Transactions for certain users(holding '>x' tokens) could be made free.
  4. (BONUS) Enable subscription model, free transactions for users paying x tokens every 30 days.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@ValarDragon
Copy link
Contributor

IMO, the best way to do this is to parameterize our auth module with a gas meter implementation, whose "New constructor" takes in the tx bytes. This is significantly more general than the suggestion, and allows the suggestion to be implemented quite easily. Your situation would just be a gas meter that switch cased on tx type, if tx type == free type, use infinite gas meter, otherwise use normal gas meter.

@alexanderbez
Copy link
Contributor

This could perhaps be facilitated via the params

@ValarDragon
Copy link
Contributor

ValarDragon commented Dec 31, 2018

Since we don't want to encode functions in state (unless we have a VM language), wouldn't the parameter have to be "list of free tx types"? If so, isn't that something most chains wouldn't want? It would complicate the default auth implementation and require an additional param store read per CheckTx.

Or were you suggesting something more along the lines of facilitating gas meter selection via params?

@alexanderbez
Copy link
Contributor

... wouldn't the parameter have to be "list of free tx types"?

Yes. Probably something most chains would not want, indeed. Also not worth the extra read (although cached).

Or were you suggesting something more along the lines of facilitating gas meter selection via params?

Yes, precisely!

@ValarDragon
Copy link
Contributor

I'm not really sure thats optimal vs making the auth module take in a gas meter to use. You can then customize your gas meter as you see fit, and also give your gas meter access to params to change things dynamically. I think the set of possibilities is greater when you allow gas meter selection, instead of having a choice via params.

@alexanderbez
Copy link
Contributor

... and also give your gas meter access to params to change things dynamically.

I like this idea. Makes sense to me.

@hleb-albau
Copy link
Contributor

Also, the auth module can define more general extension interfaces, that can be used not only by gas meter but other staff. List of such extensions will be executed in extension points. Gas meter will be implemented via them.

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Jul 17, 2020
@robert-zaremba
Copy link
Collaborator

The transactions you are talking about - do you want them to be totally free? I'm asking because maybe x/fee_grant would solve this problem? It's a module to create grants for covering someone else fees.

@tac0turtle
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants