Multisig upgrade support

[hiddentao]

Multisig upgrade support should be added to enable protected upgrades.

A possible proposal:

• Built-in n-of-m multisig system in the Diamond (replaces the Ownership facet).
• Initially it's a 1-of-1, so it works the same as current Diamond deployments.
• Allow for batch consensus (i.e. signers have created off-chain signatures which then get sent in together).
• Permission logic should be pluggable, e.g if you want certain signers to always be a signatory

Alternative proposal:

• Use existing solutions such as Gnosis Safe as the owners of the diamond and build tooling that integrates with them.

[hiddentao]

Current architectural thoughts:

• Each target specifies a safeOwner which points to an existing SAFE multisig wallet
• Gemforge will check for its existence and ensure it's a real SAFE.
• Gemforge will then set this SAFE as the owner once initial deployment of the Diamond is complete.
• Gemforge will then deploy an Upgrades contract on chain using a pre-signed transaction (like the CREATE3 factory) and add the deployed Diamond address to it as one of the Diamonds to manage.
  • The Upgrades contract will holds interim upgrade data to be signed by all SAFE participants and also does the actual upgrade when the time comes.
• Gemforge will bundle a locally running WebUI (called "Gemsafe") through which SAFE signers can view and sign the pending upgrade for the Diamond and sign it.
  • They will also be able to see historical upgrades for the Diamond
• Once enough SAFE signers have signed, a transaction is sent to the SAFE which internally calls the Upgrades contract, which internally calls diamondCut() on the Diamond.
• This way there is a record of every upgrade stored in the Upgrades contract. And SAFE signers will be able to see all historical upgrade transactions within SAFE's own WebUI.

[hiddentao]

New proposed idea based on feedback from @kevin-fruitful @amarinkovic @tgeorgas. This proposal removes the need for a separate Upgrades contract, a new signing UI, and caters for all types of multisig wallets.

• Each target specifies a safeOwner value which should be a wallet address that is ideally a multisig, though this is not enforced.
• Gemforge will then set this safeOwner as the actual owner once initial deployment of the Diamond is complete.
• Gemforge will also deploy an additional Upgrades facet which overwrites the default diamondCut() method with a new one that will store the arguments as the latest pending upgrade. This method can be called by any wallet, not just the owner.
• For an upgrade to now be finalized the safeOwner will need to send a tiny amount of ETH to the diamond after Gemforge has called diamondCut(). This amount is calculated by the Upgrades facet based on the upgrade data, enabling the approval transfer to be uniquely matched to a given upgrade.

Risk:

• Someone uses a DoS attack to prevent the final upgrade approval
  Mitigation:
• Don't allow any wallet to call diamondCut(). Have a whitelist of wallets that are allowed to call diamondCut() - whitelist is maintained by the owner.

[hiddentao]

The solidity receive() method has a fixed gas stipend of 2300 so it won't be enough for doing an upgrade. Thus, we will have to make the safeOwner call a method on the contract.

[hiddentao]

Preliminary solution in #50.

It's simple but effective - outputs the raw tx data which you can copy-paste into Gnosis SAFE