Charge a small fee for "opening" a transaction.

[robert-zaremba]

Summary

ValidateBasic is executed both at CheckTx and DeliverTx but we don't charge any fee, and if it fails we do a free computation for "opening" a transaction, but the resources are not free.

Proposal

Charge a small fee in DeliverTx by updating on of the existing middlewares or adding a new one.

Ref: #10680 (comment)

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

So you just want to charge gas for ValidateBasic calls. But what do you charge? Each implementation can be drastically different.

[robert-zaremba]

Maybe 100gas... so 10% of DefaultSigVerifyCostSecp256k1

Each implementation can be drastically

That's why i want to recommend in #10680 that we app developers for their own safety won't do nothing expensive in ValidateBasic.

[aaronc]

Regardless of gas, it seems like the real issue can only be solved if there is an account to pay fees. It's possible to spam a network with transactions that fail signature validation but use resources. They should be filtered out in the mempool. The real solution would need to be some way of penalizing validators that propose blocks with transactions that fail signature validation and/or have no tokens. Of course, sequence errors we can't do anythin about I think but up to that it should be possible.

[alexanderbez]

You mean punish validators for including txs in blocks that fail CheckTx?

[fdymylja]

You mean punish validators for including txs in blocks that fail CheckTx?

I don't think everything that might fail in CheckTx can be punished, only stateless checks (validate basic, sig verification, etc)

Also I don't think charging fixed gas for any validation is fair. A msg containing a validation of the likes of msg.field != zero value has a totally different computational overhead if we compare it to something like sdk.CoinsFromString(msg.coins).

[alexanderbez]

Right, so I'm having a hard time following exactly what the proposal is here.

[robert-zaremba]

The proposal is to create a new middleware to charge additional small fee during DeliverTx for "opening transaction" - that would be right after signature check. It can be configurable, so chains can set whatever they want, but have a sane default in the simapp.

[robert-zaremba]

It's possible to punish validators who broadcast txs with failed staeless checks. Validator must sign a brodcasted tx. That would make sense. let's add this issue to Tendermint repo.

[tac0turtle]

t's possible to punish validators who broadcast txs with failed staeless checks. Validator must sign a brodcasted tx. That would make sense. let's add this issue to Tendermint repo.

This can be done with only the sdk, it knows the txs in the block and it knows the proposer. Nothing needs to be added to tendermint to make this work.

also broadcast and propose are two different things, what is being suggested by Aaron is propose