Proxy InboxValidatorManager for more efficient deploys

[nambrot]

Abacus core deployments are relatively expensive. One way to easily save gas is to use EIP1667 proxies for the InboxValidatorManager

[asaj]

Also for Inboxes, no?

[nambrot]

I thought you made the point that being able to upgrade implementations is important for Inboxes in a way that is less so for the InboxValidatorManager?

[yorhodes]

Abacus core deployments are relatively expensive. One way to easily save gas is to use EIP1667 proxies for the InboxValidatorManager

I assume you meant EIP1167
IIUC the beacon pattern we are already employing allows us to make upgrades with minimal proxies
ie just swap out the minimal proxy address instead of the implementation address?

[nambrot]

Yes 1167.

Yeah maybe its easier to just use beacon proxy pattern, but the original point was that using 1167 is technically the minimal approach as it preserves the current property that InboxValidatorManagers are not upgradable. It's less of a need since governance can always upgrade via repointing to new InboxValidatorManager contracts on the Inbox, so it seems unnecessary to support upgrading

[yorhodes]

After spending far too much time on this, I realized that _domain and _domainHash are immutable on MultisigValidatorManager. Therefore, "cloning runtime bytecode" with EIP-1167 only works if we move _domain/_domainHash out of bytecode and into storage. However, _domainHash is used by _recoverCheckpointSigner (used in isQuorum), which implies at least one additional SLOAD for InboxValidatorManager.process (in addition to the extra call from proxying).

Posting back of napkin math from chat with @asaj offline
InboxValidatorManager costs 1539485 to deploy
Minimal proxy is at least 41000 (32000 static + 200 * 45 bytes)
savingsPerChain(numberOfRemotes) = 1539485 * numberOfRemotes - (1539485 + 41000 * numberOfRemotes)
Even with 10 chains at current gas prices of 72 gwei on mainnet, this is only 1.37 ETH.

One day I will learn the lesson of premature optimization.