feat(protocol): put automata dcap v3 ra behind proxy

[adaki2004]

As per request. #16864 (comment)

[dantaik]

and who is the owner to perform upgrade? The idea was deploy non-upgradable contract to use address manager to switch to a new verifier if needed.

[adaki2004]

and who is the owner to perform upgrade? The idea was deploy non-upgradable contract to use address manager to switch to a new verifier if needed.

Owner to upgrade i guess is the proxy owner.
But good question, i let it be answered by John, dont know who shall maintain this.

[openzeppelin-code]

feat(protocol): put automata dcap v3 ra behind proxy

Generated at commit: be80e1d0de7d4f0738224cefedc67c5c8137ab80

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 5 41 50
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[dantaik]

If this contract is stateless, then maybe we just deploy a new version.

[adaki2004]

If this contract is stateless, then maybe we just deploy a new version.

In our current design:
A: deploy a new and upgrade the lookup in AddressManager
or
B: upgrade

both can work. I have no strong opinion, maybe B is more handy and easier (?). Please you decide.

[dantaik]

@johntaiko @smtmfft

The reason I think we should keep this contract not upgradeable is to ensure we can sync with the official repo's code easily, otherwise, the official repo is not upgradeable and ours is, then we always have to manually copy code and make necessary changes to our copy to ensure it works.

[dantaik]

@johntaiko @smtmfft

The reason I think we should keep this contract not upgradeable is to ensure we can sync with the official repo's code easily, otherwise, the official repo is not upgradeable and ours is, then we always have to manually copy code and make necessary changes to our copy to ensure it works.

Given that this verifier has state data, I'm OK with upgradeability