[Vyper support] Add VyperCheckedContract in lib-sourcify and the new endpoint /verify/vyper in server

[marcocastignoli]

This PR currently:

• Implements VyperCheckedContract and SolidityCheckedContract. VyperCheckedContract generates a metadata file for Vyper contracts.
• Implements useVyperCompiler, a function similar to useCompiler which handles dynamic download for Vyper versions (need some more work for the platform architectures), and vyper compilation.
• verifyDeployed now takes as parameter CheckedContract, an abstract class extended by both VyperCheckedContract and SolidityCheckedContract. It skips metadata-related functions for VyperCheckedContract.
• Stores match in all StorageServices (I still haven't checked everything in detail)

TODO:

• - Review what's stored in the database
• - Create a common folder for the compilers code used by both lib-sourcify and server (idk if it fits in this new feature, imo yes because it's a lot of duplicated code now that we have also vyper stuff)
• - Rewrite platform architecture management (vyper versions for x86, arm, ...)
• - Add documentation
• - Handle vyper transformations (I still have to understand what we can do about it)
• - Add more tests, and finalize lib-sourcify test
• - Finalize /verify/vyper API errors + openapi responses
• - Documentation, updating readme files

[manuelwedler]

I found it quite impressive how minimal the changes to lib-sourcify are for this feature.

Some general feedback:

• Why do we need a metadata file mock for VyperCheckContract? I guess this is due to the verifyDeployed method which expects a metadata. This could be documented better in some way. Is it possible to get rid of it when we refactor the verification flow?
• lib-sourcify README needs to be updated due to renaming of CheckedContract.

I also tried to verify a vyper contract on a local server instance. Unfortunately, it didn't work due to Vyper path not found. The server logs show that vyper was downloaded. But I cannot find the binary on my machine.

2024-12-03T11:19:24.889Z [debug] [Server] Downloaded vyper - version=0.4.0 | vyperPath=/home/manuel/.vyper-bin/vyper.0.4.0.linux | platform=linux - [traceId=db3e02b8-8701-47ad-9deb-c84b6af76241]
2024-12-03T11:19:24.889Z [info] [Server] safeHandler - errorMessage=Vyper path not found | errorStack=Error: Vyper path not found
    at useVyperCompiler (/home/manuel/Projects/sourcify/sourcify/services/server/dist/server/services/compiler/local/vyperCompiler.js:46:15)

[manuelwedler]

I think this needs to be documented in the server's README.

[manuelwedler]

I don't see this fixed yet

[marcocastignoli]

Why do we need a metadata file mock for VyperCheckContract? I guess this is due to the verifyDeployed method which expects a metadata. This could be documented better in some way. Is it possible to get rid of it when we refactor the verification flow?

The main reason why we still need the metadata here is because we want to store it in RepositoryV1/V2 to align the repository fs to solidity contracts. I think @kuzdogan had this idea first.

[marcocastignoli]

I also tried to verify a vyper contract on a local server instance. Unfortunately, it didn't work due to Vyper path not found. The server logs show that vyper was downloaded. But I cannot find the binary on my machine.

That's probably related to the fact that I still have to work on rewriting platform architecture management (vyper versions for x86, arm, ...)

[kuzdogan]

Why do we need a metadata file mock for VyperCheckContract? I guess this is due to the verifyDeployed method which expects a metadata. This could be documented better in some way. Is it possible to get rid of it when we refactor the verification flow?

The main reason why we still need the metadata here is because we want to store it in RepositoryV1/V2 to align the repository fs to solidity contracts. I think @kuzdogan had this idea first.

We discussed this during the call but to recap, the reason is all of the APIv1 is based on the existence of the metadata.json. Some examples:

• People check if a contract is verified by GETing https://repo.sourcify.dev/contracts/partial_match/1/0x1F98431c8aD98523631AE4a59f267346ea31F984/metadata.json
• The only way to get the ABI is the metadata.json file
• Compilation information is only in metadata.json

So it's needed for backwards compatiility

[manuelwedler]

The additions until now look good. There are still some things missing from above.

[manuelwedler]

lgtm

We'll address the last comments afterwards