`VerifyCmd` flag collision

[erik-3milabs]

In the VerifyCmd interface, the h flag is added as a shorthand for the program hash parameter. However, this flag conflicts with the -h flag shortcut for --help. This was confusing for a second, so I wanted to point this out.

https://github.com/0xPolygonMiden/miden-vm/blob/2d559c32be3ab571d6addebc112af84bc3d26196/miden/src/cli/verify.rs#L19C1-L20C26

[bobbinth]

Thank you for noticing! I think the question is what we should change it to (since -p is used as a shorthand for --proof). Maybe -d for "program digest" or -c for "program commitment". Though I don't love either of these.

[erik-3milabs]

Perhaps -x for hex digest? Not great either, but might be something.

[varun-doshi]

Is this still open?
If so, I'd like to work on this

[plafer]

Yes definitely; go for it!

[varun-doshi]

Thank you
I'll get started on this.

[varun-doshi]

Should we go with -x for program hash?

[bitwalker]

My recommendation would be to require the long option for --hash with no short equivalent.

In general, with command-line interfaces, a couple rules apply IMO:

• Principle of least-surprise - don't use a flag that commonly means one thing to do something else, it'll be confusing, and rarely will benefit users. This means things like -h/--help and -v/--verbose are essentially off-limits for other uses. Conversely, one should prefer to use existing conventions for options that are common across various command-line programs.
• Short flags/aliases should be mnemonic/guessable, or they are useless - if someone can't guess at what the short version of a long flag is, or read a command line snippet someone else wrote and understand what it means, it would be better if it didn't exist.
• Infer reasonable defaults, e.g. miden verify FILE might look for .proof and .hash files with the same base name in the same directory as FILE, rather than requiring explicit arguments for those items.
• Ideally, commands are a balance between having structure and easy to remember, i.e. if you can do something like miden verify FILE PROOF HASH when all three are required, rather than miden verify -i FILE -x HASH -p PROOF_FILE, the former is preferable. Options/flags are supposed to be optional, hence the name, so if you have required inputs, they should take the form of positional arguments, in a natural order, whatever that happens to be.

There are other CLI conventions that I could elaborate on, but IMO these are the ones most applicable here. I don't have a horse in this race, but I'd definitely try to consider changes like this using a higher-level view, rather than focusing on what to do about this specific flag, aside from fixing the immediate issue of conflict with help

[varun-doshi]

Understood
I'll try to make it as robust as possible

[varun-doshi]

@bitwalker
According to point 3 of your comment above:
Infer reasonable defaults, e.g. miden verify FILE might look for .proof and .hash files with the same base name in the same directory as FILE, rather than requiring explicit arguments for those items.

The arguments to the verify command are:

• Input file: .input
• hash- manually inputted(this is not saved in any file, right?) Please correct me if I'm wrong here
• output file: .output
• proof: .proof

Can you confirm what you mean by .hash file?

[bobbinth]

Can you confirm what you mean by .hash file?

Yeah - there is not .hash file, it is just a string that encodes program hash. One thing we are missing in this command though is the ability to specify which kernel the program relies on. Before verifying the program, we need to construct a ProgramInfo struct - and currently, we just assume a default (empty) kernel. So, conceivably, we could have a file which encodes a ProgramInfo struct.

So, technically, the command needs the following:

1. A proof - specified via the .proof file.
2. A program for which we verify the proof. This could be either a simple hash or hash + kernel. The former could probably be specified as a string but the latter may need to be specified as a file (not sure what a good extension could be here).
3. A set of inputs - specified via .inputs file. If not provided, we assume that inputs are all zeros.
4. A set of outputs - specified via .outputs file. If not provided, we assume that outputs are all zeros.

One potential way to restructure the command could be something like:

miden verify PROOF_FILE_PATH -p PROGRAM_HASH -i INPUT_FILE -o OUTPUT_FILE 

And in the future we could also introduce a flag for specifying a "program file" (for hash + kernel combination).

But we could also make an argument that something like this is better:

miden verify PROOF_FILE_PATH PROGRAM_HASH_OR_FILE -i INPUT_FILE -o OUTPUT_FILE 

[varun-doshi]

Sounds good...I'm almost done on the initial issue and most of the points @bitwalker mentioned above. I'll raise a PR soon and we can take it from there.

Also might be good to assign this to me so that no one else accidentally starts working on this issue

[bobbinth]

Also might be good to assign this to me so that no one else accidentally starts working on this issue

Done! Thank you again for taking this on!