Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unrelated Etherscan verification message appears when verifying with a custom Sourcify instance #4776

Closed
acuarica opened this issue Jan 19, 2024 · 6 comments
Assignees

Comments

@acuarica
Copy link

acuarica commented Jan 19, 2024

Version of Hardhat

2.19.4

What happened?

It's not a bug in the sense that's something is not working properly. It is an unrelated error message which might be misleading to the user.

I'm working on the verification service for the Hedera network, which uses a custom instance of Sourcify. I wanted to validate that the hardhat-verify plugin works with our instance. It works well, but the verify task shows an unrelated Etherscan error message.

I created a new project, configure it with Hedera testnet, and deploy the sample contract. When I want to verify it with the hardhat-verify plugin, I got the following output

$ npx hardhat verify --network testnet <CONTRACT_ADDR>
Successfully verified contract Lock on Sourcify.
https://repository-verify.hashscan.io/contracts/full_match/296/<CONTRACT_ADDR>/
hardhat-verify found one or more errors during the verification process:

Etherscan:
Trying to verify a contract in a network with chain id 296, but the plugin doesn't recognize it as a supported chain.

You can manually add support for it by following these instructions: https://hardhat.org/verify-custom-networks

To see the list of supported networks, run this command:

  npx hardhat verify --list-networks

I expected the first part of the output, but the Etherscan message seems unrelated.

Minimal reproduction steps

Create a new Hardhat project, install its dependencies and use the following hardhat.config.js

require("@nomicfoundation/hardhat-toolbox");

/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
  solidity: "0.8.19",
  networks: {
    testnet: {
      url: 'https://testnet.hashio.io/api',
      accounts: ["<your private key, go to https://portal.hedera.com/ to setup one>"],
      chainId: 296,
    },
  },
  sourcify: {
    enabled: true,
    apiUrl: "https://server-verify.hashscan.io",
    browserUrl: "https://repository-verify.hashscan.io",
  }
};

Then run

npx hardhat run --network testnet scripts/deploy.js
npx hardhat verify --network testnet <CONTRACT_ADDR>

Verification in the custom Sourcify instance works well, but an unrelated Etherscan error message is displayed.

Search terms

verify hardhat-verify hedera sourcify etherscan

@fvictorio
Copy link
Member

Hey @acuarica, what's going on here is that Etherscan is enabled by default (and Sourcify is disabled by default). If you want to only use Sourcify, then you need to explicitly disable Etherscan:

etherscan: {
  enabled: false,
}

@bguiz
Copy link

bguiz commented Jan 30, 2024

@fvictorio this appears to work when I run from CLI (thanks!) but not when I run programmatically

If you want to only use Sourcify, then you need to explicitly disable Etherscan

❓ is there a way to disable etherscan when invoking hre.run('verify:verify', ...); as well?


/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/@nomicfoundation/hardhat-verify/src/internal/etherscan.ts:67
      throw new ChainConfigNotFoundError(currentChainId);
            ^
ChainConfigNotFoundError: Trying to verify a contract in a network with chain id 296, but the plugin doesn't recognize it as a supported chain.

You can manually add support for it by following these instructions: https://hardhat.org/verify-custom-networks

To see the list of supported networks, run this command, here is the stack trace:

  npx hardhat verify --list-networks
    at Function.getCurrentChainConfig (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/@nomicfoundation/hardhat-verify/src/internal/etherscan.ts:67:13)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at SimpleTaskDefinition.action (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/@nomicfoundation/hardhat-verify/src/internal/tasks/etherscan.ts:91:25)
    at Environment._runTaskDefinition (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/hardhat/src/internal/core/runtime-environment.ts:358:14)
    at Environment.run (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/hardhat/src/internal/core/runtime-environment.ts:191:14)
    at SimpleTaskDefinition.action (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/@nomicfoundation/hardhat-verify/src/index.ts:285:7)
    at Environment._runTaskDefinition (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/hardhat/src/internal/core/runtime-environment.ts:358:14)
    at Environment.run (/Users/user/code/hedera/hedera-tokens/erc20-hardhat/node_modules/hardhat/src/internal/core/runtime-environment.ts:191:14)
    at file:///Users/user/code/hedera/hedera-tokens/erc20-hardhat/scripts/verify.js:17:13

and for reference, here's the hardhat config used:

const hardhatConfig = {
  solidity: {
    version: '0.8.20',
    settings: {
      optimizer: {
        enabled: true,
        runs: 200,
      },
    },
  },
  networks: {
    hardhat: {
      accounts,
    },
    hederatestnet: {
      chainId: 296,
      url: rpcUrlHederatestnet,
      gasMultiplier: 1.1,
      accounts,
    },
  },
  sourcify: {
    enabled: true,
    apiUrl: 'https://server-verify.hashscan.io',
    browserUrl: 'https://repository-verify.hashscan.io',
  },
  etherscan: {
    enabled: false,
  },
  mocha: {
    timeout: 6_000_000,
  },
};

and the code used within scripts/verify.js to programmatically invoke verification:

            await hre.run('verify:verify', {
                address: deployedAddress,
            });

Note that if I replace the above hre.run invocation with the lines of code below, it succeeds.
(I'm ruling out possible unrelated errors introduced by my own verify script.)
So it seems that hre.run is ignoring the hardhatConfig.etherscan.enabled config value,
but the CLI invocation (via npx hardhat actually reads and uses that same config value.

            const shellExecStr = `npx hardhat verify --network "${hre.network.name}" "${deployedAddress}"`;
            const { stdout, stderr } = await childProcessExecAsPromise(shellExecStr);
            console.log(stdout);
            console.error(stderr);

@bguiz
Copy link

bguiz commented Jan 30, 2024

Self answering my previous question:

❓ is there a way to disable etherscan when invoking hre.run('verify:verify', ...); as well?

On a lark, I tried verify:sourcify as the task name instead of verify:verify... and it worked!

            await hre.run('verify:sourcify', {
                address: deployedAddress,
            });

So it looks like the remedy will likely need to be some combination of the following:

  • Update the docs at https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-verify to spell out the difference between the main task and the subtasks provided by the verify plugin (verify:verify, verify:sourcify, etc)
  • Update the implementation of the verify:verify task such that it checks hardhatConfig.VERIFY_TARGET.enabled before invoking each verify:VERIFY_TARGET subtask.

@bguiz
Copy link

bguiz commented Jan 30, 2024

@fvictorio do you want me to open a new/separate github issue for the programmatic thing described above?

@schaable
Copy link
Member

Hi @bguiz, the behavior you described for the programmatic verification was implemented the last week, it will be available in the next release. Regarding the doc, feel free to send a PR :)

@bguiz
Copy link

bguiz commented Feb 7, 2024

OK @schaable I've sent in a PR here: #4829

Hi @bguiz, the behavior you described for the programmatic verification was implemented the last week, it will be available in the next release. Regarding the doc, feel free to send a PR :)

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 8, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

No branches or pull requests

4 participants