Proxy pattern (upgradeable contracts) in Blockchain / Solidity - Time & Space Complexity
When using the proxy pattern in blockchain, we want to know how the cost of calling functions changes as the contract grows.
We ask: How does the number of steps grow when the proxy forwards calls to the logic contract?
Analyze the time complexity of the following proxy contract code snippet.
contract Proxy {
address implementation;
fallback() external payable {
(bool success, ) = implementation.delegatecall(msg.data);
require(success);
}
}
This code forwards any call to the current implementation contract using delegatecall.
Look for repeated actions that affect time cost.
- Primary operation: The delegatecall forwards the call data to the implementation contract.
- How many times: Once per external call to the proxy.
The proxy adds a small fixed overhead for forwarding calls, regardless of the size of the implementation contract.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | ~10 + small fixed overhead |
| 100 | ~100 + small fixed overhead |
| 1000 | ~1000 + small fixed overhead |
Pattern observation: The cost grows roughly in direct proportion to the size of the called function's work, with a small constant added by the proxy.
Time Complexity: O(n)
This means the time to complete a call grows linearly with the work done in the implementation contract, plus a small fixed cost from the proxy.
[X] Wrong: "The proxy adds a big extra cost that grows with the implementation contract size."
[OK] Correct: The proxy only forwards calls once per call, so its overhead is constant, not growing with the implementation contract size.
Understanding how proxy contracts affect execution cost helps you explain upgradeable contract design clearly and confidently.
"What if the proxy added multiple delegatecalls in a single fallback? How would the time complexity change?"