Assign and verify transaction fees in Transactions domain

LiskArchive / lisk-sdk

🔩 Lisk software development kit

https://lisk.com

Apache License 2.0

2.72k stars 456 forks source link

Assign and verify transaction fees in Transactions domain #3860

Closed MaciejBaj closed 5 years ago

MaciejBaj commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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.

ghost commented 5 years ago

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.