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.
This opens up the opportunity to create a nimble application layer firewall. Imagine a single, user, configurable javascript file (bear with me). Each line represents a function that is to be executed against incoming operations in the mempool, and it returns whether to accept the transaction, reject it, mark it as branch delayed, kick the peer, grey list the peer or even black list the peer relaying the transaction. When an operation is about to enter the mempool, it is evaluated against each rule for further inspection.
The rules could also be applied to the receipt of the operation (i.e. the effect it has on the context).
But why?
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.
Ok but why Javascript?
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.
It doesn’t have to be Javascript, it could be any reasonable scripting language (e.g. Python, Lua…), but it should be easy to manually edit and it should not require recompilation and restart of the node.
The problem with Javascript, python etc. is that running interpreters (even as a separate process outside of the node) brings its own set of risks. The problem with trying to cook up some custom scripting language with a minimal interpreter is that writing filtering rules would be a pain in the ass.
