Fixed `max_stack_height` (no runtime type access)

[Paweł Bylica]

Modify the specification so that functions don't specify their max_stack_height but instead there is a single constant FUNC_STACK_LIMIT defined by the spec. The validation condition is: compute max stack height of a function must be within the limit

assert(max_stack_height(code_section) <= FUNC_STACK_LIMIT)

Pros

1. The max_stack_height of a function is not needed to be stored in the type section. This saves 2 bytes per function (i.e. it shrinks the type section by half).
2. The CALLF/JUMPF implementations don't need to read the callee's max_stack_height from the type section. And combined with #134 all need by the interpreter to access the type section is gone.
3. (weak) EVM assembly is easier for end users (e.g. they don't need to compute max_stack_height of an assembly snippet).

Cons

1. Limits the function recursion. A function cannot call other function (including itself) if the operand stack height reaches 1024 - FUNC_STACK_LIMIT even if in the reality the callee uses much less of the operand stack than FUNC_STACK_LIMIT.

Constant candidates

1. 256: this plays nicely with SWAPN, DUPN limitations and still leaves significant "recursion" stack of 768 operands.

Mitigation for lower limit

I want to have 1024 operands on the stack as in legacy EVM.

For this we can allow code section 0 to have 1024 limit but we also need to forbid calling this section.

Do it later

Instead of the full deployment of the feature we can space for it and reconsider it in a future upgrade. The "space" is to limit max_stack_height to 256 (1 byte).

[Andrei Maiboroda]

Cons.1 - I think it cannot call anything, not only itself?

[Paweł Bylica]

Cons.1 - I think it cannot call anything, not only itself?

Correct. Rephrased.