search

axelarnetwork / axelar-amplifier

Permissionless Connections Service run on the Axelar Network
21 stars 24 forks source link

Different Naming of Verifier Contract in Different Spots #667

Open benjamin852 opened 1 week ago

benjamin852 commented 1 week ago

Description/Reasoning

Was going through the flow of the docs for instantiating the Gateway and Prover. Both of these require the address of the voting verifier contract to be passed in but we reference these addresses differently in the docs due to how they're referenced in the contracts, which has led to some confusion. Specifically whether a user needs to pass in the address of the verifier contract or an external verifier addresss.

Current Behaviour

In the instructions for instantiating the gateway, devs need to pass in the verifier_address, as the Verifier is referenced as verifier_address in the instantiation msg.

When instantiating the prover we also need to pass in the Verifier contract but for this instantiation the Verifier is referenced as) voting_verifier_address.

This creates a bit of confusion as readers can interpret the verifier_address needed for the gateway instantiation to be an external verifier (especially in devnet where sometimes people only have a single verifier) and the voting_verifier_address prover instantiation to be in reference to the verifier contract.

Expected Behaviour

If it is not a major difficulty to change it would be good to have these two references to the voting verifier contract, consistently named in the two instantiation msgs. We will leave a note in the doc about this so users don't get confused, but cannot update the doc the actual parameter naming in the doc to have voting_verifer_address in both commands as long as they don't match how they're named in the contracts.

cjcobb23 commented 6 days ago

verifier is actually a better name, since there it doesn't necessarily need to be a voting verifier, it could be any type of verifier contract. Maybe we call it verifier_contract?

I can see how this came to be though, because the prover is an evm prover, and we do sort of assume that the verifier contract is a voting verifier in the evm case. But the gateway is totally verifier agnostic, so it makes sense it was just called verifier.

We should not change the name in the gateway to voting verifier.

benjamin852 commented 1 day ago

Makes sense not to use voting_verifier. I think verifier_contract could be the move then. Just so people don't think the verifier is the worker verifier I think verifier_contract will help make that distinction.