Redefine zkapp benchmark ledger generation for better constitution coverage

[cjjdespres]

Explain your changes:

The data generation procedure for the --zkapps component of the transaction-snark-profiler has been reworked. That procedure will now create exactly one zkApp transaction for every possible "constitution" that a transaction can have. The benchmark will then run using that sequence of transactions and their associated ledger. The old method created a sequence with incomplete coverage of the possible constitutions. The precise coverage provided by the new method will hopefully make this benchmark more meaningful and more reliable.

Explain how you tested your changes:

I added asserts in the benchmark code to ensure that for each of the enumerated constitutions, the transaction created for that constitution does in fact have that constitution. I ran the benchmark locally and found that 63 distinct constitutions/transactions were created - I believe these are all of the valid constitutions. For the record, these constitutions are as follows (with the given number of proof updates, paired payment-like updates, and single payment-like updates).

{proof: 0; pair: 1; single: 0}
{proof: 0; pair: 2; single: 0}
{proof: 0; pair: 3; single: 0}
{proof: 0; pair: 4; single: 0}
{proof: 0; pair: 5; single: 0}
{proof: 0; pair: 6; single: 0}
{proof: 0; pair: 0; single: 1}
{proof: 0; pair: 1; single: 1}
{proof: 0; pair: 2; single: 1}
{proof: 0; pair: 3; single: 1}
{proof: 0; pair: 4; single: 1}
{proof: 0; pair: 5; single: 1}
{proof: 1; pair: 1; single: 0}
{proof: 1; pair: 2; single: 0}
{proof: 1; pair: 3; single: 0}
{proof: 1; pair: 4; single: 0}
{proof: 1; pair: 5; single: 0}
{proof: 1; pair: 0; single: 1}
{proof: 1; pair: 1; single: 1}
{proof: 1; pair: 2; single: 1}
{proof: 1; pair: 3; single: 1}
{proof: 1; pair: 4; single: 1}
{proof: 1; pair: 0; single: 2}
{proof: 1; pair: 1; single: 2}
{proof: 1; pair: 2; single: 2}
{proof: 1; pair: 3; single: 2}
{proof: 1; pair: 4; single: 2}
{proof: 2; pair: 1; single: 0}
{proof: 2; pair: 2; single: 0}
{proof: 2; pair: 3; single: 0}
{proof: 2; pair: 4; single: 0}
{proof: 2; pair: 0; single: 1}
{proof: 2; pair: 1; single: 1}
{proof: 2; pair: 2; single: 1}
{proof: 2; pair: 3; single: 1}
{proof: 2; pair: 0; single: 2}
{proof: 2; pair: 1; single: 2}
{proof: 2; pair: 2; single: 2}
{proof: 2; pair: 3; single: 2}
{proof: 2; pair: 0; single: 3}
{proof: 2; pair: 1; single: 3}
{proof: 2; pair: 2; single: 3}
{proof: 3; pair: 1; single: 0}
{proof: 3; pair: 2; single: 0}
{proof: 3; pair: 3; single: 0}
{proof: 3; pair: 0; single: 1}
{proof: 3; pair: 1; single: 1}
{proof: 3; pair: 2; single: 1}
{proof: 3; pair: 0; single: 2}
{proof: 3; pair: 1; single: 2}
{proof: 3; pair: 2; single: 2}
{proof: 3; pair: 0; single: 3}
{proof: 3; pair: 1; single: 3}
{proof: 3; pair: 0; single: 4}
{proof: 4; pair: 1; single: 0}
{proof: 4; pair: 2; single: 0}
{proof: 4; pair: 0; single: 1}
{proof: 4; pair: 1; single: 1}
{proof: 4; pair: 0; single: 2}
{proof: 4; pair: 1; single: 2}
{proof: 4; pair: 0; single: 3}
{proof: 5; pair: 1; single: 0}
{proof: 5; pair: 0; single: 1}

Checklist:

• [x] Dependency versions are unchanged
• [ ] Modified the current draft of release notes with details on what is completed or incomplete within this project
• [x] Document code purpose, how to use it
• [ ] Tests were added for the new behavior
  • Document test purpose, significance of failures
  • Test names should reflect their purpose
• [ ] All tests pass (CI will check this if you didn't)
• [ ] Serialized types are in stable-versioned modules
• [x] Does this close issues? (It does not).

[cjjdespres]

Force-pushed to improve the documentation comments and simplify the update rearrangement slightly.

[cjjdespres]

This might want to be in a separate issue/PR, but I get 103 different constitutions if I run the zkapp_limits.exe executable. One of the ones in that output and not here, for example, is {proof: 0; pair: 0; single: 0}. The extra 40 constitutions in that output cannot occur in a valid Zkapp_command, assuming my understanding of zkApp transactions is correct. The comments in zkapp_limits.ml should probably be updated to reflect this fact, or the output of zkapp_limits.exe should be refined.

[cjjdespres]

!ci-build-me

[cjjdespres]

Perhaps I don't have that power

[glyh]

!ci-build-me

[glyh]

@cjjdespres did you mark your membership of the organizations MinaProtocol& o1Labs as public?

[glyh]

!ci-build-me

[glyh]

Note for myself

• This is the project spec: Rewrite snark profiler benchmark

[glyh]

{proof: 0; pair: 0; single: 0}

What's the point of {proof: 0; pair: 0; single: 0}? Isn't that an noop command? But I get it might be useful for full coverage.

[glyh]

For your list of possible combinations:

{proof: 0; pair: 1; single: 0}
...

Doesn't seemed to on par with what George have in this snippet. Specifically, the range of param proof in yours is 0 to 5, but for George's its 1 to 6. Any ideas why?

[cjjdespres]

{proof: 0; pair: 0; single: 0}

What's the point of {proof: 0; pair: 0; single: 0}? Isn't that an noop command? But I get it might be useful for full coverage.

That's a combination that was output by zkapp_limits.exe, but isn't in the constitutions I enumerate here. I'm pretty sure that such a constitution is impossible to have in a Zkapp_command - there always seems to be an implicit fee payer update in a command, and that means either pair > 0 or single > 0. If it were possible, it would be like an extreme no-op that doesn't even have a fee payer update in it.

For your list of possible combinations:

{proof: 0; pair: 1; single: 0}
...

Doesn't seemed to on par with what George have in this snippet. Specifically, the range of param proof in yours is 0 to 5, but for George's its 1 to 6. Any ideas why?

I'm not sure either. I'll ask @georgeee again. The constitutions I enumerate match the output of zkapp_limits.exe when I run it (aside from the constitutions that zkapp_limits.exe lists that I think are impossible). As you noticed, neither of those match what's in the gist too well.

[cjjdespres]

Pushed just to base this on a more recent compatible - for some reason this wasn't compiling without doing that, but is now. I think the structure of the kimchi bindings might have changed somehow?

[cjjdespres]

Added a commit to address review comments. Updated the base again while I was at it.

[cjjdespres]

Force-pushed to address the latest merge conflicts, and added a commit to address https://github.com/MinaProtocol/mina/pull/16862#discussion_r2057266439

[cjjdespres]

!ci-build-me

[cjjdespres]

Pushed to fix some merge conflicts.

[glyh]

I just realized there's Mina_generators, we should move command generation logics inside that library so other applications might use it.

Potential use case: In mock coordinator test, we're using dumped spec from devnet nodes, we could've use generated commands instead.

Of course we could done a round of audit checking the quality of generated commands.