Voyager verification support

[jkopanski]

Closes #2287

This will submit the contract for verification successfully, but the verification itself will fail as we need to release backend changes for supporting this. Those are in review right now.

Introduced changes

• adds another verifier argument parameter: voyager to verify using Voyager block explorer

Checklist

• Linked relevant issue
• Updated relevant documentation
• Added relevant tests
• Performed self-review of the code
• Added changes to CHANGELOG.md

[franciszekjob]

Shouldn't we mention possibility of setting VOYAGER_API_URL (same for walnut btw)?

[jkopanski]

I was mimicking walnut here, but since both aren't mentioned anywhere right now, perhaps we should name it something like VERIFIER_API_URL for both?

[franciszekjob]

Correct me if I'm wrong, but this will enforce to update the env every time you want to use different verifier? I know it may be a rare case, but theoretically that's how it would look.

[jkopanski]

I'm not sure what you mean here.

I think the users would select verifier using command line arguments. I suspect the env variable was added for easier testing and targeting local verifiers, so it's kind of like a developer mode.

[franciszekjob]

I'm not sure what you mean here.

I mean that if there will be VERIFIER_API_URL (shared between both verifiers), you'll have to change it every time you change verifier.

[jkopanski]

but change verifier in what sense? Users change verifier through command line argument, the env variable is left unset almost all the time.

[franciszekjob]

but change verifier in what sense?

Let's say you use walnut and you've set VERIFIER_API_URL to walnut one. Then you switch to voyager, hence you need to change the env again (because env is shared). I know it may be a rare case. Wdyt?

[jkopanski]

I know it may be a rare case. Wdyt?

Yes it's rare, because (as a sncast user) in order to use walnut you don't set any env variable. You pass --verifier walnut.

The env variable acts as an override so a developer (either walnut, voyager or foundry dev) could target non production instance. IMHO then having single env var makes more sense, but it's not a hill I'm willing to die on ;)

[franciszekjob]

Sure, I'm leaving this up to you 😄

[kkawula]

This will submit the contract for verification successfully, but the verification itself will fail as we need to release backend changes for supporting this. Those are in review right now.

• Can you link this issue/pr?

• Please add entry there - docs/src/appendix/sncast/verify.md

[franciszekjob]

@jkopanski Is it ready to re-review?