Introduce deployment variable limit and cost

[vicsn]

Motivation

Even though we limit program size and number of constraints, @d0cd identified that it is possible for someone to create huge constants in programs. During deployment verification, an attacker can make a validator take forever or use a lot of memory, without paying for it, because we don't limit or price constants.

The solution is to limit constants similarly to how we limit the number of constraints.

Some design considerations:

• I'm limiting total number of variables, not just constants, as defense in depth. Our lack of variable limitation was nagging me anyway. Speed to synthesize is the same for constants v.s. variables (for their respective worst case opcode keccak v.s. psd)
• I'm pricing in variables at the same rate as constraints, to avoid DoS from small programs with lots of constants.
• credits.aleo uses ~150k variables, the biggest popular program 300k variables, so (1 << 20) should be a sufficient limit
• verification of a deployment with max constants of (1 << 20) takes ~2 seconds in debug mode, so likely 0.02-0.2 second in release).
• we cannot add num_constants to CircuitInfo, constants are not a known quantity at the Varuna level. That's why I added the value to the Deployment object. Given that we price deployments by their size, the cost for deployments is increased by 0.01 aleo credit per function. Technically, we could only track the constants and not the total number of variables in the deployment, but I fear its less understandable for outside developers.

Test Plan

Adding two tests, one testing the variable limit, and one testing manipulation of reported variables.

Related PRs

Similar to: https://github.com/AleoHQ/snarkVM/pull/2271

[howardwu]

You'll need to reflect TestnetCircuit changes and TestnetV0 changes now as well.

[vicsn]

Good questions.

It's said that 300k should be sufficient but what's the basis of that assumption of sufficiency?

The limit is 1M, same as the constraint limit, because synthesizing variables and constraints for our existing gadgets go hand in hand. If you grep in snarkVM for Count:: you'll see all of our existing gadgets allocate roughly the same amount of variables as constraints (actually a bit less variables, because multiple constraints typically link the same variable). Compared to before, the only usage which this design limits is someone trying to generate large constants.

My main concern with this is that how the circuit creates variables under the hood is effectively opaque to most users (minus those who are familiar with the circuits) and will create a bad UX as users pull out their hair trying to find out why their deployments are failing.

This was also the case for the constraint limit. If you have alternative design ideas let me know.

I agree we should report the reason of failure: https://github.com/AleoHQ/snarkOS/issues/2962

[howardwu]

The design should have variable count in the verifying key. It is error prone to have it defined as an accessory, like in this PR.

AFAIK, the insert_variable_count is NOT called everywhere insert_verifying_key is called.

It would be helpful to know why this design was chosen, and whether it was validated on a snarkOS devnet.

[vicsn]

It would be helpful to know why this design was chosen, and whether it was validated on a snarkOS devnet.

I did consider it. From this PR's README: "we cannot add num_constants to CircuitInfo, constants are not a known quantity at the Varuna level. That's why I added the value to the Deployment object." Adding more context:

• The CircuitVerifyingKey is from the algorithms crate, so it is also semantically not clean to add constants in there which are not relevant in that crate. I.e. we'd have to set them to 0 or None for any tests local to the Varuna crate.
• Another option is the VerifyingKey in the synthesizer crate. I didn't want to mess with that abstraction either, as it is used as a thin wrapper.

But go wild if you want to do it anyway.

whether it was validated on a snarkOS devnet.

Not yet, otherwise I would/should have mentioned in the PR README or one of the comments.

AFAIK, the insert_variable_count is NOT called everywhere insert_verifying_key is called.

I see, that looks like a potential issue. A simpler way around could be to unify just those 2 functions

[howardwu]

Thanks for the insight. We're currently discussing using https://github.com/AleoHQ/snarkVM/pull/2444 as the replacement PR.

[howardwu]

Closing in favor of #2444