Events
Solidity events give an abstraction on top of the EVM’s logging functionality. Applications can subscribe and listen to these events through the RPC interface of an Ethereum client.
In the traditional world, applications often use logs to capture and describe what’s going on at a specific moment. These logs are often used to debug applications, detect specific events, or notify the viewer of the logs that something happened. It turns out they are also very useful when writing or interacting with smart contracts!
💡 The Ethereum Virtual Machine (EVM) has a logging function
that is used to write data, including Solidity events, to a structure
outside smart contracts.
Syntax
event Deposit(address indexed from,bytes32 indexed id,uint value;
Logs and events are often referred to anonymously. Events allow you to ‘print’ information to the logging structure in a way that is more gas-efficient since the information is not stored in a storage variable, which takes up more gas. Events, or logs, live in the Transaction Receipts trie, which is inaccessible to smart contracts.
Events are inheritable members of contracts. When you call them, they cause the arguments to be stored in the transaction’s log - a special data structure in the blockchain. These logs are associated with the address of the contract, are incorporated into the blockchain, and stay there as long as a block is accessible (forever as of now, but this might change with Serenity). The Log and its event data is not accessible from within contracts (not even from the contract that created them).
💡 To put it simply, events are ways to communicate with a client application or front-end website that something has happened on the blockchain.
Logging in Ethereum
The EVM currently has 5 opcodes for emitting event logs: LOG0, LOG1, LOG2, LOG3, and LOG4.
These opcodes can be used to create log records. A log record can be used to describe an event within a smart contract, like a token transfer or a change of ownership.
Ethereum Yellowpaper — Byzantium Version 69351d5 (2018-12-10)
💡 Each log record consists of both topics and data.
Topics are 32-byte (256 bit) “words” that are used to describe what’s going on in an event. Different opcodes (LOG0 … LOG4) are needed to describe the number of topics that need to be included in the log record. For instance, LOG1 includes one topic, while LOG4 includes four topics. Therefore, the maximum number of topics that can be included in a single log record is four.
Topics in Ethereum Log Records
The first part of a log record consists of an array of topics. These topics are used to describe the event.
A topic can only hold a single word (32 bytes)Then they appear in the structure of topics, not the data portion of the log. When parameters do not have the indexed attributes, they are ABI-encoded into the data portion of the log.
Since topics can only hold a maximum of 32 bytes of data, things like arrays or strings cannot be used as topics reliably. Instead, it should be included as data in the log record, not as a topic. If you were to try including a topic that’s larger than 32 bytes, the topic will be hashed instead. As a result, this hash can only be reversed if you know the original input. In conclusion, topics should only reliably be used for data that strongly narrows down search queries (like addresses)
Data in Ethereum Log Records
The second part of a log record consists of additional data. Topics and data work best together as there are upsides and downsides to each. For example, while topics are searchable, data is not. But, including data is a lot cheaper than including topics. Additionally, while topics are limited to 4 * 32 bytes, event data is not, which means it can include large or complicated data like arrays or strings. Therefore, the event data (if any) can be seen as the value.
Indexed Events
Solidity events are interfaces with EVM logging functionality.
You can add an attribute indexed to up to three parameters. which adds them to “topics” instead of the data part of the log.
All parameters without the indexed attribute are ABI-encoded into the data part of the log.
Anonymous Events
The first topic usually consists of the signature (a keccak256 hash) of the name of the event that occurred, including the types (uint256, string, etc.) of its parameters.One exception where this signature is not included as the first topic is when emitting anonymous events
The hash of the signature of the event is one of the topics, except if you declared the event with the anonymous specifier.
This means that it is not possible to filter for specific anonymous events by name, you can only filter by the contract address.
💡 The advantage of anonymous events is that they are cheaper to deploy and call. It also allows you to declare four indexed arguments rather than three.
💡 The base cost of logging operations is 375 gas
. On top of that, every included topic costs an additional 375 gas
. Finally, each byte of data costs 8 gas
Logs are an elegant way to store tiny amounts of data on the Ethereum blockchain for a small price. Specifically, event logs are useful to let other people know something has happened without them having to query contracts individually.
Axat Bhardwaj
Blockchain Engineer
Top comments (0)