feat: add support for EraVM Extensions

[kiriyaga-txfusion]

What ❔

Add support for the enableEraVMExtension flag (formerly isSystem) in the verification process.

Why ❔

Ensuring it matches the settings used during compilation.

fixes #331

Checklist

• [+] PR title corresponds to the body of PR (we generate changelog entries from PRs).
• [+] Tests for the changes have been added / updated.
• Documentation comments have been added / updated.

[github-actions]

API E2E Test Results

207 tests   207 ✅  19s ⏱️
 14 suites    0 💤
  1 files      0 ❌

Results for commit 510493c.

♻️ This comment has been updated with latest results.

[github-actions]

Unit Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 510493c.

♻️ This comment has been updated with latest results.

[github-actions]

Visit the preview URL for this PR:
https://staging-scan-v2--pr-357-43w4o0zq.web.app

[Romsters]

E2E tests have to be fixed

[vasyl-ivanchuk]

@kiriyaga-txfusion I believe the field should be passed to the contract verifier as enableEraVMExtensions, not as enableEraVMExtensionsUsed as it is right now.

Feel free to check the schema in the contract verifier’s incoming request type here.

Other than that, everything looks good.

[kiriyaga-txfusion]

@kiriyaga-txfusion I believe the field should be passed to the contract verifier as enableEraVMExtensions, not as enableEraVMExtensionsUsed as it is right now.

Feel free to check the schema in the contract verifier’s incoming request type here.

Other than that, everything looks good.

I included it as enableEraVMExtensions in line

[vasyl-ivanchuk]

@kiriyaga-txfusion I believe the field should be passed to the contract verifier as enableEraVMExtensions, not as enableEraVMExtensionsUsed as it is right now.
Feel free to check the schema in the contract verifier’s incoming request type here.
Other than that, everything looks good.

I included it as enableEraVMExtensions in line

@kiriyaga-txfusion ,

1. For the multipart-part verification the request to the verification service looks like this:

{
    "contractName": "Greeter.sol:Greeter",
    "codeFormat": "solidity-standard-json-input",
    "contractAddress": "...",
    "optimizationUsed": true,
    "enableEraVMExtensionsUsed": true,
    "sourceCode": {
        "language": "Solidity",
        "sources": {
            "Greeter.sol": {
                "content": "..."
            }
        },
        "settings": {
            "optimizer": {
                "enabled": true
            },
            "enableEraVMExtensions": true
        }
    },
    "compilerZksolcVersion": "vm-1.5.0-a167aa3",
    "compilerSolcVersion": "0.8.28"
}

• even though the enableEraVMExtensionsUsed is ignored by the verification service, let's not sent it as it not needed.
• enableEraVMExtensions - looks good.

2. For the single-file verification the request to the verification service looks like this:

{
    "contractName": "contracts/Greeter.sol:Greeter",
    "codeFormat": "solidity-single-file",
    "contractAddress": "....",
    "optimizationUsed": true,
    "enableEraVMExtensionsUsed": false,
    "sourceCode": "...",
    "compilerZksolcVersion": "vm-1.5.0-a167aa3",
    "compilerSolcVersion": "0.8.28"
}

since the sourceCode in this case is a string, enableEraVMExtensions should be sent in the root of the payload as enableEraVMExtensions but it's not the case.

And in general I'd rename enableEraVMExtensionsUsed filed in the form & types definition to enableEraVMExtensions as this way it matches the compiler setting name.

[kiriyaga-txfusion]

@kiriyaga-txfusion I believe the field should be passed to the contract verifier as enableEraVMExtensions, not as enableEraVMExtensionsUsed as it is right now.
Feel free to check the schema in the contract verifier’s incoming request type here.
Other than that, everything looks good.

I included it as enableEraVMExtensions in line

@kiriyaga-txfusion ,

1. For the multipart-part verification the request to the verification service looks like this:

{
    "contractName": "Greeter.sol:Greeter",
    "codeFormat": "solidity-standard-json-input",
    "contractAddress": "...",
    "optimizationUsed": true,
    "enableEraVMExtensionsUsed": true,
    "sourceCode": {
        "language": "Solidity",
        "sources": {
            "Greeter.sol": {
                "content": "..."
            }
        },
        "settings": {
            "optimizer": {
                "enabled": true
            },
            "enableEraVMExtensions": true
        }
    },
    "compilerZksolcVersion": "vm-1.5.0-a167aa3",
    "compilerSolcVersion": "0.8.28"
}

• even though the enableEraVMExtensionsUsed is ignored by the verification service, let's not sent it as it not needed.
• enableEraVMExtensions - looks good.

2. For the single-file verification the request to the verification service looks like this:

{
    "contractName": "contracts/Greeter.sol:Greeter",
    "codeFormat": "solidity-single-file",
    "contractAddress": "....",
    "optimizationUsed": true,
    "enableEraVMExtensionsUsed": false,
    "sourceCode": "...",
    "compilerZksolcVersion": "vm-1.5.0-a167aa3",
    "compilerSolcVersion": "0.8.28"
}

since the sourceCode in this case is a string, enableEraVMExtensions should be sent in the root of the payload as enableEraVMExtensions but it's not the case.

And in general I'd rename enableEraVMExtensionsUsed filed in the form & types definition to enableEraVMExtensions as this way it matches the compiler setting name.

Ah yes, you're right! For single files, we need to send that parameter separately. Thanks a lot! I will fix it ASAP.