You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Description/Reasoning
Was going through the flow of the docs for instantiating the
Gateway
andProver
. 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 asverifier_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 thevoting_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.The text was updated successfully, but these errors were encountered: