Event declaration in Blockchain / Solidity - Time & Space 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.
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 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.
Each time the function runs, it emits one event. The time to emit does not depend on input size.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 event emissions |
| 100 | 100 event emissions |
| 1000 | 1000 event emissions |
Pattern observation: The number of operations grows linearly with the number of function calls.
Time Complexity per function call: O(1)
This means emitting an event takes the same amount of time no matter the input size.
[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.
Understanding event declaration time helps you write efficient smart contracts that log important info without slowing down your code.
"What if the function emitted multiple different events in a loop? How would the time complexity change?"
Practice
event in a blockchain smart contract?Solution
Step 1: Understand event declaration purpose
Events are declared to notify external apps about important contract actions.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.Final Answer:
To log important actions so external apps can track them -> Option CQuick Check:
Events = Logs for external apps [OK]
- Confusing events with storage variables
- Thinking events execute code automatically
- Assuming events create tokens
Transfer with two indexed address parameters from and to in Solidity?Solution
Step 1: Recall Solidity event syntax
Indexed parameters are declared astype indexed nameinside parentheses.Step 2: Check each option's syntax
Only event Transfer(address indexed from, address indexed to); correctly placesindexedafter the type and before the parameter name.Final Answer:
event Transfer(address indexed from, address indexed to); -> Option BQuick Check:
Indexed parameters = type indexed name [OK]
- Placing 'indexed' after the parameter name
- Adding 'indexed' outside parentheses
- Swapping order of 'indexed' and type
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);
}
}Solution
Step 1: Understand event emission in function
The function callsemit Sent(...)which triggers the event with given parameters.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.Final Answer:
An event 'Sent' is emitted with sender, receiver, and amount data -> Option AQuick Check:
emit triggers event with data [OK]
- Expecting a return value from event emission
- Thinking events execute code or change state
- Confusing event emission with function return
contract Example {
event LogMessage(string message);
function log(string memory msg) public {
emit LogMessage(msg);
}
}Solution
Step 1: Review event declaration and usage
The eventLogMessagewith a string parameter is valid and emitted correctly.Step 2: Check for reserved keyword conflicts
The parameter namemsgis allowed as a variable name; it does not conflict with reserved keywords.Final Answer:
There is no error; the code is correct -> Option AQuick Check:
Valid event with string parameter and emit usage [OK]
- Assuming all event parameters must be indexed
- Thinking 'msg' is a reserved keyword variable
- Believing strings cannot be event parameters
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?Solution
Step 1: Understand indexed parameters for filtering
Indexed parameters allow efficient filtering in event logs by those fields.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.Final Answer:
event Approval(address indexed owner, address indexed spender, uint amount); -> Option DQuick Check:
Indexed parameters = filterable fields [OK]
- Indexing non-address parameters unnecessarily
- Incorrect syntax for indexed keyword placement
- Indexing parameters in wrong order
Ready to prove it?
Pass the test and this pattern moves unknown
