Bird
Raised Fist0
Blockchain / Solidityprogramming~5 mins

Payable functions in Blockchain / Solidity - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Payable functions
O(1)
Understanding Time Complexity

When we use payable functions in blockchain, we want to know how the cost of running them changes as more data or users interact with them.

We ask: How does the time to process payments grow when the function is called many times?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.


contract SimpleWallet {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }
}
    

This code lets users send money to the contract and keeps track of each user's balance.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Updating the balance for the sender in a mapping.
  • How many times: Once per function call, no loops or recursion inside.
How Execution Grows With Input

The function does a simple update each time it is called, no matter how many users or deposits happened before.

Input Size (n)Approx. Operations
1010 simple updates
100100 simple updates
10001000 simple updates

Pattern observation: Each call takes about the same time, so total work grows linearly with calls.

Final Time Complexity

Time Complexity: O(1)

This means each call to the payable function takes the same small amount of time, no matter how many deposits happened before.

Common Mistake

[X] Wrong: "Payable functions get slower as more users deposit money because the contract stores more balances."

[OK] Correct: The contract updates only one user's balance each time, so it does not loop through all users. The time stays the same.

Interview Connect

Understanding how payable functions work and their time cost helps you explain smart contract efficiency clearly and confidently.

Self-Check

"What if the deposit function also loops through all users to update something? How would the time complexity change?"

Practice

(1/5)
1. What is the main purpose of a payable function in a blockchain smart contract?
easy
A. To allow the function to receive cryptocurrency along with the call
B. To make the function run faster
C. To restrict the function to only the contract owner
D. To prevent the function from modifying state variables

Solution

  1. Step 1: Understand the role of payable

    The payable keyword marks a function that can accept cryptocurrency (like Ether) when called.
  2. Step 2: Compare other options

    Options A, C, and D describe unrelated behaviors. Only To allow the function to receive cryptocurrency along with the call correctly describes the purpose of payable.
  3. Final Answer:

    To allow the function to receive cryptocurrency along with the call -> Option A
  4. Quick Check:

    Payable = Receive money [OK]
Hint: Payable means function can accept money sent [OK]
Common Mistakes:
  • Thinking payable makes function faster
  • Confusing payable with access control
  • Believing payable prevents state changes
2. Which of the following is the correct syntax to declare a payable function in Solidity?
easy
A. payable function deposit() public {}
B. function deposit() payable public {}
C. function payable deposit() public {}
D. function deposit() public payable {}

Solution

  1. Step 1: Recall Solidity function declaration order

    In Solidity, the visibility modifier (e.g., public) comes before payable keyword.
  2. Step 2: Check each option

    function deposit() public payable {} uses correct order: function deposit() public payable {}. Options A, B, and D have incorrect keyword order or syntax.
  3. Final Answer:

    function deposit() public payable {} -> Option D
  4. Quick Check:

    Correct order: visibility then payable [OK]
Hint: Visibility modifier before payable keyword [OK]
Common Mistakes:
  • Placing payable before function keyword
  • Switching order of public and payable
  • Using payable as a function name
3. What will be the output of the following Solidity function when called with 2 Ether?
contract Test {
    uint public balance;
    function deposit() public payable {
        balance = msg.value;
    }
}
medium
A. balance will be 2000000000000000000 (2 Ether in wei)
B. balance will be 2
C. Compilation error
D. balance will be 0

Solution

  1. Step 1: Understand msg.value in Solidity

    msg.value holds the amount of wei (smallest Ether unit) sent with the transaction. 2 Ether equals 2 * 10^18 wei = 2000000000000000000 wei.
  2. Step 2: Analyze the assignment to balance

    The function sets balance = msg.value, so balance stores the wei amount sent, which is 2000000000000000000.
  3. Final Answer:

    balance will be 2000000000000000000 (2 Ether in wei) -> Option A
  4. Quick Check:

    msg.value stores wei amount sent [OK]
Hint: msg.value is in wei, not Ether [OK]
Common Mistakes:
  • Assuming msg.value is in Ether
  • Expecting balance to be zero
  • Thinking function won't compile
4. Identify the error in this Solidity function that is intended to receive Ether:
function receiveFunds() public {
    require(msg.value > 0, "Send some Ether");
}
medium
A. require condition is incorrect
B. Function must be marked payable to receive Ether
C. Function visibility should be private
D. msg.value cannot be used inside functions

Solution

  1. Step 1: Check function declaration for payable

    To receive Ether, a function must be declared with the payable keyword. This function lacks it.
  2. Step 2: Validate other options

    The require condition is valid, visibility can be public, and msg.value is accessible in payable functions.
  3. Final Answer:

    Function must be marked payable to receive Ether -> Option B
  4. Quick Check:

    Missing payable causes Ether rejection [OK]
Hint: Add payable to accept Ether in function [OK]
Common Mistakes:
  • Forgetting payable keyword
  • Misusing require condition
  • Changing visibility unnecessarily
5. You want to create a smart contract function that accepts Ether and updates the sender's balance only if at least 1 Ether is sent. Which of the following implementations correctly achieves this?
hard
A. function deposit() payable public { if (msg.value > 1) { balances[msg.sender] = msg.value; } }
B. function deposit() public { require(msg.value >= 1 ether, "Minimum 1 Ether required"); balances[msg.sender] += msg.value; }
C. function deposit() public payable { require(msg.value >= 1 ether, "Minimum 1 Ether required"); balances[msg.sender] += msg.value; }
D. function deposit() public payable { if (msg.value >= 1) { balances[msg.sender] += msg.value; } }

Solution

  1. Step 1: Check for payable keyword and require condition

    function deposit() public payable { require(msg.value >= 1 ether, "Minimum 1 Ether required"); balances[msg.sender] += msg.value; } correctly marks the function as payable and uses require(msg.value >= 1 ether) to enforce minimum Ether sent.
  2. Step 2: Validate balance update and syntax

    function deposit() public payable { require(msg.value >= 1 ether, "Minimum 1 Ether required"); balances[msg.sender] += msg.value; } updates balances[msg.sender] by adding msg.value. Other options either miss payable, use wrong comparison, or incorrect balance update.
  3. Final Answer:

    function deposit() public payable { require(msg.value >= 1 ether, "Minimum 1 Ether required"); balances[msg.sender] += msg.value; } -> Option C
  4. Quick Check:

    Payable + require with 1 ether check [OK]
Hint: Use require with 1 ether and payable function [OK]
Common Mistakes:
  • Omitting payable keyword
  • Using incorrect Ether comparison
  • Not updating balance correctly
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard