Allow list of AnomalyTransaction types vs Explicit Hardfork

[igormcoelho]

Summary or problem description
Keeping a long-term history of blockchain is a challenging topic when the evolution of blockchain protocol itself is another important priority. In extreme situations, a hardfork can be needed, but it complicates code and protocol. Another option supported by some is to not keep the complete history of blockchain, which is in my opinion, the most drastic behavior. I want to add another intermediate option in an eventual situation where a past transaction behavior needs to be enforced in face of protocol change: create a list of AnomalyTransaction.

Do you have any solution you want to propose?
Create a new type called AnomalyTransaction and hold a list of it, read from disk (input by the operator). This way, if a single transaction fails in the past, during some upgrade, it could be cheaper and easier to manually list this transaction and all its intended effects (storage change, notification, etc) in a serializable format, and then load it when found on blockchain processing.
This way, the processing of this transaction will just be the loading of all relevant transaction effects, without actually re-executing it during re-synchronization.

Note that all relevant effects need to be recorded to be properly reproduced, so it would be useful to create such log format and play a little bit with it, before it is really needed some day. In my opinion, both TC and CoreDevs should be the ones authorized to push such changes to core repository, without any authorization from Consensus Node operators. On the other hand, disagreement from Consensus Node operators can break the network, as long as they disagree on the Anomaly List. Since the network has no native 50%+1 forking, it's fundamental that all players in the ecossystem agree with such list on practice.

Where in the software does this update applies to?

• Ledger

[vncoelho]

This is a good possibility that is used by other projects, as you mentioned.
As soon as possible we should PRUNE the HFs that does not conflict. But, when necessary, use such list. @vang1ong7ang @dusmart @superboyiii