[List] The contract can be verified only via runtime code

[rimrakhimov]

The issue contains cases when contracts can be verified only via runtime code even though creation code still exists. We haven't noticed such cases before, but lately we've started to receive such requests from different users. This issue should help to keep track of all such cases and check whether they are systematic

1. Stripped creation codes. The creation code has been obtained via explicit insertion of constructor code to the runtime code of another contract. That is made because the creation code cannot be obtained from inside the blockchain and results in some kind of stripped version of creation code which cannot be verified. Runtime code is the same. https://rari.calderaexplorer.xyz/address/0xc98042b264B3914f75f0bABCa2aCD49D23b2582d - contract with stripped creation code https://rari.calderaexplorer.xyz/address/0x83bF3A69802493E6AAF2a1Ece6905000504FC371 - initial contract with full creation code https://github.com/OffchainLabs/token-bridge-contracts/blob/main/contracts/tokenbridge/libraries/CreationCodeHelper.sol - code that creates creation code from runtime code

2. Yul with constructor. Some yul contracts use some kind of constructor arguments on construction. That is, the caller have to append bytes to the creation code itself, which are further parsed and used by the construction code. The problem is that Yul contracts do not have ABIs which are used by the verifier to determine if constructor arguments supplied are valid. As a result, Yul contracts with some kind of construction logic cannot be verified via creation code https://explorer.immutable.com/address/0x2282753a6d470d65a8d4f313841c092bb9189a7c?tab=contract