When a contract uses a `delegatecall` to another contract, what big thing about whose storage is used changes compared to a normal `call`?

When a contract uses a `delegatecall` to another contract, the big thing that changes regarding whose storage is used is that the `delegatecall` executes the code of the target contract using the storage of the *calling contract*, whereas a normal `call` executes the code of the target contract using the storage of the *target contract*.

To explain, a `contract` is a program on the blockchain that manages its own `storage`, which holds its persistent data like state variables. When a `calling contract` makes a normal `call` to a `target contract`, it initiates an execution of the `target contract`'s code. During this execution, any operations that read from or write to `storage` will interact with the `target contract`'s own storage. The execution happens within the `target contract`'s `context`, meaning its own storage, `msg.sender` (the address of the immediate caller), and `msg.value` (any ether sent) are used.

In contrast, when a `calling contract` performs a `delegatecall` to a `target contract`, it still executes the `target contract`'s code. However, this execution occurs within the `context` of the *calling contract*. This means that all `storage` operations performed by the `target contract`'s code will read from and write to the `storage` of the *calling contract*. Additionally, the `msg.sender` and `msg.value` inside the delegated call remain those of the original transaction that interacted with the *calling contract*. For instance, if Contract A `delegatecall`s Contract B, and Contract B's code changes a state variable named `owner`, it will modify the `owner` variable stored within Contract A's storage, not Contract B's. This fundamental difference enables patterns like upgradeable contracts, where a proxy contract maintains state while delegating logic execution to an implementation contract.