What is the Proxy pattern in Solidity for upgradeable contracts?

Smart contracts are immutable by default — once deployed, their code cannot change. The Proxy pattern enables upgradeable contracts through two-contract architecture: (1) Proxy contract — holds the state (storage) and ETH. Users interact with this address. All calls are forwarded to the implementation using delegatecall — execution happens in the proxy's storage context; (2) Implementation contract (logic) — contains the actual business logic. Can be replaced (upgraded) by pointing the proxy to a new implementation address. delegatecall runs the implementation's code but reads/writes the proxy's storage. Storage layout must be compatible across upgrades — adding variables is safe; changing order or removing variables causes collisions. Proxy patterns: (1) Transparent Proxy (EIP-1967) — admin calls are handled by proxy; user calls are delegated. OpenZeppelin's TransparentUpgradeableProxy; (2) UUPS (EIP-1822) — upgrade logic is in the implementation contract itself, reducing proxy complexity and gas; (3) Diamond/EIP-2535 — proxy that delegates to multiple implementation "facets" based on function selector; enables unlimited contract size. Security concern: upgradeable contracts reintroduce centralized trust — the upgrade key holder can change the logic arbitrarily. Time-locks and multi-sigs on upgrade keys mitigate this.