Why Ethereum enables programmable money in Blockchain / Solidity - Performance Analysis
When we look at Ethereum, we want to understand how the time it takes to run programs changes as the program or data grows.
We ask: How does running smart contracts on Ethereum scale with more instructions or users?
Analyze the time complexity of the following Ethereum smart contract function.
contract SimpleWallet {
address owner;
address[] payees;
function addPayee(address _payee) public {
payees.push(_payee);
}
function payAll() public {
for (uint i = 0; i < payees.length; i++) {
payable(payees[i]).transfer(1 ether);
}
}
}
This contract stores a list of payees and sends 1 ether to each payee when payAll is called.
Look for loops or repeated actions in the code.
- Primary operation: The for-loop in
payAll()that sends ether to each payee. - How many times: It runs once for every payee in the
payeeslist.
As the number of payees grows, the number of transfers grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 transfers |
| 100 | 100 transfers |
| 1000 | 1000 transfers |
Pattern observation: The work grows directly with the number of payees. More payees mean more transfers.
Time Complexity: O(n)
This means the time to run payAll() grows linearly with the number of payees.
[X] Wrong: "Sending ether to all payees happens instantly no matter how many payees there are."
[OK] Correct: Each transfer takes time and gas, so more payees mean more work and longer execution.
Understanding how loops affect execution time helps you explain how smart contracts behave as they handle more data, a key skill for blockchain developers.
What if the contract used a mapping instead of an array for payees? How would the time complexity of sending payments change?