I’ve been floating this idea around for a couple of years, but I don’t think I gave it a write-up, so here it is for the record.
An application-level firewall for nodes
The Tezos shell is agnostic to the content of operations, but the protocol does export so-called “transaction quality metrics” which essentially boil down to things like fees paid, gas limits, etc. so that the mempool can discern which transactions it would like to keep or not. This is currently used to require a set minimum amount of fees as a function of gas and space, based on a node’s user configuration.
In addition to these metrics, the protocol actually exports an entire JSON representation of the transaction.
The rules could also be applied to the receipt of the operation (i.e. the effect it has on the context).
In a perfect world, if there are never any bugs ever, firewalls are unnecessary. In the real world, it’s better to have one and not need it than to need one and not have it
Large classes of potential bugs that can be quickly patched using these kinds of filtering rules, but there are two important caveats:
Not all potential bugs can be caught by simple filtering/pattern matching on an operation. The operation could be a call to a smart-contract which itself sends a bug triggering operation for example. But some might… imagine a bug in making an operation to a malformed address for example, or greater than a certain size, or embedding some problem causing unicode characters. None of these examples correspond to any known bugs, but they are sufficiently plausible, as a category, to justify the benefits of a firewall.
Filtering on operation receipts rather than on operations is much more powerful but it comes with the risk of DDOS. This is what happened after The DAO hack, when Ethereum devs tried to introduce a soft-fork that would reject transactions touching the DAO state. Nonetheless, good peer blacklisting can potentially mitigate this side effect, and it’s always good to have the option to convert an attack on safety to an attack on liveness anyway. Filtering on receipts is a powerful double-edged sword: you’d rather have it than not have it but think before using it.
In principle, such rules could be added to the shell software and distributed as a release but this is a slow and heavy process. Adding a one-liner in a config file is much easier and can spread much faster. Curated lists can be maintained, bakers can be automatically notified when new filters are being proposed.