Hardhat 3 is here: what's new and why you should use it - John Kane

Transcript

Okay. So, first off, my name is John and uh I work on the Heartat team at the Nomic Foundation. I'm going to be talking today about Heartat 3, our major new release. It's currently in beta, but it is ready for production. We'll talk you through some of the improvements you can be leveraging now. Then, a few tips on migrating a heart 2 project across to heart 3. and then uh some of the new features you can expect to come in the the near term over the next few uh weeks and months.

I just wanted to say a few words first on the Nomic Foundation. The entire heartat team um is part of Nomic but we have several projects at Nomic. We have the slang team which is a solidity compiler targeting developer tools. We also have the EDR team. So that's the Ethereum development runtime. Um a Rust library that lets you simulate an Ethereum node. Um you use it every time you boot up uh Heartat Node. It's fair to say that EDR is in fact the beating heart of Heartat Bree.

Nomic is a nonprofit that is dedicated to improving the developer platform for Ethereum and specifically Ethereum. We're here to make Ethereum's developers life better. And speaking of that, let's talk about Hartat. Hart is a smart contract development system. And first commits went down about 7 years ago. It started off as basically a node task runner wrapping salt C letting you deploy smart contracts into uh locally running Ethereum nodes and then adding testing capabilities in either JavaScript or TypeScript.

Over the years it expanded adding lots new capabilities but we have always had a core set of principles. Hard hat is designed to be extensible. That's one of the advantages of nodes but one of the key things we have always had is a strong plug-in system and API and that has led to a flourishing ecosystem of third party plugins. We've also concentrated on ease of use developers where they are. So whether you're developing the front end onto a smart contract system and you're dealing with some gnarly JavaScript mono repo, hard hatart works well there. The other end of the spectrum, if you've just got a pure solidity project and you're just trying to figure out why the the

contracts just reverted on you, heartat's there to help you parse the stack trace and reliability, right, and stability. We take Zenfair seriously and we uh have tried to avoid any breaking API changes between major versions. Heartat 2's API has been solid for years, but as the title suggests, spoilers, we've had to make some breaking changes. Um Heart 3 has needed them because the world around us has changed. Ethereum's uh uh rollup ccentric roadmap means that L2s are just part of the day-to-day experience of a solidity developer. Node has changed significantly. It's went through its

Python 2 to Python 3 moment with the switch over from Common GS which is what hard 2 was targeting to ECMAScript modules which is what hardat 3 targets. It's also embraced TypeScript even more uh tightly uh with all the the developer experience improvements that brings and solidity tooling has changed everyone in this room right we've had uh new frameworks with excellent new capabilities to take one big example I think the community has um I was going to say congealed but solidified around the importance of solidity tests Um, hard hat 3 then is an answer to that

changing environment while also delivering on our principles of extensibility, ease of use and reliability. It brings comprehensive testing support. You still have your JavaScript and TypeScript integration tests if you need them. Uh, if you have a large mocka test suite, please bring it to the heart free party and migrate across. But if you want to write your tests in Solidity, you now have that option. Over the last few years, we've rewritten our core simulation library, EDR, in Rust, uh, bringing significant performance improvements. We've seen

projects improve the performance of some of their test suites by 10x. And hard hat 3 explicitly targets L2s seeking to get very fine sorry more accurate simulation for currently optimism stackbased chains but in the future further L2s and Hartat has always been strong on deployments and with Hart 3 we've doubled down with our uh ignition smart contract deployment There many other improvements, but I wanted to jump in in detail. Okay, so Solidity tests tests written in Solidity

have several advantages. If you've got an integration test coming from JavaScript, hard hat needs to boot up a full Athereum node. So that's the um mele, that's the JSON RPC layer with a solidity test. All we need to do is execute in the EVM. SL tests are just going to be faster. You also don't have the overhead of having to translate between two programming languages. So that's conceptual overhead, but also maybe the debugging overhead as well. We think that solidity tests makes for a very effective unit test framework for covering smart contract logic and bringing it under test. But if you need a more complex scenario, uh perhaps

you're wanting to run across multiple transactions or you're wanting to uh emulate the network layer or the JSON RPC layer, you still have all of those options uh in JavaScript and TypeScript integration tests. You might recognize this codes. We have intentionally brought across the structure and cheat codes of Foundry. It's a primatic choice. um we're wanting to build on what works, but it's also an explicit design goal that a test suite written for Foundry should uh come across to hard hat 3 with ideally minimal but uh only small changes. As I said, we support uh most cheat codes and the cheat codes that we don't support

tend to be around scripting or other areas where hard hat has a different solution. Um we also support uh first testing and invariant test as well. L2s are now a key part of Ethereum and a key part of heartat 3. We are aiming to give precise simulation of the network you're actually developing for. for the moment that's uh limited to mainet as as before but uh optimism stackbased chains we've put in the API changes and the architectural changes what will let us support L further L2s in the future okay so what does this look like then

well we've had to rework the network API in heart 3 that's one of the breaking changes in this case what we're doing is we are making a RPC call to estimate L1 gas against an optimism uh network. We pull in hardat at the top as before, but now we're explicitly making the network connection. We're passing the unnamed heartat network config. That's hardat hop in this case passed in the network property and we heart will read that configuration out the heart attack config file. So it may be saying point at a node running on alchemy or infura or it might be saying um run an

in-memory simulation using edr but we also have the concept of chain type uh in this case op for for optimism. What that allows us to do is uh provide extra typescript uh type level information. In this case, we're flowing it into the VM client library. And that sets VM up with the uh additional information which tells it to include uh optimism only RPC calls. In this case, the estimate L1 gas um uh call.

If I was to change the chain type from OP to L1, then you'd immediately see the red squiggly line of a type error against estimate L1 gas because that's not available on mainet. on top of the additional type information by providing chain type is set to OP that tells if we're running a a local nodes and that tells EDR to run in optimism mode and that will reconfigure it for different pre-eploys it will update the um sorry it will reconfigure it for different pre-eploys or update the um JSON RPC calls um and and so on.

A world where we have multiple networks is also one in which you're going to need to connect to multiple networks in some scenarios. In hard hat 2, you were only able to create one network connection at a time per process. there were hacks and workarounds, but in Hart 3 because the network connection API is explicit, you can have as many connections as you need. So to summarize, you can now have multiple connections in your scripts and in your tests. They can be targeting either L1 or uh L2s. And if you are targeting an optimism L2, we can give

you better type checking support and a more refined simulation in local development nodes. Heartat free comes by default with ignition, our smart contract deployment system. Ignition allows you to declaratively describe a complex deployment. So you describe it in Typescript as what we call an ignition module using the build module function here. Ignition is able to read this build an execution plan and then provide validations. So finding issues and errors before any transactions are submitted.

It will then if it's happy with that uh take over the responsibilities for batching and uh sending the transactions out to the memory pool and monitoring them for success. It journals any interactions with the chain locally giving it the ability to restart uh uh interrupted or failed deployment. So you can see the sort of thing we're talking about here which would be this is an ignition module which is deploying two contracts parent and child you can pass in the constructor arguments and then on the soontobe successfully deployed contracts we're making an invigation of add child against the parent with the um successfully deployed child contract

address. Ignition has a a significant feature set. Things like deterministic deployments using create 2 or the ability to use it for setting up test fixtures. You should give it a look. Hard hat retains its philosophy of extensibility, right? The plug-in API has changed to create ESM support, but it's as powerful as ever. We have made the call though to take a more batteries included approach. So some features that were in plugins have now moved into core. One such example is code coverage. So code coverage is now built in. You just need to pass the d- coverage flag. It will give you coverage

statistics on your smart contracts for both solidity test and for JavaScript TypeScript integration tests. And indeed if you run both in the same invocation. So npx hard test will run both sets of tests. You can run them separately. If you run both then the um coverage code coverage statistics will be calculated based on the merger of those two test suites. Similarly, uh the calculation of gas statistics um in your test suite is now part of core as well. There's no need to pull in a further uh plugin or library.

And this similarly works for both types of tests. We've significantly improved our key store. There's no more need for end files and there's no more need for private keys and end files. The key store now will store your secrets in an encrypted file that's outside of your repository and in your your home directory. Um, if you're making a production deployment, you have the option of pulling in hard ledger. Uh, so you've got hardware wallet support for your deployment.

The swap over to EDR for Ethereum node simulation uh which is written in Rust has significantly uh improved the speed of our JavaScript TypeScript test suites. The test execution of Solidity test is on par with Foundry. But having both options lets you partition your test suites more effectively. So if you are just testing um conditional logic inside of your smart contract, the obvious answer is to go for a solidity test and you'll get the performance advantages that that brings.

I mentioned that so hardat 3 is production ready. uh major projects have switched over already. As you might have heard at the start, I mentioned that uh we have the beta tag. We don't expect there to be userfacing changes, but we're keeping the beta tag until all of the functionality that the hard hat 2 toolbox, so that's the project that you would get if you were initializing a new heart 2 project, is fully covered. Um, and we've been bringing in things like code coverage and gas statistics to cover any of the gaps that we had. We will keep that beta tag until we have it fully covered.

There may also be changes in the plugins API. Those we so I would say if you're a plug-in offer, there's uh guides and documentation on the heart website. Any changes to the API will be likely to be additions and enhancements in response to real world requests and usage. So if you are a plug-in offer, uh please get in touch with the team. Uh we definitely want to hear from you and any requests or features that you need, let us know. Okay, a few tips on migrating a heartat 2 project to heartat 3.

To be clear, while hard free has breaking changes, particularly around the plug-in API, uh the ESMified Heart config that you'll require, uh and the new network API, those are the those are the biggest ones. We have had an explicit design goal of trying to minimize the pain of a large existing codebase moving over to Artat 3 projects that have already migrated or that we're working with investigating to see how they'll migrate.

Every project varies, but we're looking at um developer effort at the level of days rather than weeks. But just to the the starting point for your migration should be the heartat docs. We have an extensive migration guide. So that's the best place to to go. But u to give you a feel for what's involved. Let me try again. There we go. To give you a feel for what's involved. Obviously inside of your package.json, you'll be bumping hard hats and the nomic plugins to the 3.x version range.

After that, the biggest change that you or sorry, the first change you're going to want to make is updating your heart attack config file. It has to become an ESM module. If you're using TypeScript, you're probably most of the way there already. Just changing the way the exports are handled. We've intentionally made it so that the config structure of your heart config is as close as possible to heartat 2. Most of your uh settings and properties should come across cleanly. One place you definitely will have to make a change though is the way that you were handling uh plugins and tasks in heart 2. Those were uh loaded automatically by side effects when you

imported or required into the heart attack config file under ESM. And for hard hat 3, you'll need to pull um the plugins and tasks in explicitly. So as you're seeing here with the hard hat toolbox VM plugin, the toolboxes are um collection of batteries included um hard sorry nomic uh extensions which will give you a an excellent starting feature set. The largest change however is likely to be in your test suite. Previously as I mentioned the network was created explicitly as you can see here at the top. So the uh RPC call against provider um is just automatically creating a

connection in the background. Hard hat free those connections are now done explicitly that allows you to have as many connections as you need and to set things like chain type if you want to. Creating the connections explicitly means you will need to make some decisions around your test suites specifically around isolation. So how um how your how your tests will run against or or how isolated your tests will be for uh against an Ethereum node. So do you want it so that the entire test suite runs against a single instance of the Ethereum node or do you want it that all the tests in a single file runs against the Ethereum node or maybe you

want isolation at the test level. That's a decision for each project themselves to make and it's a trade-off between performance, ease of use, and testing isolation. So, let it be upon each project's own head for whatever they decide. But with that decision made, well, there'll be many files that need to be updated. We've found in practice that um the migration is after that decision um while it's repetitive, it is a mechanical process and relatively straightforward.

Heart 3 provides a base we're going to continue building on. What features are coming though in the near future? So over the next few weeks Gas statistics as I said are available today. Um but gas snapshots. So that's the ability to run a test and capture the gas usage in a stored file. then take that as a baseline against which changes to the contracts and subsequent test runs can be compared. That gives you an excellent regression test and it's particularly useful in your CI. We want to add gas snapshots.

We're going to bring across heart vapor to heartat free. So any projects which are uh using Viper as part of their smart contract system will be able to take advantage of heartat free. We have nodes. We also love bun. We have projects which are already successfully running with uh bun support. We want to confirm that the complete feature set of hard hat and its combinations will work successfully with bun before we give it the full uh stamp of approval. Um but that's something that we hope to to do in the near future.

And more performance, right? Heart 3 is faster. Um but we're not going to rest on our laurels. EDR delivered in some cases 10x performance improvements in our test suites. In test execution, as I said, solid tests is on par with Foundry. However, we have identified uh improvements we can make within our build pipeline. So, we will continue making performance improvements based on real world usage and projects. Heart 3 delivers on our principles of extensibility, ease of use, and reliability while

improving performance, adding solidity tests, and taking hard hats multi-chain. There are many other improvements as well. So, I'd say give it a go. The best starting point is our docs. They've recently been completely revamped. So take a look again if you've not looked at them recently and tell us what you think. >> Thank you. [applause] >> Thank you so much John to uh for walking us through all of the updates. We have quite a few questions to go through.

>> Um I will start with the first one. Any plan to help devs automatically mock standard bridges protocols between multiple chains? >> Sorry. Could you repeat that question? >> Any plan to help developers automatically mock standard bridges protocols between multiple chains? >> Standard what protocols? Sorry. >> Bridges. >> Bridges and protocols. Okay. So straightforward answer is uh no or not in our immediate future. um that those sorts of complicated scenarios where I should say the our L2 simulation we're assuming that you're spinning up one nodes we're not simulating the interactions definitely

not at the hard hat level between the L2 and the L1 which I think those sorts of scenarios would imply that's not to say you may not be able to um get yourself quite close yourself um and that's definitely it's something we want to explore but it's not on the immediate road Are you embracing VM in favor of ethers in hard hat 3? Which one do you think pairs better with the new updates? >> Okay, so if you initialize a new hard hat project, you'll be given the option of either an either as mocka stack or a node test VM stack. By default, um we if if you don't make any other choices, we

will um we will you will get the the node test and VM stack. VM is an excellent client library and we really like the way that it embraces the enhancements that TypeScript enables and the the the the better type handling. However, just to be clear, we will continue supporting both mock and ethers enthusiastically. So if you have a large test suite um you do not need to worry you will be able to migrate that across and we will be supporting that uh throughout the lifetime of part 3.

>> Do you support custom deployment factory in hard hat ignition for determinist deterministic deployment of contracts? >> No but that is on our road map and that's something we definitely want to see. Sorry for everyone's um clarity uh you you I'm sorry I uh can click but I'm not going to go through all those use you I'm going to assume you roughly remember the ignition module that was described before with several contracts. What one of the things that ignition allows you to do is to use an alternate strategy of create 2, which instead of using a deployment transaction, the the uh ignition will make a call

against uh the create x contract factory as it's deployed out on the particular chain you're targeting. And so you'll get a deterministic deployment. Right now, ignition only supports create X. We have had many many requests for using alternate factories. That is something we definitely want to see uh improved and that's on our uh uh road map. >> One last question. >> Not yet, but that's one we we want to see solved soon. >> Thanks. One last question. How much support does Hardhat 3 provide for testing ERC 4337 account abstraction?

Can it simulate a bundler? So this one's um more of the EDR team, but I think the answer is that right now we are not providing all of the support that you would need and there are further changes that we would have to add into ETR before we get that. I'm going to look in the audience now for members of the EDR team and you can either nod yes or no if I've got that if I've misspoken. That was uh that was uh maybe I'm going to say yes. Okay, >> that will be all for today. Thank you so much.