You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can support Vyper in the current implementation of CheckedContract without needing to rewrite the entire class, as long as we are willing to sacrifice some code structure elegance in CheckedContract. For more details, refer to issue #1628.
Given that we'll have to rewrite CheckedContract soon, I think that making the code a bit more messy in order to support Vyper is not a big deal.
The text was updated successfully, but these errors were encountered:
marcocastignoli
changed the title
Plan support for Vyper verification with the current implementation of CheckedContract
Plan support for Vyper verification with the current implementation of CheckedContractSep 30, 2024
Proposal 1: making CheckedContract an abstract class and implementing SolidityCheckedContract + VyperCheckedContract
CheckedContract is actually used by the server in APIs handlers (not important for Vyper because we'll create a custom API), VerificationService.verifyDeployed (used to verify a contract) and StorageService.storeMatch (used to write the contract in active storage services).
I would create an abstract class for CheckedContract starting from all the mandatory properties/methods needed by verifyDeployed and storeMatch, then we can implement SolidityCheckedContract extends CheckedContract and VyperCheckedContract extends CheckedContract. Passing these new classes, verifyDeployed and storeMatch will check if SolidityCheckedContract functions are available before using them (e.g. tryToFindPerfectMetadata or accessing .metadata).
Each CheckedContract implementation will implement its own constructor, recompile and createJsonInputFromMetadata function.
Let's implement Vyper support following the proposal above. Regarding the StorageServices:
SourcifyDatabaseService and AllianceDatabaseService already supports Vyper. We can store it taking inspiration from the already existing Vyper verified_contracts stored by Blockscout: select * from compiled_contracts cc where cc."language" = 'vyper';
We can generate a metadata.json for RepositoryV1Service and RepositoryV2Service so that existing tools will not have to change how they interact with the repositories for Vyper contracts.
Let's keep track of the implementation in this issue.
marcocastignoli
changed the title
Plan support for Vyper verification with the current implementation of CheckedContract
Support for Vyper verification with the current implementation of CheckedContractOct 15, 2024
We can support Vyper in the current implementation of CheckedContract without needing to rewrite the entire class, as long as we are willing to sacrifice some code structure elegance in CheckedContract. For more details, refer to issue #1628.
Given that we'll have to rewrite CheckedContract soon, I think that making the code a bit more messy in order to support Vyper is not a big deal.
The text was updated successfully, but these errors were encountered: