[HackerOne-2354265] Restrict number of imports, program depth, and call depth.

[d0cd]

This PR,

• introduces a limit for the number of imports in a program.
• checks that each function in a program makes at most MAX_TRANSITIONS - 1 calls.
• introduces an upper bound in import depth
• caches get_number_of_function_calls.

[howardwu]

Can you provide some context on why these depths and imports are where they're at?

Based on our design, I believe we're constraining other parameters already at the 32 mark. It would make sense to constraint both of these parameters alongside the 32 mark.

[d0cd]

The MAX_PROGRAM_DEPTH was decided based off of Ethereum's MAX_CALL_DEPTH.
I went with this as a healthy upper bound. I see no issue with restricting MAX_PROGRAM_DEPTH to 32.

MAX_IMPORTS should be larger because a user may want to create a program that reads the mappings of a large number of other programs.

[d0cd]

Ah actually, suppose that program1 reads program2 reads ... reads program32
If we program0 to reads program1, then we need a greater MAX_PROGRAM_DEPTH.

[howardwu]

Discussed offline, waiting for a change to 64 and 64

[randomsleep]

One question less related this issue: Would it be better to set a larger 'TRANSACTION_DEPTH', (e.g. 8)? This will make it easier to increase 'MAX_TRANSITION' in the future. We can still keep 'MAX_TRANSITION' as 32 for now.

[howardwu]

One question less related this issue: Would it be better to set a larger 'TRANSACTION_DEPTH', (e.g. 8)? This will make it easier to increase 'MAX_TRANSITION' in the future. We can still keep 'MAX_TRANSITION' as 32 for now.

This has problems because it will change the Merklization to be much slower, and require a larger inclusion circuit for proving. Ultimately, these impact runtime for transaction generation.