Understand Events in EVM | Zhenye Dong’s Blog

type

status

date

slug

summary

What are Events?

In smart contracts, events are special logs used to broadcast specific on-chain actions to the outside world. They include Event Signatures, Indexed Parameters, and Unindexed Parameters, stored in transaction logs with specific data structures.

Basic Event Structure

In Solidity, events are typically defined as follows:

When an event is emitted, it generates a log with the following underlying structure:

1. Event Signature Hash

The event signature is a unique identifier, and its hash (Event Signature Hash) is calculated as follows:

For example, for an event:

Its event signature is:

And the corresponding hash value is:

2. Topics

Event topics is an array that stores the event signature hash and indexed parameters:

First item (topics[0]): Event signature hash.

Subsequent items (topics[1] to topics[n]): Indexed Arguments.

3. Data

Unindexed Arguments are stored in byte form in the data field. These parameters typically contain more detailed information but cannot be directly queried through indexing.

4. Indexed Parameter Limitations

Each event allows a maximum of three indexed parameters, which is one of Ethereum's log storage limitations.

Field Naming and Similar Concepts

Here are some recommended field names for better organization of event information:

Field List

Field Name	Description
`event_signature_hash`	Hash value of the event signature (`keccak256`).
`event_signature`	Plain text event signature (e.g.,`Transfer(address,address,uint256)`).
`topics`	Contains event signature hash and all`indexed`parameter values.
`data`	Contains the overall encoding of all unindexed parameters.
`value`(optional)	A specific logical field extracted from`data`. May contain multiple fields depending on the situation, and the name can be different.

Similar Concept Relationships

As shown below, if we split the event definition into event identifier (i.e., event_signature_hash) and parameter list (Args[]), they have the following relationships:

Example Analysis

Example 1: Classic Transfer Event

Here's the definition and emission of a Transfer event in an ERC20 contract:

Data Structure:

Assuming we call transfer(0xB, 100), the generated log looks like this:

Field Name	Example Value
`event_signature_hash`	`keccak256("Transfer(address,address,uint256)")`
`topics[0]`	`keccak256("Transfer(address,address,uint256)")`
`topics[1]`	`0xA`(from address)
`topics[2]`	`0xB`(to address)
`data`	`0x0000000000000000000000000000000000000000000000000000000000000064`(value: 100)
`value`	`100`(logical field extracted from data in this example)

Analysis:

topics[0] is the event signature hash, identifying the event type.

topics[1] and topics[2] store the from and to addresses, which are indexed parameters.

data stores the unindexed value, which is the transfer amount.

value is extracted from data and logically consistent with it.

Example 2: More Complex Event

Here's an event definition with multiple unindexed parameters:

Data Structure:

Assuming we call purchase(42, "Laptop", 2, 1500), the generated log looks like this:

Field Name	Example Value
`event_signature_hash`	`keccak256("ComplexEvent(address,uint256,string,uint256,uint256)")`
`topics[0]`	`keccak256("ComplexEvent(address,uint256,string,uint256,uint256)")`
`topics[1]`	`0xA`(user address)
`topics[2]`	`42`(itemId)
`data`	`ABI.encode("Laptop", 2, 1500)`
`value`	`1500`(extracted price field)

Analysis:

topics[0] is the event signature hash.

topics[1] and topics[2] store the indexed user and itemId.

data contains the unindexed description, quantity, and price, stored using ABI encoding.

value stores price separately for easy querying and logical processing.

Note:

This event example demonstrates a scenario using both indexed and unindexed parameters.

data contains information for multiple fields (description, quantity, price).

value is a specific field extracted from data.

FAQ

Does `event signature` use “digital signature”? Why is it named this way? What are alternatives?

Event Signature does not involve digital signature technology. It is simply an identifier generated using keccak256 hash to uniquely mark the event structure. This naming might be misleading as it suggests cryptographic signatures, so some more intuitive alternative names could be:

event_fullname (recommended)

event_identifier

Why does the `event signature` need to include type list? Why not include parameter names?

Event signatures include parameter type lists (like address, address, uint256) to ensure uniqueness and identifiability. If only event names were included without parameter lists, it could lead to event duplication.Parameter names (like to, from) are human-readable but don't affect event functionality since names only matter at the compiler level, while on-chain event structures mainly rely on types.

Since functions have function selectors, do events have event selectors? Why?

Contracts have "function selectors," which are the first 4 bytes (8 hexadecimal characters) prefix of the function signature, used for efficiency.Events don't have "event selectors" because topics[0] essentially serves a similar purpose, storing the complete hash of the event signature to ensure event uniqueness, requiring no further optimization.

Introduction to the Current Hash Algorithm

Ethereum uses keccak256, a variant of the SHA-3 standard. Here's a comparison with common hash algorithms:

Algorithm	Hash Length	Features	On-chain Usage
MD5	128-bit	Insecure, easily collided	Almost never used
SHA-256	256-bit	Secure, widely used in blockchain	Bitcoin hash calculation
Keccak	256-bit	Faster, better for hardware implementation	Ethereum event and function identifiers