Lisk-sdk: Assign and verify transaction fees in Transactions domain

[MaciejBaj]

Expected behavior

Transaction fees should be assignable as part of created transactions extending BaseTransaction interface, e.g. by creating a new static FEE property.

• fees of transactions should be verified in validate step of BaseTransaction.
• it should be possible to create "zero fee" transactions extending BaseTransaction interface

Actual behavior

Fees for transactions are defined in the framework - controller/schema/constants_schema.js.

It is not possible to send "zero fee" transactions.

Which version(s) does this affect? (Environment, OS, etc...)

*

[michielmulders]

This is a wanted functionality upgrade!
One small comment: I'm not sure if zero fee transactions are actually a good thing for the Lisk Ecosystem - also related to DDoS the network? I agree, when running your own blockchain, it does make sense to have this possibility.

[pcdinh]

@michielmulders It is up to delegates to decide which tx is valid and included into blocks. As of now, client can send zero-fee txs. Are they valid txs? No. Moreover, the change is about programmability, flexibility. It is not about possibility to have zero-fee transactions in LISK

[pcdinh]

@michielmulders Zero-fee txs can be a desired feature in some sidechain apps. Imagine that you want to build a system in which accounts must pay in advance to use the service in a specific period of time. Think of precompiled smart contracts. After that zero-fee txs are allowed. Another rule can be enforced like: prepaid accounts can send 1000 txs/day at maximum. It really makes sense to have 0-fee txs in some business cases.

[shuse2]

Although this property will be removed, I agree that user should be able to set the Fee in their custom transactions.
For zero fee as @michielmulders pointed out, if the SDK is used for public chain, it will definitely be a security hole for DDOS.
However, I think in private chain, there might be usecase for the zero fee.

[michielmulders]

@pcdinh Thanks for your comments! Good to see some discussion here. I like your idea of having to pay in advance and give the user the "right" to use zero-fee txs. It definitely makes sense for sidechain apps. As Shu mentioned, for SDK public chain, I feel this is too risky/not enough researched to experiment with such behavior in such setting.

[Korben3]

It might be possible already with not much change to the sdk code and actually implementing 0 fee's:

• User pays $100 a month to make max 100 tx a day.
• User receives 100 tokens. Hidden from the user.
• Each time a tx is sent in the background it also automatically sends a tx fee, still hidden from the user in his/her frontend application.
• Next day user receives another 100 tokens.

A custom module might handle all the logic to keep things decentralized. It's already possible to implement if you'll let a centralized app accept payment and send tokens until no more payment is received.

The key is hiding the fees from the user, assuming you'll have a custom wallet made.