Verify with creation bytecode DB

[kuzdogan]

Clean issue for the implementation of the creation bytecode DB.

We have a geth fork running on our servers which saves the creation bytecodes of contracts on the EVM level to an SQL database. The database has the following columns

| address | chain | code | hash | | ---| --- | --- | --- |

This is the typical flow with this feature:

• User provides source code and metadata
• Compile the contract to get the creation bytecode
• Search for contracts with the same creation bytecode in the database
  • If found matches (address + chain), verify those contracts with the provided source code and metadata. Show the user the verified contracts.
  • If not found, continue with the typical verification by asking chain + address

The above would be for the session API. For the non-session API, we might need to start accepting requests without chain + address. It should then be able to return multiple matches. This would likely require a new version of the API, to keep compatibility. It should also use the DB to verify other contracts, even if the user provides a chain + address.

There's previous code written for this feature at https://github.com/ethereum/sourcify/pull/507

The compete DB is under the DB creation-code-db, complete table. I've created a test db called test-creation-code-db with complete table for the development. Also a good idea to create a user with access only to this db.

_{View in Huly HI-387}

[marcocastignoli]

verifyContractsInSession is called each time a file is uploaded or imported.

https://github.com/ethereum/sourcify/blob/5a63a90f686272d5898bac2876d5a7dac11be3c8/src/server/controllers/VerificationController-util.ts#L377-L390

when the function isVerifiable is called we check if chainId / address are set. This is a potentially good point to check the creation bytecode DB. If it's not verifiable we: 1) compile the contract 2) query the creation bytecode db with the creation_bytecode 3) store as verified all the retrieved contracts using the sources used to compile 4) return the information to the user

Point 4 is not straightforward, there are two viable solutions but we need to change core stuff for both: a. the ContractWrapper right now supports only one chainId and one address, so we cannot store more chainIds / addresses for one ContractWrapper b. the key of the ContractWrapperMap is generated from the metadataRaw, so we cannot create a new ContractWrapper for each addresses/chain.

@kuzdogan I need a feedback, if you have better ideas let me know.

[kuzdogan]

This is a good starting point. My first thoughts would be:

• We should verify all other contracts regardless if the user-provided contract is verifiable or not. Think of it as if we suddenly found the source code that maps to a certain creation bytecode. We should always seize the opportunity to verify every possible contract whenever we receive a new "source-code --> creation-bytecode" mapping.
• We need to do this with non-session verification too. So maybe this is better as an external module?
• Thinking about the reproducibility of the verification, I'm not sure if it's a good idea to mark a contract as "verified" if we match against the creation code in the database. The db-matched contracts should also go through lib-sourcify verification, so that it will be reproducable.
  • However this might take reaaaaly long if we, for example, find 10s or 100s of db-matches. Maybe we need a queueing system or sorts

About the point 4, does the user need to know about all the contracts? Generally they are interested in the contract they are trying to verify. We can maybe return a small info text with "We have found 59 contracts matching the contract you've provided: . We will try verifying them in the meantime. You can save this list and check back later, if you're interested"