[PROTO-OPS] GDA verification of SuperfluidPool instances

[d10r]

Problem

For SuperfluidPool instances, the beacon proxy pattern is used.

How instances are deployed: https://github.com/superfluid-finance/protocol-monorepo/blob/gda/packages/ethereum-contracts/contracts/agreements/gdav1/SuperfluidPoolDeployerLibrary.sol#L23

Example deployment tx: https://testnet.snowtrace.io/tx/0xb81b312ace4f70d22f8c24ac0e8eeb07dd2e1f5a95452be06a2e8cf7a4cb87a6

truffle-plugin-verify can't auto-determine constructor params if deployed like this (from contract), but can be manually told what the params are thx to this PR.

How I abi encoded the params in a truffle console:

token="0x24f3631dbbf6880C684c5e59578C21194e285Baf"
admin="0xB726d37B47C694F46104dca14FCfBb20fb5eF53e"
transferrable = true
distributeFromAny = true

truffle(avalanche-fuji)> pool.initialize.request(admin, token, transferrable, distributeFromAny)
{
  from: '0xd15D5d0f5b1b56A4daEF75CfE108Cb825E97d015',
  to: '0xf237a68c7239ea1A4306bA3b5Ebd4f8A3925a6d8',
  data: '0x89287e0a000000000000000000000000b726d37b47c694f46104dca14fcfbb20fb5ef53e00000000000000000000000024f3631dbbf6880c684c5e59578c21194e285baf00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001'
}

for the first param (beacon), it's just padding to 32 bytes.

Resulting cmdline:

npx truffle run --network avalanche-fuji verify BeaconProxy@0xf237a68c7239ea1A4306bA3b5Ebd4f8A3925a6d8 --forceConstructorArgs string:0000000000000000000000003073dd4a041b77f547b649a1ba3947355c34682c:89287e0a000000000000000000000000b726d37b47c694f46104dca14fcfbb20fb5ef53e00000000000000000000000024f3631dbbf6880c684c5e59578c21194e285baf00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001

not yet sure if this is the correct way to provide multiple args.

Acceptance criteria

A sufficiently automated solution for getting new SuperfluidPool instances verified - that is, shouldn't be more complicated than invoking a script and providing the address of the pool contract to be verified.
The solution space isn't limited to truffle-plugin-verify. On the contrary, due to truffle deprecation it may be better to use other tooling for this.

[hellwolf]

@d10r is it still broken?

[d10r]

to my surprise there finally are verified beacon proxies, see https://celoscan.io/address/0x882703DC8239e2Ba167e06CE1FcF654E17A0bd06#code
Also the one linked above (snowtrace) is now verified.

Will check next networks and close if confirmed.

[hellwolf]

I assume it is fixed.

[d10r]

to my surprise there finally are verified beacon proxies, see https://celoscan.io/address/0x882703DC8239e2Ba167e06CE1FcF654E17A0bd06#code
Also the one linked above (snowtrace) is now verified.

This was a red herring, bcs the pattern and terminology keeps confusing me. What was verified was the Beacon, not the Proxy.

snowtrace adds to the confusion because it's behaviour with proxies is different from etherscan-instances.
It sometimes renders the implementation code instead of the proxy code for the proxy contract, for example: https://testnet.snowtrace.io/address/0x524E1C366cf35A566bCD4d6A8285b1AcE6BA9752/contract/43113/code?chainId=43113

This is what a (verified) BeaconProxy looks like on an etherscan-ish explorer: https://basescan.org/address/0x76e2ca149945Bb8c6130619Ad4ddFa30EcF9bE06#code

A solution for this issue is in #1942

[d10r]

The solution above solves the problem going forward.
In order to retroactively verify existing SuperfluidPool instances, this works:

First, check out the code version deployed when the Pool contract was created, and compile it.
Then, in a truffle console, execute:

# create dummy pool on Base (token addr is network specific):
# get the address of a SuperToken (any) on the chain
token = "..."
# deploy a dummy pool (using a non-existent admin)
admin = "0x0000000000000000000000000000000000000001"
gdaFwd = await GDAv1Forwarder.at("0x6DA13Bde224A05a288748d857b9e7DDEffd1dE08")
gdaFwd.createPool(token, admin, [false, false])

# now calculate the constructor args
# selector of SuperfluidPool.initialize
initializeSelector = "0x89287e0a"
initCalldata = web3.eth.abi.encodeParameters(['address', 'address', 'bool', 'bool'], [admin, token, false, false])
data = initializeSelector + initCalldata.slice(2)
ctorArgs = web3.eth.abi.encodeParameters(['address', 'bytes'], [beacon, data]).slice(2)

Now look up the address of the created contract by pasting the tx hash in an explorer and looking at the log events.
Then run the verification command:

npx truffle run --network <network> verify BeaconProxy@<poolAddr> --forceConstructorArgs string:<ctorArgs>

(ctorArgs needs to be WITHOUT leading 0x)

If it fails, you can debug by looking up the input data of the deployment tx in Tenderly and compare with what was computed. Example: https://dashboard.tenderly.co/tx/base/0x4545ef55cc4b2b50ed3f3cb092292794a3db17df41a255dca23bad1bb115b5e5/debugger?trace=0.0.0.1.0.1.0
([INPUT] contains the contract code concatenated with the encoded constructor args, so you have to visually parse from the end and figure out where that boundary is)