Despite using a stack-safe monad in the interpreter, we weren't suspending computations often enough and observed stack overflow errors while processing large amounts of Rholang. Since this is a generic issue that could hit us in many different scenarios in different parts of the interpreter, we started work to harden the interpreter.
This is a follow-up and a generalization of RHOL-652, where a deeply nested AST caused a StackOverflowError during normalization.
Similar errors can most likely be found by causing any other deeply nested data structure to be processed, e.g.
This affects the normalizer, but most likely also the reducer, spatial matcher, and pretty match every recursive function we use for the interpreter.
We need an approach for proofing against this type of bugs, as they are a potential DOS attack vector.