We are excited to release this new version of Hardhat, as it makes Hardhat Network compatible with The Merge and makes our compilation much faster. Read on to learn more about these and other improvements.
Support for The Merge
Hardhat Network now has support for The Merge. To try it out, use the new merge hardfork setting. This hardfork is not selected by default, but you can enable it in your config:
module.exports = {
networks: {
hardhat: {
hardfork: "merge"
}
}
};Selecting this new hardfork will introduce a few changes to how Hardhat Network runs, but your contracts should still work without any modification. The rest of this section explains what these changes are.
The DIFFICULTY opcode (now renamed to PREVRANDAO) will return a pseudo-random value. This value is also exposed in the block header as mixHash.
You can use the new hardhat_setPrevRandao RPC method to modify the value returned by DIFFICULTY/PREVRANDAO in the next block. We recommend using the setPrevRandao network helper for this.
Hardhat Network’s JSON-RPC now accepts the new safe and finalized block tags, which in Hardhat Network are just aliases for the latest block tag, and correspond to the latest block.
Faster compilation
We optimized Hardhat’s compilation pipeline, significantly reducing the overhead it adds on top of solc. Compilation takes 40% less in most workflows, with a few taking 90% less!
How much of an impact this has depends on the size of your project, setup, and workflow, so we’ll explore two examples here, running the same benchmarks on each.
We’ll focus on a few different workflows:
- Clean compilation: compiling the entire codebase from scratch
- No recompilation: trying to compile when there has been no modification, and everything is cached.
- Leaf contract: modifying and recompiling a contract with tons of dependencies but that’s not imported by others after a clean compilation.
- Deep contract: modifying and recompiling a contract used in the entire codebase after a clean compilation
- Syntax error: introducing a syntax error to the leaf contract and trying to recompile it after a clean compilation
Open Zeppelin Contracts
This project is an example of a large codebase with a JavaScript setup. We expect most JavaScript projects to see similar or better results.
| Workflow | Time with Hardhat 2.10.12 | Time with Hardhat 2.11.0 | Time reduction |
|---|---|---|---|
| Clean compilation | 15.37s | 8.61s | 43.98% |
| No recompilation | 0.67s | 0.31s | 53.73% |
| Leaf contract | 8.02s | 3.06s | 61.84% |
| Deep contract | 11.9s | 6.96s | 41.51% |
| Syntax error | 4.77s | 0.36s | 92.45% |
Uniswap v3-core
This project is an example of a mid-size codebase with TypeScript and TypeChain. The benchmarks include both compilation and TypeChain types generation.
Due to the TypeScript changes described later in this document, we expect these results to be even better than those of Open Zeppelin Contracts. We believe these results will be what most Hardhat users will perceive when upgrading to this new version.
| Workflow | Time with Hardhat 2.10.12 | Time with Hardhat 2.11.0 | Time reduction |
|---|---|---|---|
| Clean compilation | 9.97s | 3.87s | 61.18% |
| No recompilation | 1.21s | 0.41s | 66.11% |
| Leaf contract | 9.29s | 3.82s | 58.88% |
| Deep contract | 9.17 | 3.82 | 58.34% |
| Syntax error | 5.79 | 0.45 | 92.22% |
Before running the benchmarks, we replaced the deprecated typechain-hardhat plugin with TypeChain’s official plugin. If you are still running the old one, upgrading will lead to better compilation times.
These benchmarks were run on an M1 Macbook Pro.
How to get the performance improvements
All you need to do to benefit from these performance improvements is to upgrade Hardhat and its plugins.
TypeScript type-checking is now opt-in
Until this version, if you used TypesScript, Hardhat type-checked your entire codebase every time it was run. While this could be useful to discover type errors quickly, it also meant that Hardhat users were waiting for the TypeScript compiler to run every time, making every Hardhat workflow slower.
Starting with Hardhat v2.11.0 we don’t type check your codebase unless you explicitly ask for it using the new --typecheck flag. This means that, by default, every task will run faster. You won’t get typing errors from Hardhat, but you should still get them in your editor.
Additionally, running without type-checking means using types from TypeChain in your config and tasks without any problem. If they haven’t been generated yet, Hardhat would still run, generating them after compiling.
We recommend using --typecheck in your CI or a similar workflow to ensure that your code is correct.
A new --flamegraph flag was added to profile Hardhat projects
Flamegraphs are a visualization of hierarchical data created to visualize stack traces of profiled software. While the Node.js ecosystem has excellent tools to create them, they aren’t really useful to profile Hardhat, as they lose track of asynchronous execution, which Hardhat uses extensively.
You can now run Hardhat’s CLI with a --flamegraph flag, which will profile the tasks’ execution and construct a flame graph of the stack of Hardhat tasks that were run. Instead of showing the JavaScript functions implementing Hardhat, this flame graph will only show tasks. This leads to a simpler-to-understand graph that can be used to optimize Hardhat, its plugins, and advanced projects overriding tasks.
Artifact paths cache
Hardhat now caches the paths to the artifacts it reads within the same process. This leads to tests taking less time to get started, which can be significant in larger projects like OpenZeppelin Contracts.
If you’re the author of a plugin and were depending on the artifact paths not being cached, please look at our updated Artifacts interface, which allows you to disable this behavior.