Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with event signatures uniqueness. #112

Open
dvush opened this issue May 20, 2022 · 0 comments
Open

Problem with event signatures uniqueness. #112

dvush opened this issue May 20, 2022 · 0 comments

Comments

@dvush
Copy link

dvush commented May 20, 2022

As of today, the registry assumes that there is only one event per signature but in reality different, binary incompatible events can have similar signature because of indexed values.

Notable example - transfer event
https://www.4byte.directory/event-signatures/?bytes_signature=0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b
Can be of two different flavors

  1. ERC721
    event Transfer(address indexed from, address indexed to, uint256 indexed id);
  2. ERC20
    event Transfer(address indexed from, address indexed to, uint256 value);

This way, it's hard to write code that uses registry to parse raw logs without additional complex logic to handle such collisions.

What if registry would return a list of possible event representations? This way, the client can just go over the list trying to decode each possible combination.

The possible issue that I can see is that the registry would be spammed by all possible combinations of indexed/unindexed fields, most of them being useless. For transfer, you have 2^3=8 possible combinations, and some of them are indistinguishable because it does not matter to binary representation which argument is indexed. I think sorting variants by "popularity" can resolve some issues.

What do you think about this problem, and can it be realistically solved in registry?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant