Contract failing to verify with creation bytecode with possibly wrong normalization

[kuzdogan]

While looking for a contract with many cborAuxdata fields for the new repo UI, I came across this one:

Address: 0x80a477a11b9AaFfaDc97Dc2785E9DB32859815F5
Chain: Base Sepolia (84532)

The contract is verified with the runtime bytecode but not with creation.

Apparently Etherscan also wasn't able to verify with the creation bytecode https://sepolia.basescan.org/address/0x80a477a11b9aaffadc97dc2785e9db32859815f5#code

The APIv2 returns the creation bytecode regardless (as discussed in #1979). One can spot several differences between the onchain vs. recompiled creation bytecode and most of them seemed to be the CBORAuxdata to me. So I investigated further and checked why it fails even after normalization.

The bytecodes at this line are the following:

sourcify/packages/lib-sourcify/src/lib/verification.ts

Lines 660 to 665 in 69e1927

	// If after the normalization the bytecodes are the same, we have a partial match
	if (
	normalizedOnchainCreationBytecode.startsWith(
	normalizedRecompiledCreationBytecode,
	)
	) {

normalized onchain creation bytecode
normalized-onchain-84532-0x80a477.txt

normalized recompiled creation bytecode
normalized-recompiled-84532-0x80a477.txt

You can check the diff in https://www.diffchecker.com/text-compare/ (choose Highlight: Character on the left sidebar)

From what I can see there are three differences after normalization:

1. Library

onchain bad4a09a79f4dd0cac798eaf7ba390be21c48794 vs. recompiled 42cc7d9bbcad1032b95aa9c26e95167f1750d8a3. This apparently is a library address given in the compiler settings:

    "libraries": {
      "src/TraitCategory.sol": {
        "TraitCategory": "0x42cc7d9bbcad1032b95aa9c26e95167f1750d8a3"
      }
    },

This one is expected as this is a linked library and the address is linked at the compile time, so there won't be a library placeholder we can look for. Apparently the user changed the library before deploying onchain. There's not much we can do about it.

2. CBOR Auxdatas

This is the more interesting part as I'd expected the normalization to handle these.

onchain: 583bdfa061092c38c530ff0026629fcf94b9bdd0c6a3063afcbf2c6aa20f19fd recompiled: a264697066735822122046cef13e939973f461d6d5184a2f95f92518d099f366ea7e22f7777f92a0c25164736f6c63430008110033

onchain: a2646970667358221220327c1c946ed7d24d7c061615eec047aea503a6ee00a406073472108d0e8a778564736f6c63430008110033 recompiled: a264697066735822122022e52c61b11b7c9141086dac1d81a484ae42bdd45269df5eff2bc04709dbd2ce64736f6c63430008110033

The IPFS hash part of these cborAuxdata were turned into into zeros in the normalized code

But other cborAuxdata, as found from the compiler output were not turned into zeros.

    "cborAuxdata": {
      "1": {
        "value": "0xa2646970667358221220490ef44aec87e88a7eb0c397b57d8dc1e9bf0bb0cfd90606f1e5895ec6b7985664736f6c63430008110033",
        "offset": 10314
      },
      "2": {
        "value": "0xa264697066735822122022e52c61b11b7c9141086dac1d81a484ae42bdd45269df5eff2bc04709dbd2ce64736f6c63430008110033",
        "offset": 21088
      },
      "3": {
        "value": "0xa2646970667358221220900c911a52dbfc724dd2c3f1f6325974708ada8ac1048f422e27bd2eff3312b564736f6c63430008110033",
        "offset": 28342
      },
      "4": {
        "value": "0xa264697066735822122046cef13e939973f461d6d5184a2f95f92518d099f366ea7e22f7777f92a0c25164736f6c63430008110033",
        "offset": 34802
      },
      "5": {
        "value": "0xa264697066735822122046cef13e939973f461d6d5184a2f95f92518d099f366ea7e22f7777f92a0c25164736f6c63430008110033",
        "offset": 34802
      },
      "6": {
        "value": "0xa2646970667358221220900c911a52dbfc724dd2c3f1f6325974708ada8ac1048f422e27bd2eff3312b564736f6c63430008110033",
        "offset": 28342
      }

I see that the zero'ed cborAuxdata above is not in the compiler output so my question is why were the IPFS hash part of those cborAuxdata were zero but not the other ones? I smell an inconsistency between how we handle cborAuxdatas and wanted to document it the best I can.