Proxy handling working well only for initial deployment, not for update case

TL;DR: The way proxy verification is now handled makes the assumption that the user has matching bytecode for both the proxy and the implementation contract in the current project directory. While that works fine for verifying a fresh deployment, it easily breaks down in the update case. That's because the local bytecode of the proxy contracts tends to change over time, e.g. due to compiler updates, while the on-chain bytecode will always remain the one originally deployed.

More detail: I just had this issue when trying to verify Superfluid framework contracts v1 on gnosisscan.io (thx for quickly adding support!) with v0.5.28. The proxy contracts are based on 2021 versions, built with Solidity v0.7.6. I tried to manually patch a local directory by copying over the build and contracts dir from an old version. Also had to patch the node_modules folder with a matching (older) version of the openzeppelin module. Even then,

npx truffle run --network xdai-mainnet verify SuperfluidGovernanceIIProxy@0xaCc7380323681fdb8a0B9F2FE7d69dDFf0664478 --debug

would fail:

DEBUG logging is turned ON
Running truffle-plugin-verify v0.5.28
Retrieving network's network ID & chain ID
Verifying SuperfluidGovernanceIIProxy@0xaCc7380323681fdb8a0B9F2FE7d69dDFf0664478
Reading artifact file at /home/didi/src/sf/protocol-monorepo/packages/ethereum-contracts/build/contracts/SuperfluidGovernanceIIProxy.json
Custom address 0xaCc7380323681fdb8a0B9F2FE7d69dDFf0664478 specified
Reading artifact file at /home/didi/src/sf/protocol-monorepo/packages/ethereum-contracts/build/contracts/SuperfluidGovernanceIIProxy.json
Verifying proxy implementation SuperfluidGovernanceIIProxy at 0x882703dc8239e2ba167e06ce1fcf654e17a0bd06
Retrieving constructor parameters...
...
Sending verify request with POST arguments:
{
  "apikey": "RD3CJ381PFPFG8SNWJ26D1ZCIA9R5MU2PJ",
  "module": "contract",
  "action": "verifysourcecode",
  "contractaddress": "0x882703dc8239e2ba167e06ce1fcf654e17a0bd06",
...
  "codeformat": "solidity-standard-json-input",
  "contractname": "/contracts/gov/SuperfluidGovernanceII.sol:SuperfluidGovernanceIIProxy",
  "compilerversion": "v0.7.6+commit.7338295f",
...
}
Invalid constructor arguments provided. Please verify that they are in ABI-encoded format
Failed to verify 1 contract(s): SuperfluidGovernanceIIProxy@0xaCc7380323681fdb8a0B9F2FE7d69dDFf0664478

It seems to me that this is failing because it's trying to be smart and verify the implementation contract. I can however not provide it with valid proxy and implementation artifacts in 1 run with reasonable effort.

Thus here I ended up writing the output of such a run with --debug flag set to a file, manually converting that to a valid std-json-input and manually uploading that via the explorer UI. That worked (see verified contract), but this process is pretty tedious.

Previous versions of the plugin had the option to be more explicit about what should be done: verify a proxy or its implementation, or both.

After this experience it seems to me that this is still needed, the ability to specify a custom proxy implementation alone isn't enough to cover such "update use cases".

This should be possible:

Verify a proxy contract, ignoring the implementation (no failure even if no bytecode for the implementation locally available)
Verify an implementation contract, ignoring the proxy (no failure even if no bytecode for the proxy locally available). Ideally in this case the plugin recognizes that there's a proxy and still does the linking, especially if the proxy is already verified.

rkalis / truffle-plugin-verify

Proxy handling working well only for initial deployment, not for update case #178