Increase deploy limits by 8x

[vicsn]

Motivation

Developers on Aleo are having trouble with the current deployment constraint and variable limits. These limits were put in place to ensure even if an attacker found an avenue to cheaply spam the network with deployments, they would not be able to increase blocktime by too much. However, they need to be increased to allow for a more expressive AleoVM, several developers noted that they are hitting the limits.

Instead of the current transaction-level limits, or proposal-level limits (like we did for finalize spend), this PR proposes a much higher block-level limit.

The main downside of this approach is that it hurts predictability. A deployment might be aborted last-minute because another user deployed at the same time. Note however:

• whereas the Aleo network processes many executions, there are only a few hundred programs deployed on mainnet. Simultaneous deployment is unlikely.
• a deployment's "end user" is always a developer, from whom we can expect more expertise. leo deploy can already check whether a deployment was accepted - we can also let it check whether a competing deployment was accepted recently.

A nice side-effect of this PR is that it makes DoS attacks with many deployments harder.

A large downside is that encouraging this will increase prover time.

Appendix: how the original limit was set

Deployment verification consists of a mix of single-threaded logic (R1CS synthesis) and multi-threaded logic (polynomial interpolation and evaluation). The original price of 25 microcredits per constraint focused on just the single-threaded runtime - allowing us to be in line with the 10 credits/second across our finalize opcodes. We don't have immediately reproducible benchmarks available unfortunately, this PR does not aim to touch that "constraints per second" metric.

Test Plan

• After the design is approved, I'll add unit tests which deploy below and above the limit.

[vicsn]

Converted to draft because developers in question may need to be encouraged to use more efficient hash functions and finalize scope operations