Why events communicate contract activity in Blockchain / Solidity - Challenge Your Understanding

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Solidity event emission?

Consider this Solidity contract snippet that emits an event when a value is updated. What will be logged in the transaction receipt's event logs after calling updateValue(42)?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract Example {
    event ValueChanged(address indexed author, uint256 oldValue, uint256 newValue);
    uint256 public value;

    function updateValue(uint256 newValue) public {
        uint256 old = value;
        value = newValue;
        emit ValueChanged(msg.sender, old, newValue);
    }
}

A An event log with author address, oldValue = 0, newValue = 42

B An event log with author address, oldValue = 42, newValue = 42

C No event log is created because events are not stored

D A runtime error occurs because events cannot have indexed parameters

💡 Hint

Events record the state before and after the change and include the sender's address.

When updateValue is called, the event ValueChanged is emitted with the sender's address, the old value (initially 0), and the new value (42). Events are stored in transaction logs and can be accessed off-chain.

🧠 Conceptual

intermediate

Why do smart contracts use events to communicate activity?

Which of the following best explains why smart contracts emit events to communicate contract activity?

A Events automatically update contract storage variables for faster access.

B Events allow off-chain applications to efficiently track contract state changes without reading all contract storage.

C Events prevent other contracts from calling the emitting contract.

D Events encrypt contract data to secure it from public view.

💡 Hint

Think about how external apps listen to blockchain changes.

Events are stored in transaction logs and can be indexed, allowing off-chain apps to listen and react to contract changes efficiently without expensive storage reads.

🔧 Debug

advanced

Identify the error in this event emission code

This Solidity function is supposed to emit an event when a user deposits Ether. What error will occur when compiling or running this code?

Blockchain / Solidity

pragma solidity ^0.8.0;

contract Deposit {
    event DepositMade(address indexed user, uint amount);

    function deposit() public payable {
        emit DepositMade(msg.sender, msg.value);
    }

    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

A Compilation error: event parameters must be non-indexed.

B SyntaxError: 'indexed' keyword cannot be used in event parameters.

C No error; the code compiles and runs correctly emitting the event.

D Runtime error: msg.value is not accessible in non-payable functions.

💡 Hint

Check the use of 'indexed' and payable function modifiers.

The code correctly declares an event with an indexed parameter and emits it inside a payable function. This is valid Solidity syntax and behavior.

❓ Predict Output

advanced

What is the output of this event filter query?

Given a contract that emits this event multiple times, what will be the result of filtering logs for ValueChanged events where author equals a specific address?

Blockchain / Solidity

event ValueChanged(address indexed author, uint256 oldValue, uint256 newValue);

// Assume events emitted:
// ValueChanged(0xABC..., 0, 10)
// ValueChanged(0xDEF..., 10, 20)
// ValueChanged(0xABC..., 20, 30)

// Filter query: author == 0xABC...

A Two event logs: one with oldValue 0 newValue 10, and one with oldValue 20 newValue 30

B All three event logs regardless of author

C No event logs because filtering by indexed parameters is not supported

D Only the first event log with oldValue 0 newValue 10

💡 Hint

Indexed parameters allow filtering events by that value.

Events with indexed parameters can be filtered by those values. Here, filtering by author address 0xABC... returns the two events where that address emitted the event.

🧠 Conceptual

expert

Why are events preferred over contract storage for communicating activity to off-chain systems?

Which reason best explains why blockchain developers prefer emitting events instead of writing data to contract storage to communicate contract activity to off-chain systems?

A Events automatically trigger off-chain code execution, while storage changes do not.

B Contract storage is private and cannot be read by off-chain systems, so events are the only way to share data.

C Writing to contract storage is slower because it requires consensus, but events do not require consensus.

D Events are cheaper in gas and provide an efficient, indexed log that off-chain systems can easily monitor without expensive storage reads.

💡 Hint

Think about gas costs and how off-chain apps listen to blockchain data.

Events are stored in transaction logs which are cheaper to write than contract storage and can be indexed for fast filtering. Off-chain systems use these logs to track contract activity efficiently.

Practice

1. Why do smart contracts use events to communicate activity?

easy

A. To send messages about contract actions to external listeners

B. To store large amounts of data permanently on the blockchain

C. To increase the gas cost of contract execution

D. To prevent users from interacting with the contract

Solution

1. Step 1: Understand the purpose of events in smart contracts

   Events are designed to notify external systems about what happens inside the contract without storing data permanently on-chain.

2. Step 2: Identify the correct use of events

   Events send messages to external listeners, like user interfaces or monitoring tools, about contract actions.

3. Final Answer:

   To send messages about contract actions to external listeners -> Option A

4. Quick Check:

   Events notify external systems = C [OK]

Hint: Events notify outside world about contract actions [OK]

Common Mistakes:

• Thinking events store large data permanently
• Believing events increase gas cost unnecessarily
• Confusing events with access control mechanisms

2. Which of the following is the correct syntax to declare an event in Solidity?

easy

A. event Transfer function(address from, address to, uint amount);

B. event Transfer(address indexed from, address indexed to, uint amount);

C. event Transfer {address from, address to, uint amount};

D. event Transfer = (address from, address to, uint amount);

Solution

1. Step 1: Recall Solidity event declaration syntax

   Events are declared with the keyword 'event', followed by the event name and parameters in parentheses, ending with a semicolon.

2. Step 2: Identify the correct syntax among options

   event Transfer(address indexed from, address indexed to, uint amount); matches the correct Solidity syntax with 'indexed' keywords for filtering.

3. Final Answer:

   event Transfer(address indexed from, address indexed to, uint amount); -> Option B

4. Quick Check:

   Correct event syntax uses parentheses and semicolon = D [OK]

Hint: Events use 'event Name(params);' syntax in Solidity [OK]

Common Mistakes:

• Using '=' instead of parentheses
• Using curly braces instead of parentheses
• Adding 'function' keyword in event declaration

3. Given the Solidity event and function below, what will be emitted when transfer(0x123, 100) is called?

event Transfer(address indexed from, address indexed to, uint amount);

function transfer(address to, uint amount) public {
    emit Transfer(msg.sender, to, amount);
}

medium

A. No event emitted because emit keyword is missing

B. Transfer event with from = 0x123, to = caller address, amount = 100

C. Transfer event with from = caller address, to = 0x123, amount = 100

D. Transfer event with from = 0x0, to = 0x123, amount = 0

Solution

1. Step 1: Understand the function call and event emission

   The function emits a Transfer event with 'msg.sender' as 'from', 'to' as the passed address, and 'amount' as passed.

2. Step 2: Apply the call parameters

   Calling transfer(0x123, 100) sets 'to' to 0x123 and 'amount' to 100; 'msg.sender' is the caller's address.

3. Final Answer:

   Transfer event with from = caller address, to = 0x123, amount = 100 -> Option C

4. Quick Check:

   emit Transfer(msg.sender, to, amount) = A [OK]

Hint: emit uses caller as from, passed args as to and amount [OK]

Common Mistakes:

• Confusing 'from' and 'to' parameters
• Forgetting 'emit' keyword
• Assuming default zero addresses

4. Identify the error in the following Solidity code snippet that prevents the event from being emitted:

event Deposit(address indexed sender, uint amount);

function deposit(uint amount) public {
    Deposit(msg.sender, amount);
}

medium

A. Event parameters are in wrong order

B. Function must be marked as 'payable' to emit events

C. Event name should be lowercase

D. Missing 'emit' keyword before the event call

Solution

1. Step 1: Review event emission syntax in Solidity

   Since Solidity 0.4.21, events must be emitted using the 'emit' keyword.

2. Step 2: Check the code for missing 'emit'

   The code calls 'Deposit(msg.sender, amount);' without 'emit', so the event won't be emitted.

3. Final Answer:

   Missing 'emit' keyword before the event call -> Option D

4. Quick Check:

   Events require 'emit' keyword = B [OK]

Hint: Always use 'emit' before event calls in Solidity [OK]

Common Mistakes:

• Omitting 'emit' keyword
• Assuming event names are case-insensitive
• Thinking 'payable' is required for events

5. You want to track token transfers in your contract efficiently. Which approach best uses events to minimize gas costs and allow external monitoring?

hard

A. Emit an event with indexed sender and receiver addresses and the amount transferred

B. Store all transfer details in a public array inside the contract

C. Use a mapping to save transfer history and emit no events

D. Emit events without indexed parameters to save gas

Solution

1. Step 1: Understand gas cost and event indexing

   Indexed event parameters allow efficient filtering by external tools and cost less gas than storing data on-chain.

2. Step 2: Evaluate options for tracking transfers

   Emitting events with indexed sender and receiver is efficient and allows external monitoring without high storage costs.

3. Final Answer:

   Emit an event with indexed sender and receiver addresses and the amount transferred -> Option A

4. Quick Check:

   Indexed events minimize gas and enable monitoring = A [OK]

Hint: Use indexed event params for efficient tracking [OK]

Common Mistakes:

• Storing all data on-chain increases gas costs
• Not indexing event parameters reduces filtering ability
• Avoiding events leads to poor external monitoring