Unexpected creationMatch: match in contract with consistent CBOR auxdata in creation bytecode

[kuzdogan]

Here's a contract that from what I can see has consistent CBOR auxdata values in both onchain and recompiled creation bytecodes but for some reason doesn't have creationMatch: exact_match.

http://repo.sourcify.dev/8453/0x1775FAAFEDD0F3967361B96CD1F6BED737C18FB4

https://sourcify.dev/server/v2/contract/8453/0x1775FAAFEDD0F3967361B96CD1F6BED737C18FB4?fields=all

CborAuxdata: a26469706673582212200616d8159ba86cbc74c62492172ca035b84fe3575ba5e6f0713dc082a2538d6264736f6c63430008090033

Other cases:

• 8453/0x43D2B22EB66A95240FD4C48BCD3A8923BF1649F1
• 8453/0x2622926C2F0983D8E8EEB4544A7D1958C2EFB254

All have in common, the CBORAuxdata is not at the end of the creation bytecodes.

[deniswaker]

Hey, @kuzdogan . If you guys allow external contributions, I would be happy to work on this issue. Please, let me know if i can get assigned.

[kuzdogan]

Hey thanks @deniswaker I don't think this is a good issue for an external contribution but if you are still interested in diving deep here's what you can do:

• Set up your own Sourcify instance locally
• Start the server with the VSCode debugger

- Download the std-json of this contract and send a verification request to your local sourcify instance. You can use the /v2/verify endpoint that accepts std-json #1910 This isn't published yet but is on staging branch - Compare the result with the above result and see why the `creationMatch` is not `exact_match` but `match`.

[deniswaker]

Thank you. I will get started soon.

[manuelwedler]

@deniswaker Did you start working on this?

[manuelwedler]

I'm taking this one due to inactivity

[manuelwedler]

I found that this problem is fixed in the current Sourcify version. This means we can simply reverify these contracts, because this is an update for creation code from match to exact match. I already did with one of the examples above:
https://sourcify.dev/server/v2/contract/8453/0x2622926C2F0983D8E8EEB4544A7D1958C2EFB254?fields=all

I also wondered which change fixed this problem, but I am still not sure. IMO, it's not worth to look too deep for the change that fixed it. We can simply reverify these contracts. If anyone has an idea, I'd still appreciate it.

Next steps:

• create an SQL query to find all occurences of this case
• write and run a script for sending the contracts to verification again

[manuelwedler]

I modified the missing-creation-verified-data-script for our use case here, because it already has some useful features like batching and storing failed verifications.

See this branch: https://github.com/sourcifyeth/missing-creation-verified-data-script/tree/fix-creation-matches

I'm running it on production now.

[manuelwedler]

It turns out that reverifying through the public API runs into a bug. Since the bytecodes stay the same, reverifying these contracts creates a conflict with the constraints of the verified_contracts table. Any contract upgraded with the script above runs into the problem explained in #2167 (comment).
I already upgraded ~21k contracts that have inconsistent data now.

We will need to run the private upgrade endpoint for the ~21k inconsistent contracts and the ~150k contracts that haven't been upgraded yet.