Events In EVM
Published: 2022-12-20 05:47:46

## 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!


<aside>
_💡 **The Ethereum Virtual Machine (EVM) has a logging function 
that is used to write data, including Solidity events, to a structure 
outside smart contracts.**_

</aside>

### 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).


<aside>
_💡 To put it simply, **events** are ways to communicate with a client application or front-end website that something has happened on the blockchain._

</aside>



## 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.

![Logs opcodes](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t7fvxhtvju77b7jqzqh7.png)

[Ethereum Yellowpaper](https://ethereum.github.io/yellowpaper/paper.pdf) — Byzantium Version 69351d5 (2018-12-10)


<aside>
💡 _Each log record consists of both **topics** and **data**._

</aside>


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](https://docs.soliditylang.org/en/v0.8.13/abi-spec.html#abi) into the data part of the log.



## Anonymous Events

The first topic usually consists of the ***signature*** (a [keccak256](https://en.wikipedia.org/wiki/SHA-3) 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. 


<aside>
💡 _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._

</aside>


<aside>
💡 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**

</aside>

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](https://linktr.ee/axatbhardwaj)
Blockchain Engineer