Monitoring deployed contracts in Blockchain / Solidity - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this command monitoring a deployed contract event?

You run the command to listen for Transfer events on an ERC-20 token contract:

web3.eth.subscribe('logs', {address: '0xTokenAddress', topics: [web3.utils.sha3('Transfer(address,address,uint256)')]})

What will this command output when a transfer happens?

Blockchain / Solidity

web3.eth.subscribe('logs', {address: '0xTokenAddress', topics: [web3.utils.sha3('Transfer(address,address,uint256)')]})

A A boolean true indicating subscription success

B A list of all past Transfer events from the contract

C A syntax error because 'topics' is not a valid parameter

D An event log object containing transaction hash, block number, and data about the transfer

💡 Hint

Think about what 'subscribe' does in web3.js for event logs.

The subscribe method listens for new events matching the filter and outputs event log objects as they occur. It does not return past events or just a boolean.

❓ Configuration

intermediate

Which configuration correctly sets up a Prometheus exporter for Ethereum node metrics?

You want to monitor your Ethereum node using Prometheus. Which Prometheus scrape config snippet correctly scrapes metrics from a node exposing metrics at http://localhost:9545/metrics?

A

scrape_configs:
  - job_name: 'eth_node'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:9545']

B

scrape_configs:
  - job_name: 'eth_node'
    static_configs:
      - targets: ['http://localhost:9545/metrics']

C

scrape_configs:
  - job_name: 'eth_node'
    static_configs:
      - targets: ['localhost']

D

scrape_configs:
  - job_name: 'eth_node'
    static_configs:
      - targets: ['localhost:9545']

💡 Hint

Prometheus targets should be host:port without protocol, and metrics_path is set separately.

Option A correctly sets the metrics_path and target host:port without protocol. Option A misses metrics_path, B includes protocol which is invalid, C misses port.

❓ Troubleshoot

advanced

Why does your contract event listener miss some events?

You wrote a script to listen to contract events using web3.js subscription, but it misses some events when the node restarts. What is the most likely cause?

A The subscription only listens to new events after connection; missed events during downtime are lost

B The contract ABI is outdated and cannot decode events correctly

C The node is not synced fully and cannot provide event data

D The web3.js version does not support event subscriptions

💡 Hint

Think about what happens to event subscriptions when the connection drops.

Subscriptions listen only to new events after connection. Events emitted during downtime are not received unless you query past logs.

🔀 Workflow

advanced

What is the correct workflow to monitor contract state changes reliably?

You want to monitor a deployed smart contract's state changes and ensure no events are missed even if your monitoring service restarts. Which workflow is best?

A Use event subscriptions only and restart them on service start

B Only query the current contract state on demand without event listening

C Periodically query past events from the last known block and combine with live subscriptions

D Use a centralized logging service that stores all blockchain transactions

💡 Hint

Consider how to handle downtime and missed events.

Combining past event queries with live subscriptions ensures no events are missed during downtime.

✅ Best Practice

expert

Which practice best improves monitoring scalability for many deployed contracts?

You manage monitoring for hundreds of deployed contracts on Ethereum. What is the best practice to scale event monitoring efficiently?

A Run one full node per contract to isolate event streams

B Use a centralized event indexing service like The Graph to query events

C Subscribe to all events on the main node and filter in your application

D Poll each contract's state every second to detect changes

💡 Hint

Think about reducing load and complexity on your own infrastructure.

Centralized indexing services efficiently index and provide event data for many contracts, reducing node load and complexity.