Bird
Raised Fist0
Blockchain / Solidityprogramming~5 mins

Event declaration in Blockchain / Solidity - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Event declaration
O(1)
Understanding Time Complexity

When we declare events in blockchain smart contracts, it's important to know how this affects the program's speed.

We want to understand how the cost changes as more events are declared or used.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.


contract SimpleContract {
    event DataStored(address indexed sender, uint256 value);

    function storeData(uint256 _value) public {
        emit DataStored(msg.sender, _value);
    }
}
    

This code declares an event and emits it each time the storeData function is called.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Emitting the event inside the function.
  • How many times: Once per function call; no loops or recursion involved.
How Execution Grows With Input

Each time the function runs, it emits one event. The time to emit does not depend on input size.

Input Size (n)Approx. Operations
1010 event emissions
100100 event emissions
10001000 event emissions

Pattern observation: The number of operations grows linearly with the number of function calls.

Final Time Complexity

Time Complexity per function call: O(1)

This means emitting an event takes the same amount of time no matter the input size.

Common Mistake

[X] Wrong: "Emitting an event takes longer if the event has more data or is called many times inside a function."

[OK] Correct: Each event emission is a single action and does not loop over data inside the event. The time depends on the number of emissions, not event size.

Interview Connect

Understanding event declaration time helps you write efficient smart contracts that log important info without slowing down your code.

Self-Check

"What if the function emitted multiple different events in a loop? How would the time complexity change?"

Practice

(1/5)
1. What is the purpose of declaring an event in a blockchain smart contract?
easy
A. To create a new token within the contract
B. To store user data permanently on the blockchain
C. To log important actions so external apps can track them
D. To execute a function automatically on contract deployment

Solution

  1. Step 1: Understand event declaration purpose

    Events are declared to notify external apps about important contract actions.
  2. Step 2: Compare options with event role

    Only To log important actions so external apps can track them matches the role of events as logs for external tracking.
  3. Final Answer:

    To log important actions so external apps can track them -> Option C
  4. Quick Check:

    Events = Logs for external apps [OK]
Hint: Events are for logging actions, not storing data [OK]
Common Mistakes:
  • Confusing events with storage variables
  • Thinking events execute code automatically
  • Assuming events create tokens
2. Which of the following is the correct syntax to declare an event named Transfer with two indexed address parameters from and to in Solidity?
easy
A. event Transfer(address from indexed, address to indexed);
B. event Transfer(address indexed from, address indexed to);
C. event Transfer(address from, address to) indexed;
D. event Transfer(indexed address from, indexed address to);

Solution

  1. Step 1: Recall Solidity event syntax

    Indexed parameters are declared as type indexed name inside parentheses.
  2. Step 2: Check each option's syntax

    Only event Transfer(address indexed from, address indexed to); correctly places indexed after the type and before the parameter name.
  3. Final Answer:

    event Transfer(address indexed from, address indexed to); -> Option B
  4. Quick Check:

    Indexed parameters = type indexed name [OK]
Hint: Put 'indexed' right after the type, before the name [OK]
Common Mistakes:
  • Placing 'indexed' after the parameter name
  • Adding 'indexed' outside parentheses
  • Swapping order of 'indexed' and type
3. Given the Solidity code below, what will be the output when the function sendTokens is called?
contract Token {
    event Sent(address indexed from, address indexed to, uint amount);

    function sendTokens(address receiver, uint amount) public {
        emit Sent(msg.sender, receiver, amount);
    }
}
medium
A. An event 'Sent' is emitted with sender, receiver, and amount data
B. A compilation error due to missing return statement
C. Nothing happens because events do not emit automatically
D. The function returns the amount sent

Solution

  1. Step 1: Understand event emission in function

    The function calls emit Sent(...) which triggers the event with given parameters.
  2. Step 2: Check function behavior

    The function does not return anything but emits the event, so An event 'Sent' is emitted with sender, receiver, and amount data is correct.
  3. Final Answer:

    An event 'Sent' is emitted with sender, receiver, and amount data -> Option A
  4. Quick Check:

    emit triggers event with data [OK]
Hint: emit keyword triggers event logs during function execution [OK]
Common Mistakes:
  • Expecting a return value from event emission
  • Thinking events execute code or change state
  • Confusing event emission with function return
4. Identify the error in the following Solidity event declaration:
contract Example {
    event LogMessage(string message);

    function log(string memory msg) public {
        emit LogMessage(msg);
    }
}
medium
A. There is no error; the code is correct
B. The event declaration is missing the indexed keyword
C. The event cannot have string type parameters
D. The function parameter name conflicts with a reserved keyword

Solution

  1. Step 1: Review event declaration and usage

    The event LogMessage with a string parameter is valid and emitted correctly.
  2. Step 2: Check for reserved keyword conflicts

    The parameter name msg is allowed as a variable name; it does not conflict with reserved keywords.
  3. Final Answer:

    There is no error; the code is correct -> Option A
  4. Quick Check:

    Valid event with string parameter and emit usage [OK]
Hint: Strings are allowed in events; 'msg' is not reserved as variable name [OK]
Common Mistakes:
  • Assuming all event parameters must be indexed
  • Thinking 'msg' is a reserved keyword variable
  • Believing strings cannot be event parameters
5. You want to declare an event Approval that logs the owner, spender, and amount approved. You also want to filter logs by owner and spender efficiently. Which is the best event declaration?
hard
A. event Approval(indexed address owner, indexed address spender, uint amount);
B. event Approval(address owner, address spender, uint indexed amount);
C. event Approval(address owner indexed, address spender indexed, uint amount);
D. event Approval(address indexed owner, address indexed spender, uint amount);

Solution

  1. Step 1: Understand indexed parameters for filtering

    Indexed parameters allow efficient filtering in event logs by those fields.
  2. Step 2: Check correct syntax and indexing

    event Approval(address indexed owner, address indexed spender, uint amount); correctly indexes owner and spender addresses, allowing filtering; amount is not indexed.
  3. Final Answer:

    event Approval(address indexed owner, address indexed spender, uint amount); -> Option D
  4. Quick Check:

    Indexed parameters = filterable fields [OK]
Hint: Index addresses to filter events; amount usually not indexed [OK]
Common Mistakes:
  • Indexing non-address parameters unnecessarily
  • Incorrect syntax for indexed keyword placement
  • Indexing parameters in wrong order
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