archethic-node icon indicating copy to clipboard operation
archethic-node copied to clipboard

Leverage fee as an anti-spam solution

Open samuelmanzanera opened this issue 1 year ago • 2 comments

Is your feature request related to a problem?

Blockchains protocols usually leverage transaction's fees as a way to prevent failed transaction & spamming. While it's true, in our current implementation, the transaction is not accepted if the pending transaction validation failed, causing resource consumption for the network for nothing. The transaction's fee is not leveraged enough to incentivize good transactions.

Describe the solution you'd like

The idea is to use to accept a transaction where the pending transaction check failed, and to flag it as failed using the Validation Stamp error flag.

We might have to prevent a transaction to being validated if the previous signature is invalid; otherwise we could not guarantee the chain's integrity & ownership. In that case, it's an invalid transaction and not a failed transaction.

So finally, a failed transaction will be replicated, and the fee will be consumed.

This will even become more useful when the smart contract recipient's code validation will be implemented to prevent invalid contract's transactions or violating a chain's conditions.

Additional context

The UI might be adapted to print the invalid state of a transaction.

Epic: #306

samuelmanzanera avatar Mar 15 '23 15:03 samuelmanzanera

We should also take in consideration for smart contracts, we should add an index for the last valid transaction, particularly for smart contract / web hosting (aeweb), as the previous during mining might be invalid and the same for the latest transaction.

samuelmanzanera avatar Mar 27 '23 14:03 samuelmanzanera

Probably, a branching solution as a fork of the main chains can be used to avoid pollution of the validated chain. Hence, all the KO transactions will go in that branch. The latest transaction will remain the validated one. Multiple attempts of a failed transaction will be possible in this KO's chain, and being auditable. The workflow will remain almost the same, except the transaction will not be stored in the validated chain.

However, a logic needs to be provided to apply fee as spend input to reduce the balance of the previous transaction.

samuelmanzanera avatar Mar 28 '23 07:03 samuelmanzanera