One post tagged with "Signatures"

Recently Sourcify took over openchain.xyz's 4byte signature APIs as well as the domain itself, maintained by @samczsun. We also built the database and I wanted to run a quick analysis on the selector collisions and see how many collisions are legit vs. deliberately generated (spam).

We built the dataset and a service to serve the data. The dataset contains:

1. Data from openchain's dataset
2. Data from 4byte.directory
3. Signatures from verified contracts in Sourcify.

You can see the database schema in the database docs and the service in services/4byte in the repo. As of now we have 4.7 million signatures, of which 1.9 million are not from verified contracts, and the rest of the majority appear in at least one verified contract (stats).

While it's possible to submit signatures to the database via the /import endpoint, we also add the signatures to the database automatically when a contract is verified. The 4byte databases are known to be spam prone, as function signatures are only 4 bytes and it's trivial to find a collusion to an otherwise legit signature.

For example, see the ERC20 transfer(address,uint256) function's collisions under its selector 0xa9059cbb in our 4byte.sourcify.dev page: https://4byte.sourcify.dev/?q=0xa9059cbb

Seeing this and having the data I wanted do a quick analysis on the selector collisions and see how many collisions are legit vs. deliberately generated (spam).

Analysis​

Running a simple query to find the signatures that share the same 4byte selector:

SELECT
  concat('0x', encode(signature_hash_4, 'hex')) AS signature_hash_4,
  COUNT(*) AS num_signatures,
  ARRAY_AGG(signature ORDER BY signature) AS signatures
FROM public.signatures
GROUP BY signature_hash_4
HAVING COUNT(*) > 1
ORDER BY num_signatures DESC;

In the end we find 2789 4byte selectors that have more than one signature. Here are the top 5 with most collisions:

collisions.csv

collisions.json

Looking at the top collisions, it might look a lot. But still the spamming seems not excessive and spammers generally find a single funny signature and call it a day. Out of the 2789 selectors, 2740 have only 2 signatures (ie. a single collusion) and only 49 with more than 2 signatures.

The interesting question is, how many of these collisions are actually unintended collisions vs. how many are deliberately generated (spam)?

Looking at them one by one would take some time. First I want to actually see only the collisions that have a verified contract. Ie. if f00000001_bdmvamqo() is not seen on a verified contract, let's assume it's a spam.

SELECT
  concat('0x', encode(s.signature_hash_4, 'hex')) AS signature_hash_4,
  COUNT(*) AS num_signatures,
  ARRAY_AGG(DISTINCT s.signature ORDER BY s.signature) AS signatures
FROM public.signatures s
WHERE EXISTS (
  SELECT 1
  FROM public.compiled_contracts_signatures ccs
  WHERE ccs.signature_hash_32 = s.signature_hash_32
)
GROUP BY s.signature_hash_4
HAVING COUNT(*) > 1
ORDER BY num_signatures desc;

Now we're left with 1023 "verified" collisions:

collisions_verified.csv

collisions_verified.json

Now it starts to get interesting. Again the selectors with many collisions have mostly spam. But for 3 and less collisions we have some legitimate collisions.

For example for 0x01a754a3 we have AutoSwap() and updateTeamFeeContract(address). It's really difficult to tell if this is a spam or not.

But for the last row, 0x025313a2, we have getACLRole5999294130779334338() and proxyOwner(). Here the former is clearly a spam and the latter is not.

Next, we can actually ask an LLM to filter the ones looking like a spam! Since the data is not excessive, I shoved all of it into Claude and asked it to filter the ones looking like a spam. In the end it gave me a list of 648 collisions that it thinks are legitimate. I peeked in the list and it seems to be mostly accurate:

legitimate_collisions.csv

Here are 10 interesting examples of legitimate unintended collisions:

These are all legitimate functions and events from different smart contracts that happen to share the same 4-byte selector purely by chance. This demonstrates that while 4-byte collisions are rare, they do happen naturally in the wild!

At this stage I just ran this for fun. We only have a list of popular signatures that we know the "correct" signature for (canonical-signatures.json). We filter out non-canonical ones by default and have a filtered field (can turn off filtering in the API response ). But if the community thinks this is useful, we can do a more thorough analysis and filter out the spam via LLMs.