search

archethic-foundation / archethic-node

Official Archethic Blockchain node, written in Elixir
GNU Affero General Public License v3.0
76 stars 23 forks source link

Leverage fee as an anti-spam solution #938

Open samuelmanzanera opened 1 year ago

samuelmanzanera commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.