Upgradeable Proxy Contracts

仕組み

A proxy holds the assets and the storage while delegating execution to a separate implementation contract whose address can be changed by whoever holds the upgrade right. This pattern is genuinely useful, since it allows a bug to be fixed without migrating users, but it means the code a depositor reviewed is a snapshot rather than a commitment. Two additional exposures follow. Storage layout must remain compatible across upgrades, and a mistake there can corrupt balances rather than merely change behavior. And the implementation is itself a dependency that can be removed, so the proxy pattern makes the contract's future contingent on both the upgrade key and the continued existence of the code it points to.

実際に観測できるもの

Check whether the address is a proxy by reading the standard implementation and admin storage slots, then identify who holds the upgrade right and whether upgrades pass a timelock. Count how many times the implementation has changed and compare the currently deployed implementation against the specific commit that was audited. Where a timelock exists, its queue of pending changes is public and can be monitored.

先例

In 2017 a shared library that many Parity multisig wallets delegated to was self-destructed, freezing the balances of every wallet that depended on it and demonstrating that the code behind a proxy is a live dependency.

重要性を左右する要因

Consider whether the contract is upgradeable at all, who holds that right, whether a timelock and an exit window exist, how frequently the implementation has changed, and whether the current code matches an audited version.