wmitsuda/topic0

Ethereum event log signatures database

topic0

Introduction

This repository is:

1. A public database of Ethereum event log signatures.
2. A set of scripts to generate the database from a Sourcify repository backup. We were able to extract almost 9K event signatures from mainnet verified contracts 🎉🎉🎉

Event what?

When a transaction gets included in an Ethereum block, its execution generates a receipt. A receipt contains 0 or more event logs. Event logs are composed by an array of topics.

For a non-anonymous event log, the first topic, topic[0], is used to identify the event signature. It is made of the keccak256 hash of the event signature.

However, since topic[0] is a hash, it is not possible to revert it to the original signature.

This is analogous to how 4byte function decoding works. If you are familiar to that concept, you already got the point.

This database provides the event signature for known topic hashes. From the event signature it is possible to decode the log entry to human-readable elements.

DB format

This repo follows a similar format to the popular 4bytes repository (https://github.com/ethereum-lists/4bytes).

signatures directory

It contains one file for each signature. The file contains the event signature used to generate the topic hash.

The filename is the hexadecimal string (without the 0x prefix) of the topic hash. Calculating the keccak256 the file contents must result in the filename.

For example, the file signatures/ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef contains the popular ERC20 Transfer(address,address,uint256) event signature.

with_parameter_names directory

It contains one file for each signature. The file contains one or more complete event signatures (separated by ";") corresponding to the topic hash.

We must say it contains one or more signatures because there are multiple signature variations which result in the same topic hash.

Please take a look at the gotchas page for more details.

The filename is the hexadecimal string (without the 0x prefix) of the topic hash.

For example, the file with_parameter_names/ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef contains the popular ERC20 Transfer(address indexed from, address indexed to, uint256 value) and ERC721 Transfer(address indexed from, address indexed to, uint256 indexed tokenId) event signatures.

Rebuilding the repo

Here.

Gotchas

Long explanation here.

Kudos

Proper kudos should be given to Sourcify, the raw data comes from them.

The scripts in this repository just perform extraction, processing and massaging on their data.

topic0's Issues

Sourcify has migrated from IPNS to DNSLink

Migrate to using DNSLink from IPNS

I would open a PR but I am not sure how you want to handle this

ref changes https://github.com/ethereum/sourcify/commit/1e33e676389f39957bcb00d60e575ad024f10750

Stable

IPNS=k51qzi5uqu5dll0ocge71eudqnrgnogmbr37gsgl12uubsinphjoknl6bbi41p

- IPNS=k51qzi5uqu5dll0ocge71eudqnrgnogmbr37gsgl12uubsinphjoknl6bbi41p

+ IPNS=repo.sourcify.dev # Use DNSLink

Staging

IPNS=k51qzi5uqu5dkuzo866rys9qexfvbfdwxjc20njcln808mzjrhnorgu5rh30lb

- IPNS=k51qzi5uqu5dkuzo866rys9qexfvbfdwxjc20njcln808mzjrhnorgu5rh30lb

+ IPNS=repo.staging.sourcify.dev # Use DNSLink

ipfs resolve -r /ipns/repo.sourcify.dev/manifest.json

Note on improving download speed

IPFS uses QUIC transfers. These connections can be limited by the size of the UDP receive buffer. This buffer holds packets that have been received by the kernel, but not yet read by the application (quic-go is what IPFS uses in this case). Once this buffer fills up, the kernel will drop any new incoming packet.

ensure you have configured

sysctl -w net.core.rmem_max=2500000

default is 208 kiB
you want: 2048 kiB

see https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size