Use Sourcify when encoding/decoding governance proposals

[bowd]

Description

The tooling around governance proposals was initially designed under the assumption that Governance interacts only with Celo core contracts, i.e. contracts that are:

• registered in the Registry
• included in ContractKit
• part of the @celo/protocol package.

This assumption was first challenged a few months ago when we needed to deploy Reserve funds to a Mobius pool, and we had to interact with external contracts. The tooling was patched in a pretty hacky fashion (#9735) due to time constraints, but the general idea was that the tooling should have additional ways to retrieve metadata about contracts it interacts with.

As we're moving forward with Mento we're moving away from the monorepo, ContractKit, and the Registry, while still having to interact with Governance for upgrades and future releases. This means that unless there's a more general solution we will hit this problem as well. And the community is also slowing moving away from a ContractKit-centric development mentality and more into broader ecosystem tools.

This PR puts forward a future-proof solution to this problem by leveraging sourcify to lookup contract metadata. Therefore governance will be able to decode/encode transactions to any contracts that are verified on Sourcify.

For example, for the Mobius pool liquidity we had this transaction as part of the cgp.json:

  {
    "contract": "0xFa3df877F98ac5ecd87456a7AcCaa948462412f0",
    "function": "addLiquidity(uint256[],uint256,uint256)",
    "args": [
      [
        "5000000000000000000000000",
        "5000000000000"
      ],
      0,
      1661419596
    ],
    "value": "0"
  }

We made this work at the time in #9735 by:
(1) Allowing addresses for the contract field instead of just Registry names.
(2) Providing a function call signature for the function field instead of just a function name
(3) Having a list of "known functions" so the tooling can turn an on-chain encoded proposal back to human readable.

(3) being a hackiest part of that PR

After this PR we can add this transaction as:

  {
    "contract": "0xFa3df877F98ac5ecd87456a7AcCaa948462412f0",
    "function": "addLiquidity",
    "args": [
      [
        "5000000000000000000000000",
        "5000000000000"
      ],
      0,
      1661419596
    ],
    "value": "0"
  }

The major difference is that we can remove the arguments from the function parameter. And the tooling will output:

0: 
  contract: SwapUSDCet(0xFa3df877F98ac5ecd87456a7AcCaa948462412f0)
  function: addLiquidity
  args: 
    0: 
      0: 5000000000000000000000000
      1: 5000000000000
    1: 0
    2: 1661419596
  params: 
    __length__: 3
    amounts: 
      0: 5000000000000000000000000
      1: 5000000000000
    minToMint: 0 
    deadline: 1661419596 (~1.661e+9)
  value: 0

What happens is that 0xFa3df877F98ac5ecd87456a7AcCaa948462412f0 is a contract that's verified on sourcify so the tooling downloads the metadata.json file from which it can extract the contract name (SwapUSDCet) and the ABI and find the addLiquidity function and encode everything with naming the params and all, without relying on any hardcoded values.

The tooling also has some heuristics to determine if the contract passed in is a proxy and look up the implementation to see if it's verified. This is not very fleshed out but is isolated enough to be easily extensible.

It's important to note that if all @celo/protocol contracts would be verified on sourcify, this PR could be the first step in making the decoding/encoding part of the governance proposal much leaner.

Other changes

N/A

Tested

Added some specs for the sourcify metadata comprehension and tested out locally with different governance json configurations.

Related issues

• Make governance tooling work with arbitrary transactions #9735

Backwards compatibility

All CLI commands and functions intended for public use are backwards compatible. A few functions added recently and intended for internal use but accessible outside have been removed. Given there small surfaces area and unlikelihood of use this is not considered breaking

Documentation

Unsure if this requires documentation changes.

[bowd]

@aaronmgdr @gastonponti if y'all have time I'd super appreciate a review 🙏 tagged y'all 'cose you were involved in #9735

[rkachowski]

It's important to note that if all @celo/protocol contracts would be verified on sourcify, this PR could be the first step in making the decoding/encoding part of the governance proposal much leaner.

This is something that would also be super useful for data services. We rely on sourcify's db to retrieve contract ABIs for decoding transactions.

[aaronmgdr]

looks like most of the breaking changes dont really need to be breaking. the changed method names could be aliased to the new and marked as deprecated as well

[dckesler]

I'm wondering if maybe we could update this PR to avoid the breaking changes. That would mean keeping method names the same and leaving in other methods that were deleted in this PR. It would make a release with these changes much faster and simpler.