In the process of learning blockchain programming, whether it's the most popular on YouTube or the Alchemy's , content related to Hardhat is inevitable. This is not surprising as in the field of Web3 development, Hardhat is undoubtedly one of the most mainstream frameworks. However, I encountered the same pitfall in the process of learning these two courses, that is, after using Hardhat to deploy smart contracts, I could never succeed in the verification. The same error always occurred: video tutorial solidity bootcamp An unexpected error occurred:
ConnectTimeoutError: Connect Timeout Error
...... I searched on Google for a long time but didn't find a complete solution. Then I tried to ask GPT-4 but still failed to solve it. Eventually, I found some insights in this on GitHub. Now, in combination with the actual process of solving this problem myself, I will record the process of analysis and verification, hoping to help those who also encounter this problem. post Firstly, I want to analyze the causes of this problem： I'm using the WSL2 system. The proxy is set in the Windows environment, and the WSL2 system shares the proxy from the Windows environment. Therefore, the solution idea in the aforementioned post did not initially catch my attention. I originally thought that my WSL2 system had set up to share the proxy from the Windows environment, and that I could connect normally using the command, so the inability to use Hardhat's verify function should not be a problem with the proxy settings. curl http://google.com Moreover, my error message and the content in the aforementioned post were quite different, aside from the ConnectTimeoutError. Given that Hardhat itself frequently updates, I thought it was an issue with the Hardhat version or a problem with one of its dependencies. What's more, GPT-4 analyzed the situation in the same way at the time, which somewhat misled my thinking. I tried to upgrade and downgrade and adjust the versions of libraries and dependencies like Hardhat, @nomicfoundation/hardhat-verify, @nomicfoundation/hardhat-toolbox several times, and even tried to apply for multiple API keys on Etherscan, only to find it didn't help. In the end, I realized that although I globally shared the proxy from the Windows environment in WSL2, the verify plugin might not use the global proxy under the WSL2 environment when Hardhat is running due to some reason. Problem Solution and Contract Verification Process Environment configuration: I have a simple here, which deploys an upgradeable contract. You can refer to my package.json file. Many answers online are quite outdated, but my libraries are all up to date. Of particular note is the need to install the Undici library, which will be used to set the proxy for verification. example project Writing the contract and deployment script: This is a standard step and not the focus of this article. But if you are a beginner like me, you can also refer to the simple contract and deployment script in my aforementioned repository. After the writing is done, we can deploy the contract under the Hardhat localhost environment or on the testnet. However, only when deployed on the testnet or mainnet can we use Hardhat's verify plugin. Apply for an API key on the website, which is free. After application, create a new .env file in the root directory of the Hardhat project and paste into it. Then set it in the hardhat.config.js configuration file. You can also refer to the configuration method in this file in my repository. Etherscan ETHERSCAN_KEY=yourApiKey Use the command to view your IP address, assuming it's , then check the "LAN" corresponding HTTP port through the VPN client in your Windows environment, assuming it's yyyyy. Add the following content to your hardhat.config.js file: ip route | grep default | awk '{print $3}' http://xxx.xx.xxx.x const { ProxyAgent, setGlobalDispatcher } = require("undici");
const proxyAgent = new ProxyAgent("http://xxx.xx.xxx.x:yyyyy");
setGlobalDispatcher(proxyAgent); Please note that you should not use the IP address and port in the aforementioned GitHub post, because everyone's VPN client and IP are different. The post also mentioned looking at the DNS server IP using and adding it to the configuration. But if you, like me, share the Windows proxy in the WSL2 environment, then your DNS is likely set by yourself, such as 8.8.8.8. So using the method I mentioned in the fourth point above is the safest. Also, don't forget to turn on options like "Allow LAN connections" in your VPN client. If your client doesn't have this option, you may need to switch to another one. cat /etc/resolv.conf Use the command to verify the contract, or you can write an additional verification function in the deployment script, which will complete the verification immediately after deployment. npx hardhat verify --network yourNetWork CONTRACT_ADDRESS

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

The writer is smart, but don't just like, take their word for it. #DoYourOwnResearch before making any investment decisions or decisions regarding your health or security. (Do not regard any of this content as professional investment advice, or health advice)

Too Long; Didn't Read

 Add passwordless user experiences to your app

HackerNoon Mobile

Solving the ConnectTimeoutError When Verifying Smart Contracts with Hardhat

Too Long; Didn't Read

@codingjourneyfromunemployment

Credibility

RELATED STORIES